Agile: оценка и планирование проектов - [84]
1. Скорость команды находится на ожидаемом уровне. Это видно по выгоранию, о котором говорит расположение вершин первых двух столбиков.
2. Был добавлен значительный объем работы. Это видно по положению нижней части второго столбика. Предположительно работа была добавлена потому, что она должна привести к созданию более ценного релиза. Вместе с тем полезно обратить внимание на темп изменения объема этого проекта — к нему было добавлено больше, чем завершено. Возможно, это не такой уж тревожный факт, все зависит от того, сохранится ли тренд и насколько важна первоначальная целевая дата завершения релиза.
3. Суммарный объем работы, оставшейся в релизе, больше ее объема в начале проекта. Это следует из того, что общая высота второго столбика больше высоты первого столбика.
Очевидно, что данное представление диаграммы выгорания значительно более наглядно. Его недостаток заключается в том, что смысл диаграммы не ясен сразу же.
Посмотрим теперь на вторую и третью итерации проекта на рис. 19.4. Во второй итерации команда вновь достигла целевой скорости. Владелец продукта опять добавил работу, однако на этот раз прибавка не такая большая, как в предыдущей итерации.
Что произошло в третьей итерации? При ее выполнении скорость снизилась до 20. Это может быть результатом недооценки некоторых историй, включенных в итерацию, болезни или ухода в отпуск какого-нибудь члена команды либо переоценки части оставшихся работ. Команда могла выполнить плановый объем работы 30 пунктов, однако повышение оценок некоторых оставшихся историй привело к тому, что чистый прогресс составил 20 пунктов вместо 30.
Однако самый интересный момент, связанный с третьей итерацией, показан в нижней части четвертого столбика. Во время этой итерации владелец продукта удалил функцию из релиза. При выпуске релиза проект по-прежнему содержит больше пунктов, чем было запланировано первоначально. Такой вывод следует из того, что столбик все еще находится ниже нулевого уровня. Вместе с тем на этом этапе проект содержит меньше запланированных пунктов, чем было в начале предыдущей итерации. При этом не имеет значения, какие функции удалялись — те, что были изначально в плане релиза, или те, что были добавлены владельцем продукта в предыдущих итерациях. Приоритизация работы — прерогатива владельца продукта, который может добавлять и удалять функции по своему усмотрению. Чистый эффект показан в нижней части столбика выгорания.
При построении диаграммы выгорания такого типа нужно помнить четыре простых правила.
• Каждый раз, когда работа завершается, верхняя часть столбика понижается.
• Когда работу переоценивают, верхняя часть столбика смещается вверх или вниз.
• Когда добавляют новую работу, нижняя часть столбика смещается вниз.
• Когда работу удаляют, нижняя часть столбика смещается вверх.
Посмотрим на гистограмму выгорания релиза реального проекта, которая представлена на рис. 19.5. Здесь мы видим, что команда демонстрирует хороший прогресс в течение первых двух итераций. Владелец продукта добавляет небольшой объем работы перед началом второй итерации, что довольно часто случается. Во время третьей итерации команда обнаруживает, что некоторые пользовательские истории недооценены, и проводит переоценку части оставшейся работы. Это приводит к повышению верхней части четвертого столбика на рис. 19.5. Перед началом четвертой итерации владелец продукта удаляет работу из плана релиза. Как результат, нижняя часть столбика смещается вверх выше нулевой линии. Во время этой итерации команда демонстрирует хороший прогресс. Далее план релиза больше не меняется, и команда продвигается вперед вплоть до завершения работы.
Хотя я считаю, что гистограмма выгорания релиза более наглядна (и, следовательно, зачастую более полезна), чем традиционная диаграмма выгорания, существует пара ограничений ее использования. Во-первых, гистограмму выгорания труднее понимать, поэтому в новых командах я всегда начинаю работу с более простой традиционной диаграммы. Во-вторых, гистограмма выгорания предназначена только для тех организаций, которые достигли достаточной зрелости и могут удержаться от споров о том, чтó находится выше линии, а чтó ниже. При первых же признаках спора такого характера я говорю всем участникам проекта, что мы не можем использовать гистограмму и возвращаемся к традиционной диаграмме выгорания.
Диаграмма парковки
Джефф Делюка (Deluca, 2002) предложил еще один способ визуализации процесса реализации командой запланированных функций релиза. На рис. 19.6 показан вариант того, что Делюка называет диаграммой парковки. Диаграмма парковки содержит большой прямоугольник для каждой темы (или группы пользовательских историй) в релизе. В каждом прямоугольнике указано название темы, количество историй в этой теме, количество пунктов или идеальных дней для историй и процент реализованных пунктов.
В прямоугольнике «Гендерно-возрастная информация пловцов» на рис. 19.6 видно, что эта тема включает в себя восемь историй, которые оцениваются в сумме в 36 пунктов. Из этого числа уже выполнено 18 пунктов, поскольку, как мы знаем, реализовано 50 % функции. Мы не можем сказать, какие именно пользовательские истории реализованы. Отдельные прямоугольники на диаграмме можно даже выделить цветами, чтобы показать, реализована ли тема, идет ли ее реализация в соответствии с календарным графиком, требует ли эта тема повышенного внимания или значительно отстает от календарного графика.
