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

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

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

Планы ориентируются на функции, а не на задачи

Традиционный план в форме диаграммы Гантта, диаграммы PERT или разбивки работ сфокусирован на задачах, выполнение которых необходимо для создания продукта. Agile-план концентрируется на функциях, которые должны присутствовать в продукте. Это принципиальное отличие, которое заставляет команду думать о продукте на правильном уровне — на уровне функций. Когда функции разрабатываются итеративно, уменьшается потребность в предварительном обдумывании необходимых конкретных задач. В процессе осмысления работы для очередной итерации команда обдумывает или открывает все задачи по мере их необходимости. Еще важнее то, что команда думает о функциях, которые подлежат разработке. Мой коллега Джим Хайсмит (Highsmith, 2004b) утверждает, что «agile-планирование „лучше“ других потому, что оно ориентируется на функции (истории и т. п.), а не на задачи. Довольно легко спланировать целый проект, используя стандартные задачи, без реального понимания сущности создаваемого продукта. Когда планирование осуществляется на основе функций, команда намного лучше понимает продукт». На уровне задач планы многих проектов выглядят одинаково. Каждый agile-план конкретен по отношению к создаваемому продукту.

Небольшие истории поддерживают постоянство потока работы

Из теории массового обслуживания (Poppendieck and Poppendieck, 2003; Reinertsen, 1997) мы знаем о важности фокусирования на времени цикла — количестве времени, необходимого для чего-то от начала процесса до его завершения. В софтверном проекте время цикла — это время от начала работы команды над функцией до поставки этой функции пользователям. Чем короче время цикла, тем лучше.

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

Незавершенная работа ликвидируется в каждой итерации