Узнайте о CFD диаграмме в Канбан, ее значении, способах чтения и применении для эффективного управления проектами.

Cumulative Flow Diagrams, она же накопительная диаграмма потока, — это визуальный инструмент, который показывает здоровье проекта на разных этапах разработки.

Главное в графике — динамика. Накопительная диаграмма потока позволяет увидеть события в прошлом. CFD — это индикатор.

Время (Cycle Time). Количество задач (WIP). Время от появления задачи до поставки (Lead Time). Количество задач за промежуток (Throughput).

Cumulative Flow Diagrams, она же накопительная диаграмма потока, — это визуальный инструмент, который показывает здоровье проекта на разных этапах разработки. Все ли в нем идет так, как планировалось. Диаграмма подскажет, если что–то нужно подкрутить.

CFD диаграммы — это инструменты метода Канбан.

Они помогают:

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

• увидеть, на каком этапе разработки появляются проблемы;

• оценить результаты экспериментов;

• понять, как часто стоит проводить эксперименты.

Чтобы построить Cumulative Flow Diagram, надо каждый день следить, сколько задач находится на каждом этапе работы. Эти результаты мы и будем отмечать на графике.

Сам график состоит из:

• Оси Х — это время работы

• Оси Y — это количество задач/элементов работы на каждом этапе.

Проще говоря, горизонтальная ось — ось времени. Вертикальная ось — число задач на каждом этапе работы по дням.

Допустим, начинаем строить диаграмму с понедельника. Тогда отмечаем понедельник на оси Х. На оси Y будем отмечать числа. А на пересечении X и Y — число задач на каждом этапе.

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

И вот, что мы можем получить в итоге:

График на примере построен для процесса из четырех этапов: очередь, в процессе, тестирование и выполнено.

• Зеленым цветом выделена выполненная часть задач. И это та самая ценность, которую получил и распознал для себя клиент. Понятно, что эта область графика должна постоянно расти.

• Желтым цветом отмечено то, что тестируется.

• Голубым — задачи в процессе, то, что разрабатывается в данный момент.

• Фиолетовый — задачи из бэклога или очередь из задач. Она может постепенно уменьшаться.

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

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

• Верхняя линия — это всегда накопительный вход в процесс. Соответственно нижняя линия — это накопительный выход из процесса.

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

• Линии на CFD всегда должны идти либо вверх, либо параллельно оси Х.

Все знают, что в CFD диаграмме масса полезной информации, но при этом редко ее используют. Почему? Да просто не знают, как извлечь из нее эту самую пользу.

Эти правила помогут вам правильно прочитать CFD диаграмму.

• Главное в графике — динамика. Наблюдайте за изменениями показателей. Нет смысла делать вывод на данных, которые получены в один момент времени.

• Накопительная диаграмма потока позволяет увидеть события в прошлом. Поэтому по ней нужно строить прогнозы и предположения.

• CFD — это индикатор изменений. Вы можете запланировать улучшения своей канбан–системы и с помощью диаграммы наблюдать за изменениями показателей.

• Время (Cycle Time). Сколько времени задача была в разработке: с момента, когда ее взяли в работу и до того как ее принял клиент.

• Количество задач (WIP). Те, над которыми идет одновременная работа. При этом можно оценить, сколько задач находится в каждой стадии. Если заметили резкий рост количества задач и времени поставки — это важный сигнал, что с процессом что–то не так. И надо бы разобраться.

• Время от появления задачи до поставки (Lead Time). Здесь учитывается и время разработки, и время ожидания в очереди.

• Количество задач, которые команда может реализовать за определенный промежуток времени (Throughput).

Эти показатели помогут предсказать, что может произойти с системой, командой или даже компаний, если изменится одна или 2-3 метрики.

Рост количества задач (WIP) автоматически означает и увеличение времени поставки результата, и поставку ценности для клиентов или пользователей. Гораздо сложнее становится сделать что–то полезное быстро, даже когда очень надо.

Рост показателя WIP неизбежно приводит к многозадачности, членам команды приходится часто переключаться между разными элементами работами. Эффективность идет вниз.

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

Если на этапе разработке вы видите большой WIP, то можно предположить, что задач в разработке находится больше, чем на тестировании. Можно сделать вывод, что с тестированием все отлично. И отправиться искать виноватых среди разработчиков.

И вот тут есть риск нарваться на ошибку. Большое количество задач на этапе разработки может говорить и о том, что большое количество задач пребывает в стадии «готово к тестированию». Но вот тестировщики завалены работой, а когда они–таки доступны, то заняты тем, что начали раньше.

Чтобы быстрее разбираться с этими моментами, на графике можно отразить еще одну линию, которая будет отделять задачи в разработке от тех, что готовы к тестированию. Без этих данных диаграмма CFD будет только показывать, что проблема есть и надо анализировать глубже.

Вдруг, в один не самый прекрасный день, вы видите на CFD диаграмме, что все линии становятся параллельны оси Х. Первым делом надо проверить, не связано ли это с праздниками/новогодними каникулами или какими–то праздничными событиями внутри компании. Тут все просто, если никто не работал в этот период, на графике будет остановка работ.

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

• Могло сломаться тестовое окружение и все кинулись его восстанавливать.

• Команду срочно перебросили на другой проект и текущий пока забросили.

• Появился какой–то блокер, и вся команда занялась его устранением.

Если на диаграмме видно, что поставка ценности происходит слишком быстро, это может служить предупреждением: а нет ли проблем с качеством?

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

Самое время спросить себя: почему команда стала такой быстрой? А почему раньше так не могли?

• Первый вариант, что команда просто не актуализировала задачи и процессы на доске.

• Второй вариант, что команда под влиянием клиента или чего–то еще отправила в релиз сразу очень много задач. Но не факт, что все они реально выполнены. Здесь велик риск, что эти полуготовые задачи вернутся обратно и, возможно, в не самый удачный момент.

Если же задачи выполняют слишком медленно, то линия «Готово» будет долго оставаться неизменной и проходить близко к горизонтальной оси. Однако в конце мы увидим резкий рост этой линии, готовые задачи посыпятся как из рога изобилия.

О чем это может говорить:

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

• Либо проблема в самой процедуре поставки или релизов. Что–то идет слишком сложно и со скрипом.

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

• Это может быть проблема в самом проекте.

• Либо вы договорились с клиентом о внесении изменений в процессе работы и они случились. Список задач снова наполнился.

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

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

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

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