Майк Кон - Agile: оценка и планирование проектов

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

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

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

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

Эти основные различия между планом релиза и планом итерации представлены в обобщенном виде в табл. 14.2.

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

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

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

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

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

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

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