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

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

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

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



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

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

    Image
    05 февраля 2020 в 15:54
    heart interface icon391

    Как высчитывать значения в Burn Down Chart в Scrum

    В это статье рассказано о том, как высчитываются параметры в Burn DownCharts в Scrum.

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

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

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

    Image
    Yevgeniy Ampleev
    arrow-up icon