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

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

Резюме

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

Историю можно разбивать по типу данных, которые она поддерживает. Ее также можно разбивать на основе предусматриваемых операций. Распространенной практикой является подход к разбивке на основе CRUD-операций (создание, чтение, редактирование и удаление). Историю можно уменьшить с помощью выделения сквозных функций, таких как безопасность, регистрация и обработка ошибок. Также это можно сделать через игнорирование целевой производительности во время той итерации, в которой реализуется функционал истории. Целевую производительность можно выделить в самостоятельную историю и реализовать позднее. Многие истории описывают две и более потребности. Если такие потребности имеют разный приоритет, разбивайте истории по ним.

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

Наконец, помните, что иногда полезно объединять пользовательские истории, особенно в случае устранения ошибок, которые бывают слишком мелкими сами по себе.

Вопросы для обсуждения

1. Есть ли в вашем текущем или другом проекте пользовательские истории, которые трудно поддаются разбивке? Как бы вы подошли к их разбивке теперь?

2. К каким проблемам, на ваш взгляд, приводит разбивка истории на задачи с последующей придачей этим задачам статуса пользовательских историй?

Часть IV Составление календарных графиков

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

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

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

Глава 13 Основные аспекты планирования релиза

Ты импровизируешь. Ты адаптируешься. Ты преодолеваешь.

Клинт Иствуд в фильме «Перевал разбитых сердец»

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

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

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