В этой статье я планирую рассказать как на своей практике мы применяем Burn Down Chart в процессе работы по фреймворку SAFe
Начну, пожалуй, с самого интересного. А именно с того, что использование этой диаграммы в SAFe не должно иметь никакой специфики относительно использования этой диаграммы в SCRUM. Или должно?
SAFe у нас отличается наличием такой роли, как RTE, в отличие от SCRUM, где ее нет. Burn Down Chart - это инструмент отслеживания объема работ в спринте и он необходим прежде всего для SCRUM-команды, а не для кого-либо извне, не так ли?
Таким образом, все же перейду к тому как мы используем Burn Down Chart, не смотря ни на что, и, находясь по-прежнему внутри фреймворка SAFe.
Я нахожусь в роли Scrum Master и стараюсь высвечивать эту диаграмму ежедневно для всей Dev Team. Средство, которое я использую - это командный чат, упоминание всей команды через "@", скриншот текущего состояния диаграммы. Упоминание всей команды - это достаточно тонкий инструмент и важно использовать его как можно реже(ведь, мы, Скрам Мастера, должны помогать команде работать в комфорте и с минимально возможной расфокусировкой, не так ли?)
В итоге команда ежедневно видит текущее состояние спринта и способна отследить следующие события
- Появление незапланированной работы
- Долгое зависание задач в незавершенном статусе
- Чрезмерное закладывание рисков
- Понимание - в правильном ли темпе идет работа
Далее я постараюсь раскрыть каждое из этих событий и привести примеры из своей практики.
Появление незапланированной работы
На данной диаграмме очень хорошо видно, как появляется новая работа (во второй вторник двухнедельного спринта).
Случай из практики: "Разработчик, как член scrum-команды, разделяющей принципы agile, классно взаимодействует с Product-ом напрямую. Product говорит ему, что вот это надо запилить быстренько, ты же сам понимаешь, тут быстро и риски минимальные.
Разработчик классный, он знает все про agile и про важность доставки бизнес-ценности, идет закидывает на доску историю из беклога, оценена она командой в 6 sp.
Остальная часть команды (кроме разработчика и Product-а) замечает это на утреннем апдейте диаграммы. На стендапе команда принимает решение как быть с этой ситуацией. Вероятнее всего, история выкидывается из спринта, Product-у и Разработчику команда дает понять, что так делать нельзя, продакт может поставить данную историю в следующий спринт при необходимости.
Конечно, в идеале команда должна заметить появление новой работы на стендапе и без диаграммы. Но диграмма является хорошим индикатором, который сводит риски незаметить такое важное для всей команды изменение к минимуму.
Здесь важно понимать, что сценарий мог пойти по-разному в зависимости от уровня команды. В крутых командах Product Owner врядли так сделал бы, а если и сделал бы, то аргументировал не тем, что «это можно быстренько запилить», а тем, что «я оцениваю в 55% вероятность того, что если это запилить сейчас, то может увеличить нашу прибыль на 20% в следующем месяце» или еще какой-либо измеримой метрикой.
Долгое зависание задач в незавершенном статусе
Здесь мы видим, что очень долго работа не завершается даже частично. Это может сигнализировать о разных проблемах, перечислю некоторые из них
Плохая декомпозиция задач
Очень часто начинающие команды говорят о невозможности декомпозиции. У них все сгорает в последний день, работа не распараллеливается и т.д. Конечно, с этим необходимо работать Скрам Мастеру и объяснять ценность декомпозиции команде.
Не оптимально сформулированный DOD
DOD (Definition of Done) - описание критериев готовности User Story в спринте. Иногда их вообще нет или они описаны очень абстрактно. Это вполне может быть проблемой, котороую, естественно, должен помочь решить Скрам Мастер
Чрезмерное закладывание рисков
В этом случае мы видим ситуацию когда команда перезаложила риски.
Возможно, какая-то история была переоценена. Возможно, это более системная проблема и необходимо увеличивать объем работы при планировании спринта. В любом случае, данная ситуация не корректна. Ведь бизнес планировал что будут реализованы именно задачи спринта и именно к концу спринта. В зависимости от того как были спланированы зависимости, здесь вероятнее всего придется проводить встречи для корректировки ожиданий.
На моей практике такое было когда находилось решение более быстрое, чем обсуждалось при оценке. Обсуждали всей командой какую историю сможем закрыть до конца спринта и на ретроспективе договорились, что будем стараться смотреть код при груминге. Выяснилось, что достаточно было просто заглянуть в код чтобы понять, что решение сильно проще.
Понимание - в правильном ли темпе идет работа
Здесь я хотел бы обратить внимание на графически неудачные способы отображения Burn Down Chart
В верхней части изображения приведен пример не самого удачной графической реализации по двум причинам, которые я изложу ниже.
Не заметно попадание новых SP в спринт
Здесь, на верхней диаграмме, практически не заметно, что добавилась незапланированная работа. На нижней это более наглядно.
Не корретно отображается относительный остаток работ
Согласно верхней диаграмме осталось работать еще 3 дня. По факту их 2, в выходной, возможно, кто-то планирует отдохнуть.
Конечно, кому-то такие мелочи покажутся не значительными. Но надо понимать, что каждый член команды всего лишь краем глаза вpглянет на эту диаграмму и она должна донести максимум полезной информации.
