Начну, пожалуй, со ссылки на такую
статью - здесь, на мой взгляд, хорошо описано ее назначение в стандартном виде, рекомендую изучить перед
прочтением моей статьи. Ниже же я опишу как мы ее адаптировали для Scrum-процесса(изначально она
используется в
Kanban) и какие проблемы она помогает нам решать при работе по спринтам.
Ранее, в статье
о Burn Down Charts я уже говорил о том, что там мы видим появление новой работы и сгорание старой.
Проблема Burn Down Chart в том, что, в отличие от Cumulative Flow Chart, на ней мы не видим движение
Пользовательских Историй по статусам. Когда же мы начинаем наблюдать движения по статусам в Cumulative Flow
Chart, мы начинаем видеть ежедневные изменения (Burn Down Chart может не изменяться несколько дней и в
некоторых
контекстах это может быть вполне нормально) и можем заметить более тонкие проблемы.
Вот как это может выглядеть в динамике(на изображении диаграмма построенная на реальных данных).
В данном примере мы видим следующее
- Первые 7 дней спринта в тестировании находится очень малый объем работ и он не меняется
- Из DOR (здесь это черновик) в работу Пользовательские Истории уходят достаточно равномерно - это хорошо.
- Также как и на Burn Down, мы видим, что согласно тенденции Пользовательские Истории не будут выполнены к
концу спринта
Эти 3 наблюдения в совокупности приводят к следующему выводу. Здесь явно еще на ранних этапах (где-то во
второй-третий день спринта) нужно было Скрам Мастеру обратить внимание на слой "Тестирование", который
слишком
мал и не меняется достаточно долго(убедиться в чем причина). Можно предположить, что объем работы готовой
для
тестирования невозможно протестировать по каким-либо обстоятельствам, но тогда это означает, что
тестировщики
простаивают, а значит,как минимум стоит повнимательнее их послушать на ближайшем стендапе.
Если говорить о практике применения, то я, к примеру, публикую ежедневно в чате команды все метрики перед
стендапом с упоминанием всей команды.
В целом, не стоит забывать, что все же метрики нужно правильно интерпретировать. Уметь видеть действительно
системные проблемы если они есть и не воспринимать за проблемы то, что в вашем контексте может быть даже
положительным признаком