Планирование

6.4. Диаграмма сгорания работ

Один из самых важных артефактов, которые использует Scrum-команда для контроля за запланированными показателями выполнения работ в течение спринта, - диаграмма сгорания работ (Burndown Chart) ( рис. 6.2).

Рис. 6.2. Диаграмма сгорания работ

Эта диаграмма показывает, сколько задач осталось до завершения запланированного периода времени на выполнение работ (спринта):

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

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

Оперативный анализ процесса сгорания задач должен проводиться по количеству оставшихся "пунктов" путем сравнения реального графика с идеальным:

• Если реальный график выше идеального - значит, команда отстает от плана.
• Если реальный график ниже идеального - команда опережает план.

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

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

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

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

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

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

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

6.5. Краткие выводы

В данной главе был подробно рассмотрен наиболее значимый и критичный для управления ожиданиями пользователей этап планирования процесса разработки программного обеспечения. Мы уделили внимание методам и профильным техникам планирования для работы с гибкими процессами. В частности, рассмотрели планирование методом "набегающей волны" и последующее поэтапное уточнение планов. Применение этих методик в Scrum позволит выстроить работу, начиная с "правильной" работы с менеджментом, на предмет однозначного понимания объема необходимых ресурсов для достижения поставленных результатов и заканчивая техниками оценки трудоемкости задач, к примеру, техникой Planning Poker.

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

В "Этапы и мероприятия Scrum" мы более подробно поговорим о контрольных мероприятиях, используемых в Scrum для управления процессом разработки программного обеспечения.