Цикл "Agile: Планирование": Agile-подход

Как приручить Agile?

В предыдущей статье я начал разбирать вопрос "А для чего собственно нужно планирование и какая его функция?". В этой же буду делиться инструментами.

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

Что это значит? Что придется много общаться. Много адаптироваться. Много переписывать и много переделывать. Быть готовым, что любой план может разрушиться, но при этом не отпускать голову, брать себя в руки и не бояться придумать новый. А их придется делать много.

Вот, вкратце, манифест:

Теперь имея представление о четырех всадниках agile ценностей, познакомимся с agile-командой на практике.

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

Разделы ниже относятся к основным аспектам работы agile-команд:

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

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

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

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

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

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

Последняя роль — руководитель проекта. Как пишет Хайсмит (Highsmith, 2004a), роль руководителя проекта изменяется в случае применения agile-подхода. Руководители agile-проектов концентрируют внимание больше на лидерстве, а не на менеджменте. В некоторых agile-проектах лицо, выполняющее роль руководителя проекта, выступает также и в другой роли: нередко как разработчик, а иногда как владелец продукта.

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

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

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

Agile-команды демонстрируют приверженность бизнес-приоритетам двумя путями:

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

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

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

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

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

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

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

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