Agile: Оценка и планирование проектов - Майк Кон

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

Для того чтобы понять, как это работает, приведу пример. На рис. 19.4 по плану релиз должен включать объем работы, равный 240 пунктам. В начале первой итерации на диаграмме выгорания находится один столбик, вытянутый от 0 до 240. Как и прежде, команда ожидает, что ее скорость будет равна 30, а работу удастся завершить за восемь итераций. В первой итерации команда достигает ожидаемой скорости, и поэтому верхняя часть второго столбика находится на уровне 210. Владелец продукта, однако, решил, что в релизе должно быть больше функций, чем считалось первоначально. Работу, которую решили добавить к релизу, оценили в 50 пунктов. По этой причине столбик второй итерации опустился ниже нулевой линии и стал занимать пространство от –50 до 210. Другими словами, объем работы в релизе теперь составляет 260 пунктов, т. е. больше, чем вначале. К концу второй итерации, глядя на рис. 19.4, можно отметить три интересных факта.

1. Скорость команды находится на ожидаемом уровне. Это видно по выгоранию, о котором говорит расположение вершин первых двух столбиков.

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

3. Суммарный объем работы, оставшейся в релизе, больше ее объема в начале проекта. Это следует из того, что общая высота второго столбика больше высоты первого столбика.

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

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

Что произошло в третьей итерации? При ее выполнении скорость снизилась до 20. Это может быть результатом недооценки некоторых историй, включенных в итерацию, болезни или ухода в отпуск какого-нибудь члена команды либо переоценки части оставшихся работ. Команда могла выполнить плановый объем работы 30 пунктов, однако повышение оценок некоторых оставшихся историй привело к тому, что чистый прогресс составил 20 пунктов вместо 30.

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

При построении диаграммы выгорания такого типа нужно помнить четыре простых правила.

• Каждый раз, когда работа завершается, верхняя часть столбика понижается.

• Когда работу переоценивают, верхняя часть столбика смещается вверх или вниз.

• Когда добавляют новую работу, нижняя часть столбика смещается вниз.

• Когда работу удаляют, нижняя часть столбика смещается вверх.

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

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

В прямоугольнике «Гендерно-возрастная информация пловцов» на рис. 19.6 видно, что эта тема включает в себя восемь историй, которые оцениваются в сумме в 36 пунктов. Из этого числа уже выполнено 18 пунктов, поскольку, как мы знаем, реализовано 50 % функции. Мы не можем сказать, какие именно пользовательские истории реализованы. Отдельные прямоугольники на диаграмме можно даже выделить цветами, чтобы показать, реализована ли тема, идет ли ее реализация в соответствии с календарным графиком, требует ли эта тема повышенного внимания или значительно отстает от календарного графика.