Практики Agile планирования

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

Планирование набегающей волны (Rolling-wave planning)

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

Это называется планированием набегающей волны:

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

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

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

Стратегии планирования

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

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

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

Например, если бы вы строили мост через реку, было бы смешно сказать что-то вроде: “Мы построим первый пролет, посмотрим, как это выйдет, и тогда мы решим, как построить оставшиеся пролет.” Типичный проект строительства моста был бы очень плановым, и все требования, а также конструкция моста, как правило, были бы достаточно детализированы до начала строительства моста. С другой стороны, что если в проекте была какая-то неопределенность? Предположим, что река призывала построить новый вид моста, который раньше никогда не строился, или была какая-то неопределенность относительно того, насколько стабильен фундамент для моста? Возможно, потребуется создать прототип и протестировать новую конструкцию в меньшем масштабе, чтобы устранить некоторую неопределенность и риск, прежде чем приступать к полномасштабной разработке.

Ключевые вещи для запоминания:

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

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

Спайки (Spikes)

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

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

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

Прогрессивная разработка (Progressive elaboration)

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

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

• На уровне проекта может быть потребность понять полный объем проекта оценить ресурсы, затраты и требуемый график. Однако это, как правило, может быть сделано на основе очень высокого уровня понимания требований без каких-либо подробностей.
• На уровне релиза может быть потребность в немного большей точности в предполагаемое время и усилие закончить релиз. Это могло бы потребовать более подробного понимания требований, но это также не должно требовать значительного количества деталей.

Наконец, на уровне спринта, как правило, существует две потребности, которые должны быть удовлетворены до начала спринта:

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

Однако, даже на уровне спринта, многие детали того, как требования будут выполнены, могут быть проработаны, пока спринт идет, без какого-либо заметного влияния на оценки спринтерского уровня.

Функциональная декомпозиция на основе ценности (Value-based functional decomposition)

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

• Для (предназначаются для клиента),
• Кто (заявление потребности или возможности)
• (Название продукта) – (категория продукта)
•  Это (ключевое преимущество для покупки)
• В отличие от этого (основная конкурентоспособная альтернатива)
• Наш продукт (заявление основного дифференцирования)

После того, как заявление о видении высокого уровня было сформировано, рекомендуется использовать функциональную декомпозицию для разбиения этого заявленного видения на функциональные возможности, которые потребуются для достижения этого общего видения. Функциональное декомпозирование становится особенно важным в крупных проектах, где могут быть сотни пользовательских историй. Он обеспечивает иерархический подход к определению требований, что может быть важным методом определения приоритетов требований. Без эффективного подхода к функциональному разложению, согласующемуся с общей ценностью, очень просто “потеряться в сорняках” отдельных требований или пользовательских историй и упустить из виду общую картину ценности, которую вы пытаетесь получить.