Практика применения Cumulative Flow в контексте Scrum и SAFe | Амплеев Евгений - Agile Coach / Full stack web developer. Персональный блог.
Читаете:
Практика применения Cumulative Flow в контексте Scrum и SAFe
Поделиться:

Практика применения Cumulative Flow в контексте Scrum и SAFe

Avatar
Автор статьи: Yevgeniy Ampleev
13 декабря 2019 в 08:54
Image

В этой статье я планирую рассказать как на своей практике мы применяем Cumulative Flow Chart в Scrum в процессе работы по фреймворку SAFe

Начну, пожалуй, со ссылки на такую статью - здесь, на мой взгляд, хорошо описано ее назначение в стандартном виде, рекомендую изучить перед прочтением моей статьи. Ниже же я опишу как мы ее адаптировали для Scrum-процесса(изначально она используется в Kanban) и какие проблемы она помогает нам решать при работе по спринтам.

Ранее, в статье о Burn Down Charts я уже говорил о том, что там мы видим появление новой работы и сгорание старой. Проблема Burn Down Chart в том, что, в отличие от Cumulative Flow Chart, на ней мы не видим движение Пользовательских Историй по статусам. Когда же мы начинаем наблюдать движения по статусам в Cumulative Flow Chart, мы начинаем видеть ежедневные изменения (Burn Down Chart может не изменяться несколько дней и в некоторых контекстах это может быть вполне нормально) и можем заметить более тонкие проблемы.

Вот как это может выглядеть в динамике(на изображении диаграмма построенная на реальных данных).

Image


Image


В данном примере мы видим следующее

  • Первые 7 дней спринта в тестировании находится очень малый объем работ и он не меняется
  • Из DOR (здесь это черновик) в работу Пользовательские Истории уходят достаточно равномерно - это хорошо.
  • Также как и на Burn Down, мы видим, что согласно тенденции Пользовательские Истории не будут выполнены к концу спринта

Эти 3 наблюдения в совокупности приводят к следующему выводу. Здесь явно еще на ранних этапах (где-то во второй-третий день спринта) нужно было Скрам Мастеру обратить внимание на слой "Тестирование", который слишком мал и не меняется достаточно долго(убедиться в чем причина). Можно предположить, что объем работы готовой для тестирования невозможно протестировать по каким-либо обстоятельствам, но тогда это означает, что тестировщики простаивают, а значит,как минимум стоит повнимательнее их послушать на ближайшем стендапе.

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

В целом, не стоит забывать, что все же метрики нужно правильно интерпретировать. Уметь видеть действительно системные проблемы если они есть и не воспринимать за проблемы то, что в вашем контексте может быть даже положительным признаком



Всего комментариев: 1
  1. Sarah Priestly
    Yevgeniy Ampleev
    19 сентября 2023 в 19:25
    тест
    Ответить

Добавить комментарий
divider graphic

Возможно, вам будет интересно

Image
04 февраля 2020 в 15:59
heart interface icon2905

Специфика работы Agile-команды в SAFe относительно Scrum на практике

В данной статье я постараюсь описать основные и, наиболее яркие отличия фреймворка SAFe относительно SCRUM, которые я заметил за год работы в SAFe.

Image
Yevgeniy Ampleev
Image
12 декабря 2019 в 08:54
heart interface icon2421

Практика применения Burn Down Charts в контексте SAFe и Scrum

В этой статье я постараюсь рассказать о своем опыте применения диаграмм сгорания (Burn Down Charts).

Image
Yevgeniy Ampleev
arrow-up icon