Поскольку выходные и праздники сокращают количество рабочих дней в итерации, в некоторых итерациях количество планируемых рабочих дней может варьировать. В нашем примере Вадим отработал на два дня меньше, чем планировалось. Возможно, он болел. В то же время Саша отработала на один день больше запланированного. Предположительно она собиралась взять выходной, но передумала.
Строки в этой таблице обычно делают цветными: зеленый — для успешной сборки, красный — для неудачной сборки. Обратите внимание на то, что в колонке «Статус» указывается число успешных тестов, только если все тесты успешно пройдены. Если хотя бы один тест не пройден, то все тесты попадают в разряд неудачных. В случае провала одного из тестов не имеет значения, сколько тестов пройдено. Если написать, что из 100 тестов пройдено 99, то возникает соблазн считать, что, раз 99 % тестов пройдено, мы работаем хорошо. Во избежание этого я указываю в отчете число пройденных тестов, если они все пройдены, или, в противном случае, число непройденных тестов.
Анализ итерации проводился в 9:00 15 сентября. Высказаны следующие предложения:
Нам нужно, чтобы информирование об оценках и планах было частым, честным и двухсторонним. Диаграмма Гантта может быть полезным инструментом информирования о плане. Вместе с тем ее не следует детализировать больше, чем до уровня функций, а функции должны представляться как находящиеся в работе на протяжении всей итерации.
Диаграммы выгорания — главное средство представления информации о прогрессе, однако их зачастую дополняют диаграммой скорости на итерацию для команды разработчиков. Полезно представлять скорость в виде диапазона, а не одного числа. С этой целью удобно использовать скорость в последней итерации, среднюю скорость в предыдущих восьми итерациях и среднюю скорость в трех наименее результативных итерациях из предыдущих восьми. Эти три значения хорошо отражают то, что только что произошло, долгосрочное среднее значение и наихудший из возможных сценариев.
В некоторых проектах итоговые отчеты по итерациям могут быть полезными как для распространения текущей информации, так и в качестве документа, которым можно воспользоваться в будущем.
1. Предположим, что в проекте оставшийся объем работы оценивается в 150 пунктов. В последних 10 итерациях команда имела скорость 10, 12, 13, 5, 14, 7, 6, 12, 16 и 14. Вас спрашивают, когда будет завершен проект. Как вы ответите на этот вопрос?
2. Как установлен срок в вашем текущем проекте — как конкретная дата (скажем, 18 сентября) или как диапазон? Почему?
3. В каком диапазоне итераций или дат будет завершен ваш текущий проект?
Если вам все еще непонятно, почему работает agile-подход к оценке и планированию, то мы постараемся объяснить это в настоящей части. Она содержит всего одну главу, посвященную исключительно этому вопросу. В этой главе мы быстро освежим в памяти, в чем заключается цель планирования, и рассмотрим наиболее важные причины, по которым agile-оценка и agile-планирование обеспечивают успешное достижение данной цели.
Глава завершается финальным набором правил применения agile-подхода к оценке и планированию в ваших проектах.
Если вы хотите гарантию, купите тостер.
