Agile: оценка и планирование проектов - [55]

Пользовательские истории в табл. 13.1 рассортированы владельцем продукта по убыванию их ценности для первого релиза SwimStats. Владелец продукта может выбрать до 48 пунктов. Первоначально он выбирает первые восемь историй, включая «Как пловец я могу сравнивать свои результаты с национальными рекордами». Это составляет в сумме 46 пунктов, что довольно близко к согласованным предельным 48 пунктам.

Разработчики, однако, указывают на необходимость включения истории, получившей у владельца продукта низший приоритет: «Как системный администратор я могу конфигурировать права доступа и пользовательские группы». Эта история оценивается в три пункта, что увеличивает объем работы в релизе до 49 пунктов при плановых 48. Плановый объем в 48 пунктов — величина довольно приблизительная, а кроме того, есть еще дополнительная неделя после шестой итерации. При таких обстоятельствах вполне возможно пойти на увеличение объема до 49 пунктов.

Так или иначе, команда SwimStats не решается на увеличение объема до 49 пунктов. Если добавить трехпунктовую историю, то из релиза необходимо исключить как минимум один пункт. Владелец продукта принимает решение удалить историю «Как пловец я могу сравнивать свои результаты с национальными рекордами» на восемь пунктов. Это уменьшает релиз до 41 пункта. Владелец продукта мог бы добавить трехпунктовую историю «Как тренер я могу рассылать электронные письма всем пловцам команды», но он предпочитает воздержаться от этого. Если команда выполнит хотя бы один пункт раньше календарного графика, то он предпочтет вернуть назад исключенную восьмипунктовую историю. В результате окончательный план релиза принимает форму, приведенную в табл. 13.2.

Резюме

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

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

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

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

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

1. Каким является ваш текущий проект, ориентированным на сроки или на функции? Почему он именно такой?

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

Глава 14 Планирование итерации

Это серьезнейшая ошибка, строить теории до того, как получишь информацию.

Шерлок Холмс в «Скандале в Богемии»

Артура Конана Дойла

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

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

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

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