Привет! Меня зовут Артур Нек, я Kanban-консультант и управляющий партнер Kaiten. Как руководителю, мне важно знать, как идут дела в проекте и есть ли какие-то проблемы. Постоянно спрашивать об этом у сотрудников в чатах или на почте неэффективно, а на просмотр досок и карточек проекта уйдет много времени.
Вместо этого я использую визуализацию — накопительную диаграмму потока, которая помогает быстро составить картину происходящего. В этой статье я расскажу, что это за диаграмма, и на примерах разберу самые частые проблемы, которые она может показать.
Как работает накопительная диаграмма и почему она полезна
Накопительная диаграмма потока (Cumulative Flow Diagram, или CFD) — способ визуализации данных, который помогает оценить состояние дел внутри проекта. Например, в сервисе Kaiten все данные о текущих и уже выполненных задачах автоматически превращаются в понятный график. Он постоянно обновляется, и я могу посмотреть его в любой момент.
CFD помогает решить две основные задачи:
Следить, на каком этапе работа над проектом. График показывает, сколько задач уже выполнено и сколько осталось, есть ли задержки. Это позволяет оценивать ситуацию в моменте и контролировать темп работы и сроки.
Оценить, есть ли на каком-то этапе проблемы. Например, успевают ли тестировщики исправлять баги. Если работа в какой-то момент застопорилась, график это покажет.
Сама диаграмма устроена очень просто. Горизонтальная ось — время, а вертикальная — количество задач на каждом этапе проекта по дням. В разных сервисах внешний вид диаграммы может различаться. Здесь расскажем, какие данные показывают разные области на примере диаграммы в Kaiten.
Оранжевая — количество выполненных задач. По мере того как проект будет близиться к завершению, эта область будет расти в высоту и ширину.
Зеленая и серая — количество задач в тестировании и разработке, а их суммарная ширина показывает объем одновременно выполняемой работы. При равномерной загрузке команды ширина обеих областей будет примерно одинаковой, а на графике они будут постепенно подниматься все выше. Это значит, что все больше задач переходят в статус «Готово» и все меньше осталось сделать.
Голубая — количество задач, очередь до которых еще не дошла. Площадь, залитая голубым цветом, в самом начале максимально широкая, так как выполненных задач еще нет. По мере продвижения работы над проектом голубая часть графика будет «худеть», но ее верхняя граница остается неизменной, то есть объем работ не изменится.
На доске есть разделение на выполненные задачи в колонке «Разработка» и на задачи, которые уже ожидают тестирования. В графиках, которые показаны в этой статье, такого разделения нет. Чаще всего оно и не нужно, но чуть позже мы расскажем о ситуации, когда такое разграничение точно пригодится.
Какую информацию можно найти в накопительной диаграмме: разбираем каждую область на графике
Теперь расскажем, как вообще работает график, как на нем двигаются области и что означают ломаные линии.
На графике видно изменение объема работ — это ступенька на синей области. Еще хорошо видно, как менялось количество элементов в работе (Work in Progress, или WiP) и сколько составляет Production Lead Time — среднее время, необходимое для выполнения одной задачи.
График показывает, что сейчас выполнена половина работы и можно определить примерный срок окончания проекта. Конечно, дата может сдвигаться, если количество задач или время поставки изменятся.
Диаграмма показывает только приблизительные значения для WiP и времени поставки, но по ним все равно можно оценивать состояние проекта. Еще важно отметить, что график сам по себе не показывает причины возникновения проблем. Чтобы выяснить, почему этапы разработки и тестирования в нестабильном состоянии, нужно проанализировать все процессы в команде.
Идеальный график вы будете видеть нечасто, потому что во время работы всегда возникают задержки, форс-мажоры или изменения. Ниже мы рассмотрим самые частые проблемы, которые может проиллюстрировать диаграмма потока, и научимся ее читать.
Work in Progress растет для тестирования и разработки
На графике выше видно, что ширина зеленой и серой областей, которые обозначают разработку и тестирование, со временем растет. Это значит, что количество задач со статусом «в работе» увеличивается.
Если над проектом все время работает одна и та же команда и количество ее участников не менялось, такой график может сигнализировать о проблеме. Если нерешенные задачи копятся, то это значит, что специалисты решают их медленнее, чем раньше. Следовательно, увеличивается и время доставки ценности потребителю (Time To Market, или TTM). Кроме того, каждый сотрудник вынужден работать в режиме многозадачности и постоянно переключаться с одного вопроса на другой, а это ведет к снижению эффективности.
Если команда постепенно разрастается, она, соответственно, берет на себя большее количество задач. В этом случае график просто отражает текущее положение дел и беспокоиться не о чем.
Work in Progress растет на этапе разработки
Здесь возможны две ситуации:
Качество разработки очень хорошее. Если тестировщики находят в продукте минимум багов, которые нужно устранить, и быстро выполняют свои задачи.
Загруженность тестировщиков высокая. Например, если сотрудников в команде мало, они могут не справляться с объемом работы. В результате к ним выстраивается очередь из задач на тестирование.
Это ситуация, когда есть смысл разграничивать на графике те задачи, которые еще находятся у разработчиков, и те, что уже выполнены, но их еще не взяли в работу тестировщики. В любом случае показатели на этом графике — повод проанализировать объем работы и, возможно, увеличить штат сотрудников.
Проблемы с организацией поставки
Характерные ступеньки на оранжевой области графика чаще всего появляются на поздней стадии работы над проектом. Вместе с тем количество задач на тестировании растет — зеленая область на графике расширяется после каждого релиза.
Это может означать проблемы с качеством продукта, которые команда не успевает решать. Если разработчики не уделяют достаточно внимания исправлению багов, у тестировщиков копятся задачи. Они вынуждены одновременно выполнять новые задачи и напоминать коллегам о незакрытых.
Еще проблема может быть в плохой организации поставки, которая не позволяет выпускать в релиз все готовые задачи. Их «выбрасывают» раз в несколько дней, поэтому плавная линия на графике превращается в ломаную.
Полная остановка работы
Если все линии выравниваются параллельно оси Х, это означает, что в определенные дни команда ничего не делала. Ситуация, когда сотрудники были на работе, но не выполнили ни одной задачи за несколько дней, очень маловероятна. Скорее всего, у этих показателей есть простое объяснение.
Такой график может появиться во время длинных государственных праздников или корпоративов. Еще прямые линии могут означать, например, поломку тестового окружения или срочную переброску команды на другой проект.
Остановка работы на этапе поставки
На этом графике, в отличие от предыдущего, выровнялись только области тестирования и поставки, но область разработки продолжает расти.
Возможно, у команды нет проблем с началом работ над новыми задачами, но процесс останавливается в момент, когда должны включаться тестировщики. Раз на этапе тестирования ничего не происходит, новых задач тоже нет. Возможно, что-то произошло с тестовым окружением либо в команде только один сотрудник, который заболел или ушел в отпуск и не может работать.
Есть еще одна деталь, на которую я бы обратил внимание, — возможная проблема с коммуникацией внутри команды. Разработчики выполняют свои задачи в прежнем режиме, будто все в порядке. Это значит, что, когда тестировщик сможет вернуться к работе, его будет ждать настоящий завал. На его ликвидацию уйдет много времени, в работе проекта возникнет еще одна пауза, а релиз опять отложат.
Очень быстрая поставка
Этот график очень наглядно иллюстрирует проблемы с качеством продукта. Линия разработки растет стабильно, а линии тестирования и поставки сужаются и взлетают круто вверх. При этом сначала на графике видно, что задач в разработке много, но на этапе тестирования и поставки они будто исчезают. В самом конце удивительно мало задач «в работе» и большое количество готовых.
Такой скачок в графике объясняется небрежным ведением отчетности в Kaiten. Разработчики забывали отмечать свои задачи как выполненные, а потом сделали это за один день.
Более вероятен сценарий, когда команда не успела все доделать до дедлайна и отправила в релиз задачи, которые казались выполненными. В этом случае ненайденные баги обнаружатся уже на завершающем этапе, и значительную часть работы придется переделывать заново.
Очень высокий показатель Work in Progress
На этой диаграмме линия разработки начинает расти очень агрессивно, и к середине периода уже начата работа над 80% задач. Тестирование немного запаздывает, но тоже двигается быстрыми темпами.
В поставке в самом начале почти ничего не происходит: область не растет вверх и не расширяется. Но по мере приближения дедлайна оранжевая линия идет почти вертикально вверх, и все задачи внезапно оказываются выполненными. Мы видим очень большой WiP в центре графика и очень маленький — в начале и в конце. Судя по диаграмме, в последний день поставлено все, что было в планах, то есть команда уложилась в сроки.
Несмотря на сходство с предыдущим графиком, здесь все задачи, скорее всего, выполнены качественно. Такой график характерен для scrum-команд, которые в планировании используют time boxing. Команда поддерживает стабильную скорость поставки и хорошо планирует задачи внутри определенного периода.
У сотрудников нет ограничений для WiP внутри time box. Разработчики быстро набирают большое количество задач и ориентируются только на необходимость закончить их к концу итерации. Когда бэклог итерации исчерпан, команда фокусируется на завершении процессов и увеличивает скорость на последних этапах работы.
Медленная поставка
На этом графике все выглядит хорошо, за исключением области поставки, которая почти все время остается практически параллельной оси Х. В конце периода резкий скачок, и линия поставки поднимается вертикально.
Команда выполнила и протестировала довольно много задач, но по какой-то причине не делала поставки. Так часто поступают в проектах, у которых заранее оговоренный, фиксированный бюджет и поставка запланирована ближе к дедлайну. Эффективность работы измеряют именно в задачах, которые выполнила в срок продуктовая команда, но релизом раньше времени никто не занимается. Другая возможная причина такого графика — проблемы с процедурой поставки, а это уже повод для реорганизации работы либо увеличения бюджета или сроков.
Рост очереди из задач
В самом начале мы уже говорили, что означает большая ступенька в синей области — это изменение количества задач внутри проекта. На этом конкретном графике изменение очень большое. Судя по всему, добавили примерно половину от уже имеющегося объема, это произошло в один день и почти перед финалом работы. Команда практически откатилась от завершающей стадии к середине проекта.
Всё в порядке, если такой скачок был заранее оговорен с клиентом и пополнение списка задач не стало сюрпризом. Но, если речь о проекте с фиксированным бюджетом, это значит, что для его завершения потребуется много времени и дополнительных расходов.
Уменьшение общего количества задач
На всех предыдущих графиках видно, что линии либо двигаются вверх, либо остаются плоскими. Но на этом примере количество задач в разработке и тестировании между 14 и 15 июля уменьшилось. Они точно не выполнены, потому что область поставки не изменилась, и не могли быть удалены с доски, потому что в голубой области нет спада.
Такие изменения обычно показывают, что несколько задач вернулись в бэклог после тестирования. Работа над ними началась заново, и у разработчиков в графике они будут помечены как новые. Скорее всего, после тестирования произошли изменения в архитектуре или функциональности, поэтому задачи откатились в бэклог. К сожалению, это значит, что разработчики потратили часть рабочего времени впустую.
Задачи, возвращенные в бэклог с этапа поставки
Здесь, как и в пункте выше, общий объем задач не изменился, но во всех областях виден явный провал. Количество задач в тестировании и разработке осталось прежним, значит, часть задач из «выполненных» вернулась в «новые».
Такой график означает, что задачи, которые команда считала завершенными, были сделаны некачественно. Есть вероятность, что, как и в пункте выше, сотрудники выполнили ненужный объем работ, но обнаружили это не на этапе тестирования, а уже на этапе поставки. Такое «открытие» дорого обойдется бюджету проекта.
Еще такой график указывает на плохо выстроенную коммуникацию с клиентом и нечеткие критерии, по которым задачу оценивают как выполненную. Возможно, задачи приняли без проверки или согласовывали без участия других членов команды, а из-за упущенных из виду ошибок вся работа в итоге откатилась назад.
Задачи, исчезнувшие из графика на этапе тестирования
Число задач в проекте может не только увеличиваться, но и уменьшаться. Если удалить часть из них на стадии бэклога, вниз пойдет только голубая линия. На примере выше видно, что задачи пропали еще и из области тестирования, причем они не переместились в «выполненные» и не вернулись в разработку.
Это значит, что мы опять потратили время на ненужные процессы и поняли это довольно поздно. Похоже, какая-то функциональность оказалась лишней и ее просто убрали. Такое возможно, если команда не придумала, как реализовать ее, столкнулась с какой-то технической проблемой или вовсе упростила решение. В любом случае, если бы от этих задач отказались раньше, изменения обошлись бы проекту дешевле.
Изменение процесса работы всей команды
Диаграмма потока может подсветить не только проблемы, но и показать, как хорошо команда управляет задачами и адекватно оценивает силы.
Первые несколько дней на графике видно, как растет серая область, а затем линия выравнивается. Это значит, что разработка сначала активно принимала новые задачи, затем приостановила набор и сосредоточилась на том, чтобы закрыть все уже имеющиеся задачи.
Несколько выводов о работе с Cumulative Flow Diagram
В реальности таких красивых и наглядных графиков, как в примерах, не будет. Наоборот, наверняка сразу заметите несколько разных проблем, но, если понимать, как работает диаграмма, прочитать ее будет несложно.
Диаграмма помогает анализировать общую картину проекта — количество задач, темп работы, провалы на каком-то из этапов. Важно помнить, что на графике видно лишь следствие. Причину проблемы можно определить только с помощью анализа процессов и общения с командой.
СFD могут применять не только руководители, но и сами участники команд. Это поможет им отслеживать динамику процессов, самостоятельно управлять временем и лучше выстраивать коммуникацию с коллегами.
