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

Анализ итерации проводился в 9:00 15 сентября. Высказаны следующие предложения:

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

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

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

1. Предположим, что в проекте оставшийся объем работы оценивается в 150 пунктов. В последних 10 итерациях команда имела скорость 10, 12, 13, 5, 14, 7, 6, 12, 16 и 14. Вас спрашивают, когда будет завершен проект. Как вы ответите на этот вопрос?

2. Как установлен срок в вашем текущем проекте — как конкретная дата (скажем, 18 сентября) или как диапазон? Почему?

3. В каком диапазоне итераций или дат будет завершен ваш текущий проект?

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

Глава завершается финальным набором правил применения agile-подхода к оценке и планированию в ваших проектах.

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

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

Чтобы план оказался полезным, он должен быть точным, однако мы допускаем, что первоначальные планы неточны. Одна из причин изменения плана — постепенное уменьшение неточности. Иными словами, первоначальный план может говорить, что в третьем квартале в проекте будет выполнена работа объемом 300–400 пунктов. Этот план впоследствии может оказаться более-менее точным (в августе выполняется работа объемом 305 пунктов), но он все равно неточен. В начале проекта такой план, скорее всего, служит основой для принятия решений. Позднее, однако, чтобы оставаться полезным, план уточняется, и мы можем сказать, что в сентябре в проекте будет реализовано 380–400 пунктов.

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

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

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

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