Agile: оценка и планирование проектов

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

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

Agile-подход к планированию

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

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

Мы зачастую не учитываем эти новые знания и не планируем возможность их получения. Как результат, процесс планирования строится на допущении о том, что нам уже известно все необходимое для получения точного плана. В мире разработки программного обеспечения такое случается редко, если вообще случается. Уорд Каннигем заметил, что «это больше планирование того, что вы хотите узнать, а не того, что [продукт] получится в конце» (Van Schooenderwoert, 2004).

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

Многоуровневость планирования

При постановке задач и их пересмотре важно помнить, что мы не можем видеть дальше горизонта и что точность плана быстро снижается по мере того, как мы все дальше уходим за черту, до которой видим. Допустим, вы стоите на палубе небольшого судна и ваши глаза находятся на высоте 2,7 м над уровнем воды. Расстояние до горизонта в этом случае составляет примерно 6 км[2]. Если вы планируете 30-километровое путешествие, то вам необходимо составить план на перспективу как минимум в пять раз дальше горизонта, который составляет 6 км. Поскольку вы не можете видеть дальше горизонта, нужно периодически осматриваться и корректировать свой план.

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

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