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

Итоговый отчет в конце итерации

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

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

Контекст

Даты

Персонал

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

Рабочие дни

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

Показатели

Результаты ночной сборки

Цвет строк

Строки в этой таблице обычно делают цветными: зеленый — для успешной сборки, красный — для неудачной сборки. Обратите внимание на то, что в колонке «Статус» указывается число успешных тестов, только если все тесты успешно пройдены. Если хотя бы один тест не пройден, то все тесты попадают в разряд неудачных. В случае провала одного из тестов не имеет значения, сколько тестов пройдено. Если написать, что из 100 тестов пройдено 99, то возникает соблазн считать, что, раз 99 % тестов пройдено, мы работаем хорошо. Во избежание этого я указываю в отчете число пройденных тестов, если они все пройдены, или, в противном случае, число непройденных тестов.

Выгорание итерации

Скорость

Контент и оценка

Анализ итерации

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

Резюме

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

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

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

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

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

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

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

Часть VI Почему работает agile-подход к планированию

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

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

Глава 22 Почему работает agile-подход к планированию

Если вы хотите гарантию, купите тостер.

Клинт Иствуд в фильме «Новичок»

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