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

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

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

4. Выражайте неопределенность при представлении либо функциональности, либо даты. Ни один план не является полностью определенным. Обязательно включайте выражение неопределенности в составляемые планы релизов. Если объем новой функциональности зафиксирован, представляйте неопределенность в виде диапазона дат («Мы завершим работу в третьем квартале» или «Мы завершим работу через 7–10 итераций»). Если зафиксирована дата, представляйте неопределенность через набор поставляемых функций («Мы завершим работу 31 декабря, и продукт будет содержать по меньшей мере вот эти функции, но, возможно, не более, чем те новые функции»). Используйте более крупные единицы (итерации, месяцы, кварталы, например) по мере роста неопределенности.

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

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

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

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

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