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

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

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

Каждый столбик на рис. 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. Перед началом четвертой итерации владелец продукта удаляет работу из плана релиза. Как результат, нижняя часть столбика смещается вверх выше нулевой линии. Во время этой итерации команда демонстрирует хороший прогресс. Далее план релиза больше не меняется, и команда продвигается вперед вплоть до завершения работы.