Что такое накопительная диаграмма потока (Cumulative Flow Diagram – CFD)
Как быстро оценить, что происходит в проекте или работе над продуктом.
Один из графиков, который даёт возможность быстро оценить, что происходит в проекте или работе над продуктом – это Накопительная диаграмма потока (Cumulative Flow Diagram – CFD). С одной стороны на графике можно найти стандартную для проекта информацию – сколько работы выполнено, сколько задач осталось, темп выполнения проекта. Это основные метрики. С другой стороны, понимая сущность графика вы сможете увидеть все типы проблем, с которыми может столкнуться команда. Именно в этом заключается реальная польза графика.
Механизм графика очень прост. Горизонтальная ось – это ось времени. На вертикальной оси мы обозначаем количество задач на каждом этапе процесса в соответствующий день.
Оранжевая область на графике показывает количество выполненных задач – естественно ожидать, что она будет постоянно расти.
Зелёная и серая области отображают количество задач в тестировании и разработке, а их суммарная ширина показывает объем одновременно выполняемой работы. Если мы обеспечиваем стабильную загрузку команды, то ширина этих областей будет оставаться достаточно стабильной, а сами они постепенно будут подниматься выше, за счет накопления выполненной работы.
Голубая область – это количество задач находящихся в очереди. В данном случае она постепенно, худеет, но её верхняя граница остаётся неизменной – то есть объем работ не изменился.
График выше, как и все последующие, построен для процесса, состоящего из 4 этапов: очередь, разработка, тестирование и готово.
Замечу, что на графике обе стадии разработки суммируются и нет разницы между активными задачами и теми, что ожидают тестирования в колонке Разработка / Выполнено. В большинстве случаев такое разделение не нужно, однако чуть позже мы рассмотрим случай, когда оно будет полезным.
Информация на накопительной диаграмме
Ещё раз взглянем на график, чтобы посмотреть какую полезную информацию можно на нём найти
Во-первых, сразу можно отметить изменение объема работ – изменение верхней границы голубой области. Во-вторых, увидеть как менялось количество элементов в работе (Work in Progress – WiP) и каково среднее время поставки (Production Lead Time – среднее время, необходимое для выполнения одной задачи).
К текущему моменту выполнено около половины проекта и мы можем получить приблизительный срок окончания проекта. Естественно, он будет меняться при изменении количества задач или времени поставки.
Стоит заметить, что с помощью графика можно получить лишь приблизительные значения для WiP и времени поставки. Однако, даже эти значения позволяют получить полезную информацию, если отслеживать их изменение во времени. Их резкий рост – это отличный сигнал к тому, чтобы разобраться что происходит с процессом.
Всего за несколько секунд мы получили достаточно много полезной информации.
Очень нечасто вы будете видеть столь идеальный график. И это хорошие новости. Если график всегда стабильный и гладкий вы можете получить ту информацию, о которую мы только что обсудили, но реальная магия CFD проявляется в тот момент, когда в проекте возникают проблемы.
Растущий WiP
На графике видно, что ширина зелёной и серой областей растёт со временем. Это индикатор проблемы – количество элементов “в работе” постоянно увеличивается. Увеличение WiP также означает увеличение времени поставки. Увеличивается не только время доставки ценности потребителю (Time To Market – TTM), но всё сложнее становится сделать поставку чего-то быстро, когда это необходимо.
Но это ещё не самое плохое. Хуже всего то, что увеличение WiP приводит к увеличению многозадачности и частому переключению контекста, что делает работу команды менее эффективной.
Можем ли мы быть уверены в наших выводах? Не совсем. Мы исходим из предположения, что команда не изменялась, что те же самые люди работают над проектом аналогичное время. Если эта диаграмма для постоянно растущей команды, тогда график выглядит хорошо. Этот график также может отражать растущее количество заблокированных задач, что также является проблемой, но отличной от описанной выше.
В любом случае подобный график – это повод для дальнейшего изучения, а не для формирования преждевременных выводов. Не забывайте об этом и при рассмотрении следующих примеров.
Ещё один интересный вывод относительно представленного графика – мы не можем глядя на него выяснить корневую причину увеличения WiP. Ни этап разработки, ни этап тестирования не сохранили свою стабильность. Требуется дальнейшее изучение происходящего в команде.
Большой WiP на этапе разработки
В этом случае количество задач в разработке существенно больше, чем в тестировании. Какой можно сделать вывод? У нас нет проблем в тестировании. Если тестирование включает в себя устранение багов (что случается достаточно часто), мы можем говорить о хорошем качестве разработки. И если мы начнём искать виновного, то стоит отправиться к разработчикам. Не так ли?
И здесь мы можем ошибиться. Конечно описанное – это один из вариантов, который объясняет подобный график. Однако возможна ситуация, когда большое число задач находятся в стадии “готово к тестированию”, но доступность тестировщиков очень низкая и когда они доступны, то сосредоточены на работе, которую начали ранее.
Как мы можем узнать это? Никак, до тех пор пока у нас не будет больше информации. На самом деле нам может помочь ещё одна линия, которая отделит задачи “в разработке” от задач готовых к тестированию. Без этой информации CFD лишь показывает наличие проблемы и призывает к более глубокому анализу. Собственно в этом и есть основное назначение графика.
Ступеньки в поставке
Другая разновидность похожей проблемы изображена на следующем графике.
Первое, что можно заметить на графике – это ступеньки на оранжевой линии. Чаще всего они появляются на последней стадии, которая обычно отвечает за этап поставки, которая происходит на регулярной основе, например еженедельно или раз в две недели. В этом случае WiP и время поставки (Production Lead Time) будут сильно зависеть от частоты поставки.
Вторая особенность – это заметное увеличение задач, которые находятся в тестировании, ширина зелёной линии растёт с каждым релизом.
Это может означать, что в процессе проблема с качеством и команде сложно достигнуть состояния когда исправлены все баги связанные с задачей. Возможно разработчики не уделяют достаточно внимания исправлению багов и гораздо охотнее берутся за новые задачи. Тестировщики вынуждены одновременно проверять новые задачи и напоминать о существовании незакрытых задач.
Другая возможность, объясняющая, рост задач в тестирование – это плохая организация процедуры поставки, которая не позволяет выпускать в релиз все готовые к поставке задачи.
В который раз мы не можем сразу указать корневую причину проблемы, но у нас есть подсказки, позволяющие начать анализ.
Остановка в работе
Подобное периодически случается почти во всех командах, все линии становятся параллельными оси Х. Что происходит? Первое, что стоит проверить – это наличие официальных праздников или какого-то грандиозного события в компании, которые приходятся на данный период. Если в это время никто не работал, то это отличное объяснение для графика.
Если же команда работала над проектом, но график показывает, что ни одна из задач не была выполнена – это скорее всего говорит о наличии серьёзной проблемы. Возможно было сломано тестовое окружение и все занимались его восстановлением. Может быть команда была срочно переброшена на другой проект или возник блокер в устранении которого была занята вся команда.
В любом случае, похоже, что критическая ситуация уже решена и команда вернулась к привычной скорости разработки
Где поставка?
Этот график похож на предыдущий, но имеет два существенных отличия. Во-первых, только 2 линии перестали расти, а линия разработки продолжает рост. Во-вторых, линии тестирования и поставки остаются плоскими.
Последнее предполагает, что проблема до сих пор не решена. В чем же может заключаться проблема? Похоже, что команда не испытывает проблем с началом работ над новыми задачами. В то же время они не могут начать тестирование, а также не могут ничего поставлять. Одна из возможных гипотез заключается в наличии серьёзных проблем с тестовым окружением или с тестировщиками.
В первом случае нет технической возможности проверить, что всё работает в соответствии с требованиями. Во втором, похоже, что что-то плохое случилось с нашим единственным тестировщиком (если бы их было несколько, то мы бы видели какой-то прогресс). Существует и другая подсказка. Похоже, что разработчиков не заботит эта ситуация. Они начинают и возможно заканчивают свои задачи как будто ничего не произошло.
Сначала разобраться с проблемой поставки и обсудить взаимодействие в команде. Чувствуется наличие глубокой проблемы в коммуникации.
Быстрая поставка
Так же как предыдущий график говорит о проблемах с совместной работе, новый предупреждает о проблемах с качеством.
Линия разработки идёт вверх стабильным и предсказуемым образом. Линия тестирования не так хороша, не говоря уж о линии “Выполнено”.
Сначала, мы видим постепенный рост количества задач в разработке (этот случай уже разобран ранее) и совершенно внезапно всё возвращается к идеалу. В самом конце удивительно мало задач “в работе” и большое количество готовых задач.
Как получилось, что ранее такая скорость поставки была невозможна? Почему команда внезапно стала такой быстрой? Конечно разработчики могли не поддерживать доску в актуальном состоянии и в какой-то момент они поняли что выполненных задач существенно больше.
Но более вероятный сценарий, что команда под давлением отправила в релиз все задачи, которые казались выполненными. Если это правда, то проблема не решена и она обязательно вернётся через некоторое время, чтобы укусить их за задницу.
Огромный WiP – это проблема?
Подобный график встречается на удивление часто. Линия разработки начинает расти очень агрессивно и к середине периода начата работа над 80% задач. Тестирование чуть запаздывает. Поставка просто ужасна в начале, но в конце все задачи внезапно оказываются выполненными. Мы видим очень большой WiP в середине графика и очень маленький по его краям. Кроме того, похоже, что в последний день поставлено всё, что было в планах.
Скорее всего задачи выполнены полностью, не смотря на то, что график так напоминает предыдущий.
Какой-же диагноз можно поставить в этом случае? Time boxing! Это один из классических случаев визуализации типичной для итеративной поставки. Так выглядит одна из итераций команда, если она успешно справляется с планирование и имеет стабильную скорость поставки.
Тогда не имея ограничений для WiP внутри time box, каждый член команды делает свою работу. Разработчики быстро начинают большое количество задач не имея других ограничений кроме необходимости закончить все задачи к концу итерации. Когда бэклог итерации исчерпан команда фокусируется на завершении задач, что увеличивает скорость на последних этапах процесса.
Если вы увидите серию подобных графиков один за другим, это скорее всего означает, что вы нашли Scrum-команду.
Медленная поставка
В этом случае практически всё выглядит хорошо. За исключением того, что линия “Выполнено” долго остаётся плоской и проходит близко к горизонтальной оси. В то же время мы видим резкий рост поставки в конце. Что это означает?
Скорее всего команда выполнила большое количество задач, но по какой-то причине не могла их поставить. Это традиционный график для проектов с фиксированным бюджетом и фиксированным временем поставки, когда основная метрика – это количество выполненных задач для продуктовой команды. Никто не обращает внимание на задачи, которые могут быть протестированы и поставлены раньше.
Другая возможная причина такого графика – это сложная и болезненная процедура поставки.
Рост очереди
Мы уже обсуждали, что означает большая ступенька на графике – изменение объема проекта. В данном случае обсудим время и размер этого изменения.
Во-первых, это изменение огромно. Похоже, что добавили больше половины изначального объема работы. Во-вторых, оно случилось внезапно и очень поздно. Мы уже видели окончание проекта, но внезапно оказались на его середине.
Что ж, это не обязательно проблема в проекте. Если в результате общения с клиентом вы договорились об изменениях или это изменение означает ожидаемое наполнение списка задач – это вполне нормальная ситуация. В обоих случаях подобная картина не должна быть для вас неожиданной.
Возможна и другая, более драматичная, история. Если подобное произошло в проекте с фиксированной ценой – это означает, что внезапно появился большой объем незапланированных задач и потребуется ещё немало времени, а значит и расходов, чтобы завершить проект.
Уменьшение количества задач
Во всех предыдущих случаях мы видели, что линии на CFD двигаются вверх или, в худшем случае остаются плоскими. Именно этого вы ожидаете исходя из механизма создания графика. Это теория, а на практике вы не должны удивляться, если увидите похожий график.
Что здесь произошло? Почему количество задач в тестировании уменьшилось? Куда исчезли эти задачи? Они точно не попали в готовые потому то оранжевая линия не изменилась. Они не были удалены, потому что не изменилось общее количество задач. Похоже что несколько задач вернулось из тестирования в бэклог.
Что это может означать? Сложно сказать без более тщательного исследования. Есть и хорошая новость. Исследование не будет долгим – подобные вещи не происходят каждый день. По какой-то причине задачи после разработки были помечены, как новые, как будто работа над ними не начиналась.
Похоже это большое архитектурное или функциональное изменение. Скорее всего оно было вызвано тестированием ранее упомянутых задач. К сожалению это также означает, что мы потратили часть времени на разработку ненужной функциональности.
Ненужная работа
Эта же проблема может выглядеть намного страшнее. Так же как и в предыдущем примере общее количество задач не изменилось, но все остальные графики резко спикировали вниз. Не изменилось количество задач в тестировании и разработке, значит часть задач из выполненных переместилась в новые.
Часть задач, которые считали выполненными оказались неготовыми. Возможно, как и в прошлом случае мы выполняли ненужные задачи, но обнаружили это слишком поздно. Это позднее открытие будет стоить нам существенно больше, чем в предыдущем случае.
Есть ещё одно важное замечание. Возможно CFD указывает на возможные проблемы с критериями завершения задачи и взаимодействием с клиентом. Как оказалось так что существенное количество выполненных задач больше не являются таковыми? Возможно кто-то принимал их без проверки или обсуждения с другими участниками.
Куда пропали задачи?
Естественно, может уменьшаться и количество задач в очереди. Кроме очевидного случая, когда часть задач была удалена из бэклога, что скажется только на голубой линии, вы можете столкнуться вот с таким графиком. Используя те же рассуждения, что и для предыдущих примеров мы быстро обнаружим, что задачи из тестирования попали… где же они?
Они исчезли. Они не перешли в выполненные и не вернулись назад. Этих задач больше нет
Что это означает? Во-первых, мы опять сделали ненужную работу. Во-вторых, мы обнаружили это достаточно поздно. В-третьих, похоже, что эта функциональность больше не нужна.
Мы либо осознали, что не знаем как точно реализовать функциональность, либо узнали у клиента, что она больше не нужна. Так же возможно, что мы столкнулись с серьёзной технической проблемой и подумали, как мы можем упростить наше решение. Чтобы это ни было мы поняли, что если бы узнали об этом раньше, то изменения не были бы такими дорогими.
Изменение процесса на CFD
CFD не только помогает найти проблему, но и показывать насколько успешно она решается. Последний график достаточно хорош по сравнению с предыдущим, но у него есть особенность.
В первой части графика задачи в работе медленно но стабильно увеличивается. В какой-то момент команда заметила это и перестала набирать новые задачи. Видно, что верхняя граница серой линии практически перестаёт расти во второй половине графика – разработка сосредоточилась на завершении уже начатых задач.
Накопительная диаграмма на практике
Надеюсь, что статья помогла разобраться в том, как строить накопительную диаграмму и что можно увидеть с её помощью.
Есть плохая новость. Вы редко увидите такие красивые графики, как в примерах. Скорее всего в реальной жизни вы столкнётесь с комбинацией нескольких паттернов сразу. Не стоит бояться. Если вы понимаете, как устроен CFD вы сможете быстро найти место где необходимо начать исследование.
Напомню, что график лишь показывает возможное наличие проблемы. Её поиск и исправление – это совершенно другая история.
В тоже время если вы ищите инструмент для быстрого определения состояния вашего проекта, то CFD – это совершенно естественный выбор.
Интересные статьи
Ekaterina Svirepo
Max Frolov
Veronika Vesterovskaya
Хотите построить управляемый
процесс в своей команде?