Agile-разработка по — это не только про разработчиков

Создание кода, культура и agile-разработка ПО на новом уровне

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

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

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

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

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

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

В то же время руководитель по Agile-разработке понимает, что хорошим специалистам нужно доверять. Постулат Agile-разработки гласит: участники процесса, погруженные в фактическую работу, смогут лучше всех оценить объем и сделать эту работу качественно. График устанавливает команда. Уникальный вклад руководителя по разработке состоит в том, что в ходе оценки сложности работы он может запрашивать предположения и проверять их обоснованность как равный участник команды, а не как начальник.
В Agile-организациях не говорят: «Придумай, как сделать это за четыре недели» (а если говорят, то это тревожный звоночек).
«Постулат agile-разработки: кто больше всех погружен в фактическую работу, тот лучше всех может оценить объем работы и сделать эту работу качественно».
Кто такой scrum-мастер?
Scrum-мастера — это руководители проекта в Agile-команде, в чьи задачи входят оптимизация работы и посредничество между владельцем продукта и командой, чтобы спринты проводились успешно и предсказуемо. Scrum-мастера также отвечают за координирование действий нескольких команд, чтобы основная команда могла сосредоточиться на разработке продукта.
Scrum-мастер следит, чтобы все работали эффективно и согласованно. Как следствие, Scrum-мастер контролирует потоки входящих и исходящих данных, необходимых для реализации Agile-программы. Этот человек занимается Agile-собраниями: собранием по запуску спринта, ежедневными стендапами, собранием по обзору итогов спринта и ретроспективой спринта и вместе с командой и руководителями по разработке проводит оценку сложности крупных элементов бэклога, таких как эпики и отдельные пользовательские истории. Scrum-мастер может не так хорошо разбираться в технических вопросах, как другие участники команды. В таком случае на помощь может прийти руководитель по разработке, который предоставит ценную информацию о ситуации, если возникнет пробел в знаниях. Когда команда становится более подкованной в применении принципов Agile, Scrum-мастер начинает уделять больше внимания оптимизации скорости поставки, а не оценке сложности.
В более крупной организации Scrum-мастер также принимает на себя роль Agile-наставника. Он помогает команде освоить Agile-практики и умело применять их на протяжении всего цикла жизни продукта: оценку сложности работы в очках за истории, планирование спринтов и непрерывную поставку. Обязанности наставника занимают важное место в роли Scrum-мастера. Он, как эксперт по Agile, знает, зачем методика нужна проекту и компании, и может выступать в поддержку методов Agile, пока компания пытается преодолеть первичные трудности их освоения.
Scrum-мастера и руководители по разработке работают над agile-портфелями вместе как партнеры
В большинстве команд, использующих каскадную модель, центральную роль играет менеджер. Он отвечает за расстановку приоритетов, отслеживание хода работы и оценку производительности. Однако Agile-команды исходят из принципов самоорганизации: они сами составляют дорожную карту и отвечают за поставку. Чтобы подобное прижилось в более крупных организациях, Scrum-мастера и руководители по разработке вместе взращивают Agile-культуру в рамках всей организации и выступают в качестве посредников между командами и руководством высшего звена. Поскольку люди в этих ролях могут взаимодействовать сразу с несколькими Agile-командами, они являются основными агентами в Agile-портфеле.
Пусть Scrum-мастер работает над тем, как команда осваивает и применяет принципы Agile, а руководитель по разработке отвечает за правильный подбор участников команды, курирование существующих участников и поддержание здоровой культуры разработки в каждой команде. Совместная работа двух этих сотрудников способствует успеху Agile-команд.
Среди команд разработчиков ПО Agile и DevOps наиболее популярна система управления версиями Git, которая составляет важную часть набора инструментальных средств DevOps. Эта система с открытым исходным кодом активно поддерживается, а благодаря универсальности ее можно использовать в рамках разнообразных рабочих процессов, с помощью которых та или иная команда разработчиков решает свои задачи. Поскольку система является распределенной (а не централизованной), она значительно повышает производительность. Так разработчики могут выполнять работу на собственных локальных устройствах и передавать изменения в общий репозиторий, только когда они будут готовы представить эти изменения команде.
Система Git подходит для применения в командах Agile- и DevOps-разработки не только за счет универсальности и распределенности. Ее ключевые функции также являются хорошим подспорьем в деле Agile и DevOps и расширяют возможности разработчиков. Git можно рассматривать как составную часть Agile- и DevOps-разработки. Изменения можно отправлять вперед по конвейеру развертывания быстрее, чем при работе с монолитными релизами и централизованными системами управления версиями. Git работает так же, как работают (и как должны работать) Agile- и DevOps-команды.
ПОДСКАЗКА