Менеджеры по Agile: руководители по разработке и scrum-мастера

По своей структуре agile-команды не похожи на команды, работающие по каскадной модели. У последних структура повторяет структуру организации, при этом планирование часто ведется по принципу «сверху вниз», т. е. руководство устанавливает график и сроки выполнения.

Команды agile-разработки функционируют по принципу самоорганизации. Они составляют собственный график, исходя из расстановки приоритетов владельцем продукта и имеющихся ресурсов.

Scrum-мастера и руководители по разработке заполняют разрыв между высшим руководством и отдельными командами разработчиков. #ScrumMasters #DevelopmentManagers Они стремятся оптимизировать команды и отдельных сотрудников, чтобы те поставляли программное обеспечение наивысшего качества, которое приближало бы компанию к ее целям.

Scrum-мастера и руководители по разработке также следят, чтобы команды не отвлекались на внешние моменты, такие как изменение объема функций, плохие примеры использования каскадной модели, совмещение обязанностей и побочные проекты, которые отвлекают команду от истинных целей.

Scrum-мастера и руководители по разработке также следят, чтобы команды не отвлекались на внешние моменты, такие как изменение объема функций, плохие примеры использования каскадной модели, совмещение обязанностей и побочные проекты, которые отвлекают команду от истинных целей. Как scrum-мастера, так и руководители по разработке обычно работают с несколькими agile-командами. Рассмотрим, как они работают с каждой командой в более крупных agile-портфелях.

Руководители по разработке играют большую роль в agile-организациях, становясь их центральным звеном. Они отвечают за качество продукта, начиная от архитектуры кода и заканчивая качеством взаимодействия с конечными пользователями.

Они принимают участие в проверках кода и следят, чтобы код, написанный участниками команды, отвечал краткосрочным и долгосрочным целям программы. Поскольку они очень тесно взаимодействуют с командой, от них часто зависит выбор технологии для реализации программы.

Такая близость к процессу и продукту позволяет руководителям по разработке передавать контекст команде и организации в целом.

Хорошие руководители по разработке уделяют много времени формированию команды, начиная с приема сотрудника на работу. Они управляют процессом найма, и их место в организации располагает к этому по следующим причинам.

• Процесс подбора сотрудников требует времени и внимания команды.

• Одновременно искать кандидатов и создавать качественные продукты не выйдет.

• Руководитель по разработке может упростить процесс адаптации каждого нового сотрудника, чтобы он постепенно стал частью команды.

Проще говоря, пока руководитель по разработке занимается поиском и наймом сотрудников, команда может сосредоточиться на продукте.

Руководители по разработке также берут на себя роль партнера и наставника, так как они хорошо разбираются в основных составляющих системы управления: личных встречах, обратной связи и обучении. Успешные руководители по разработке содействуют профессиональной деятельности разработчиков, чтобы те максимально раскрыли свой потенциал в отношении идей, кода, тестов и культуры.

Иногда от команды требуется принимать решения разного масштаба, от архитектурного проектирования до выбора стратегий ветвления. Опытные руководители по разработке знают, когда следует вмешаться, а когда лучше позволить команде решать проблемы самостоятельно, чтобы участники могли развиваться.

Существенное отличие Agile от каскадной модели заключается в том, что в Agile-команде руководитель по разработке на равных условиях принимает участие в процессе оценки сложности. В команде, работающей по каскадной модели, можно услышать такой разговор.

• Руководитель: «Но тебе нужно придумать, как сделать это за четыре недели».

• Разработчик: «Это займет шесть недель. Чтобы вывести эту возможность на рынок, потребуется сделать первое, второе и третье».

• Руководитель: «Звучит разумно. «Но тебе нужно придумать, как сделать это за четыре недели».

В то же время руководитель по Agile-разработке понимает, что хорошим специалистам нужно доверять. Постулат Agile-разработки гласит: участники процесса, погруженные в фактическую работу, смогут лучше всех оценить объем и сделать эту работу качественно. График устанавливает команда. Уникальный вклад руководителя по разработке состоит в том, что в ходе оценки сложности работы он может запрашивать предположения и проверять их обоснованность как равный участник команды, а не как начальник.

В Agile-организациях не говорят: «Придумай, как сделать это за четыре недели» (а если говорят, то это тревожный звоночек).

Scrum-мастера — это руководители проекта в Agile-команде, в чьи задачи входят оптимизация работы и посредничество между владельцем продукта и командой, чтобы спринты проводились успешно и предсказуемо. Scrum-мастера также отвечают за координирование действий нескольких команд, чтобы основная команда могла сосредоточиться на разработке продукта.

Scrum-мастер следит, чтобы все работали эффективно и согласованно. Как следствие, Scrum-мастер контролирует потоки входящих и исходящих данных, необходимых для реализации Agile-программы. Этот человек занимается Agile-собраниями: собранием по запуску спринта, ежедневными стендапами, собранием по обзору итогов спринта и ретроспективой спринта и вместе с командой и руководителями по разработке проводит оценку сложности крупных элементов бэклога, таких как эпики и отдельные пользовательские истории. Scrum-мастер может не так хорошо разбираться в технических вопросах, как другие участники команды. В таком случае на помощь может прийти руководитель по разработке, который предоставит ценную информацию о ситуации, если возникнет пробел в знаниях. Когда команда становится более подкованной в применении принципов Agile, Scrum-мастер начинает уделять больше внимания оптимизации скорости поставки, а не оценке сложности.

В более крупной организации Scrum-мастер также принимает на себя роль Agile-наставника. Он помогает команде освоить Agile-практики и умело применять их на протяжении всего цикла жизни продукта: оценку сложности работы в очках за истории, планирование спринтов и непрерывную поставку. Обязанности наставника занимают важное место в роли Scrum-мастера. Он, как эксперт по Agile, знает, зачем методика нужна проекту и компании, и может выступать в поддержку методов Agile, пока компания пытается преодолеть первичные трудности их освоения.

В большинстве команд, использующих каскадную модель, центральную роль играет менеджер. Он отвечает за расстановку приоритетов, отслеживание хода работы и оценку производительности. Однако Agile-команды исходят из принципов самоорганизации: они сами составляют дорожную карту и отвечают за поставку. Чтобы подобное прижилось в более крупных организациях, Scrum-мастера и руководители по разработке вместе взращивают Agile-культуру в рамках всей организации и выступают в качестве посредников между командами и руководством высшего звена. Поскольку люди в этих ролях могут взаимодействовать сразу с несколькими Agile-командами, они являются основными агентами в Agile-портфеле.

Пусть Scrum-мастер работает над тем, как команда осваивает и применяет принципы Agile, а руководитель по разработке отвечает за правильный подбор участников команды, курирование существующих участников и поддержание здоровой культуры разработки в каждой команде. Совместная работа двух этих сотрудников способствует успеху Agile-команд.