Метрики потока в Kanban: как управлять не скоростью команды, а эффективностью системы
Что изменить, чтобы сократить реальное время доставки ценности
Вы используете Agile и измеряете Velocity команды, но по-прежнему не можете дать заказчику точный ответ на вопрос «Когда?» Если команда загружена, а сроки срываются, то проблема в том, что Velocity не предназначена для прогнозирования.
В этой статье мы совместно с Василием Савуновым, Kanban-тренером (KU AKT), Agile Coach и автором курса «Основы Канбан-систем», расскажем, как с помощью метрик потока и Kaiten изменить подход к управлению. Вы увидите, как ограничение WIP позволяет находить «бутылочные горлышки» на доске, точно прогнозировать сроки и принимать решения, которые ускорят доставку продукта, а не просто создадут видимость работы.
За какими метриками лучше следить: взгляд эксперта
Команды, работающие по Scrum, опираются на метрику Velocity, но, по мнению эксперта, этот подход имеет свои ограничения, когда речь заходит о точном прогнозировании сроков для заказчика.
В Scrum команды оперируют не количеством задач, а оценкой задач в сторипойнтах (Story Points) — относительной мерой трудоемкости задач. Сторипойнты были придуманы для ускорения коллективной оценки, поскольку оценить трудоемкость в часах или днях сложно, особенно в больших командах.
Для новичка час может значить один объем работы, а для опытного сотрудника — совсем другой
Василий Савунов, Kanban-тренер (KU AKT)
По мере набора статистики и опыта, команда может определить свою Velocity — оптимальный порог вместимости в сторипойнтах, который позволяет ей с большой вероятностью планировать объем работы на спринт.
Однако относительная оценка в сторипойнтах сама по себе имеет существенный недостаток для бизнеса:
Сложность в работе с Velocity в сторипойнтах в том, что такой подход не дает точного ответа для заказчика на вопрос «когда, в какую именно дату будет готово?» Точность оценки на основе Velocity - плюс-минус 1 спринт. И в ответ на вопрос заказчика «когда?» команда может ответить лишь - в каком именно спринте будет готова задача (например - «в четвертом спринте»), что не всегда подходит заказчику.
Василий Савунов, Kanban-тренер (KU AKT)
В отличие от Velocity в сторипойнтах, метрики потока Kanban опираются на исторические данные о сроках выполнения задач в днях и используют математическую статистику для прогнозирования.
Оценка по Kanban-метрикам позволяет сказать, с какой вероятностью тот или иной прогноз по времени выполнения совпадет с реальностью. Такой подход позволяет дать четкий, научно обоснованный прогноз: «вот эту задачу выполним с вероятностью 80% за столько-то дней»
Василий Савунов, Kanban-тренер (KU AKT)
Василий подчеркивает, что метрики Kanban не конкурируют со Scrum, а улучшают его точность.
Главная ценность метрик потока в их способности предоставить руководству прогноз сроков в днях, подкрепленный статистикой, что делает планирование более управляемым и предсказуемым.
Смена фокуса с «загрузки» на «поток»
Как мы выяснили в предыдущем разделе, Velocity в сторипойнтах — это метрика вместимости, которая не позволяет делать точный прогноз. Эксперт указывает, что чрезмерная ориентация на максимальную скорость поставки приводит к неэффективности, поскольку поощряет максимизировать загруженность сотрудников, а не завершенность задач.
Если мы будем фокусироваться на загрузке всех членов команды, вовлеченных в работу, мы только ухудшим ситуацию. Управление загрузкой может дать локальную оптимизацию, но это не сделает лучше весь процесс и может даже замедлить его
Василий Савунов, Kanban-тренер (KU AKT)
Для перехода к управлению потоком нужно поменять взгляд на оценку. Вместо того, чтобы смотреть на команду, нужно смотреть на систему.
Часто бывает очень сложно точно описать внутреннее устройство рабочего процесса по всей его полноте или точно спрогнозировать эффективность работы конкретного человека, а тем более группы людей. Надо представить себе, что это черный ящик, и начинать измерять разные метрики его поведения
Василий Савунов, Kanban-тренер (KU AKT)
Чтобы клиенты быстрее получали то, что им нужно, нужно фокусироваться на завершении уже начатых задач, и добиваться доведения их до состояния готовности, прежде чем брать в работу новые задачи. Это позволит снизить накладные расходы на переключение между задачи, повысит качество и фокусировку, снизит перегрузку, и сделает рабочий поток предсказуемым.
В чем отличие и преимущество метрик потока:
- Позволяют увидеть простои. При анализе метрик потока есть возможность замерить не только общий Lead Time задач, который включает в себя все время — и работы, и простоев (ожидание ревью, ожидание тестирования, блокировки), но и замерить время задач в колонках-буферах, где они копятся и ждут, когда их возьмут в работу на следующем этапе рабочего процесса. Это помогает команде видеть где они не эффективно тратят свое время и улучшать рабочий процесс.
- Они предотвращают «эффект многозадачности». Если команда фокусируется на завершении, а не на начале, это снижает количество задач, которые просто “стоят” в колонке и не несут ценности.
Один из важных инструментов, который помогает переключить фокуса с «загрузки» на «поток» — WIP-лимиты. Это ограничение количества задач, над которыми ведется активная работа (количество задач в колонке «В работе») и главный рычаг управления всей системой Kanban. Причина кроется в базовом законе теории потока — законе Литтла.
Ограничение WIP заставляет команду фокусироваться на завершении начатого. Благодаря метрикам потока команда будет получать честные данные о работе всей системы:
- Cycle time (время цикла) и Lead time (сквозное время) измеряют реальное время доставки ценности.
- Throughput (пропускная способность) показывает, сколько ценности система может выдать за период.
Отслеживать WIP-лимиты можно с помощью Kaiten — сервиса управления задачами. Лимит для колонки или дорожки будет отображаться цветом и цифрами, сигнализируя о достижении или превышении порога:
- зеленый — в колонку еще можно переносить задачи;
- желтый — лимит почти достигнут;
- красный — лимит достигнут или превышен.
Kaiten помогает команде фокусироваться на прозрачности и визуализации, предоставляя единую платформу для понимания и анализа текущего состояния системы, а не только для ее ускорения.
Прежде чем улучшать рабочие процессы, стоит сначала четко определить правила и визуализировать поток задач. Так команда сможет полностью осознать свое текущее положение
Василий Савунов, Kanban-тренер (KU AKT)
Данные метрик формируют три ключевые метрики потока, которые помогают видеть «бутылочные горлышки» и прогнозировать сроки доставки продукта. Разберем их подробнее.
3 метрики потока и их ценность
Lead time, Cycle time и Throughput — метрики, которые измеряют реальное время в днях и часах, подсвечивают простои и помогают управлять системой на трех уровнях.
Lead time
Lead time в общем случае — это время производства, от начала реальной работы над задачей до ее завершения. Еще один показатель — Upstream Lead Time - это время подготовки задач к реализации, когда ее анализируют, обсуждают, приоритизируют и так далее.
Часто Upstream Lead time показывает, что самый большой простой в системе — это подготовка к началу работы, а не сама работа. Чтобы сократить значение, можно не только ускорять разработку, но и быстрее принимать решения, расставлять приоритеты и убирать из бэклога неактуальные задачи.
Cycle time
Cycle time — это время между произвольными точками рабочей системы, которое иллюстрирует определенную часть Lead Time.
Например, с помощью Cycle time можно измерить время от момента, когда задача была переведена в первую рабочую колонку («В работе», «Разработка») до момента, когда она выпущена или доставлена («Готово», «Релиз»).
Cycle Time — один из индикаторов внутренней неэффективности команды. Метрика помогает:
- Диагностировать «бутылочные горлышки». Если собрать отчет в Kaiten, то метрика Cycle time покажет, сколько времени задача в среднем тратит на каждый этап (например, «разработка», «ревью», «тестирование»). Если Cycle time внезапно вырос в 2 раза, вы видите, что проблема возникла не в кодировании, а в долгом ожидании на этапе ревью или тестирования.
- Принимать управленческие решения. Cycle Time тесно связан с WIP, поэтому его можно сокращать через ограничение одновременно выполняемых задач и устранение простоев.
Throughput
Метрика измеряет, сколько задач (рабочих элементов) ваша система в среднем способна завершить и выпустить за определенный период времени.
Throughput — это важная метрика для прогнозирования и планирования, которая помогает:
- Планировать выполнение работы. В стабильной системе с контролируемыми WIP и Lead time можно рассчитывать средний недельный (или месячный) Throughput, чтобы спрогнозировать, сколько фич вы сможете выпустить за следующий период. Например, если Throughput = 15 задач в неделю, то можно рассчитывать на выполнение 60 задач за месяц.
- Оценить масштабирование. Если вы добавили разработчиков или провели оптимизацию, Throughput должен вырасти. Это подтвердит, что ваши инвестиции в ресурсы или процессы были оправданы. Если Lead time сократился, но Throughput не вырос, это сигнал о возможной неэффективности.
Throughput переводит все усилия команды и всю эффективность системы в конкретные, измеримые результаты, которые являются основой для планирования RoadMap.
Мы можем отследить, когда задача попала в работу и когда над ней завершилась работа. Это время по каждой задаче можно собрать за длительный срок, а на его основе строить прогноз выполнения по будущей работе
Василий Савунов, Kanban-тренер (KU AKT)
Можно отследить пропускную способность на графике накопительной диаграммы потока. Выберите необходимый промежуток времени на диаграмме и посмотрите, сколько задач за это время попало в колонку «Готово»:
Подробно о том, как еще можно использовать накопительную диаграмму потока, мы подробно рассказывали в другой статье блога.
Прогнозирование: переход от оценок к вероятностям
Вместо того чтобы полагаться на субъективные оценки или опыт отдельных сотрудников, метрики потока позволяют делать точные прогнозы на основе статистики работы всего подразделения.
Гораздо лучше планировать сроки на основе всего производственного подразделения, а не опираться на профессионализм отдельных сотрудников, которые могут заболеть, уволится или уйти в отпуск
Василий Савунов, Kanban-тренер (KU AKT)
Для прогнозирования используется статистика времени прохождения каждой задачи:
Мы можем отследить, когда задача попала в работу и когда над ней завершилась работа - Lead Time. Это время по каждой задаче можно собрать за длительный срок, а на его основе строить прогноз выполнения по будущей работе
Василий Савунов, Kanban-тренер (KU AKT)
Именно исторические данные позволяют перейти от абстрактных оценок к вероятностному прогнозированию, где менеджер и заказчик сами выбирают приемлемый уровень риска.
Василий Савунов предлагает определять вероятность в разных процентных соотношениях:
- 100% Lead Time — мы должны будем опираться на самый пессимистичный, самый долгий срок, который есть в статистике и диаграммах.
- 80% Lead Time — бизнес всегда надеется получить результат быстрее. Тогда вероятность попадания в этот прогноз будет меньше, например, 80% вероятности.
Дальше уже задача заказчика решить, принимает ли он этот срок и риски, которые с ним сопряжены
Василий Савунов, Kanban-тренер (KU AKT)
Такой подход гарантирует долгосрочный и надежный прогноз, не зависящий от конкретных людей в команде.
Диагностика и принятие решений с помощью Kaiten
Настоящая ценность этих метрик раскрывается, когда их расчет и визуализация автоматизированы. Kaiten, как платформа для управления потоком, берет на себя самую сложную часть — сбор и визуализацию данных.
Расчет времени. Чтобы корректно рассчитывать Cycle time и Lead time, система автоматически отслеживает историю движения каждой карточки:
- Lead time считается от момента создания карточки или попадания в «Бэклог», а заканчивается при переводе в «Релиз» или «Готово».
- Cycle time — от перемещения в первую активную колонку и заканчивается при переводе в финальную «Релиз» или «Готово».
Визуализация потока. Через накопительную диаграмму потока Kaiten показывает, как со временем меняется количество задач в каждой колонке. Каждая колонка представлена своим цветом.
Важно регулярно проводить диагностику и определять проблемы. Например, если один из цветовых слоев резко расширяется по вертикали (то есть, наклон верхней линии резко расходится с наклоном нижней), это означает, что задачи скапливаются на этом этапе, не успевая перейти в следующую стадию. Это и есть «бутылочное горлышко»:
Слой «Разработка» стал заметно толще. Это сигнал, что отдел не справляется с потоком, а задачи зависают перед переходом на тестирование.
Принятие решений. Анализ метрик всегда приводит к конкретным управленческим действиям, направленным на устранение простоев.
Например, вы заметили, что средний Cycle Time увеличился с 3 до 6 дней, а CFD показала, что задачи скапливаются перед колонкой «Тестирование»:
Что делать в этом случае:
- Не начинать сразу искать виноватых, возможно проблема в лимитах или доступности тестировщиков.
- Уменьшить WIP-лимит в колонке «Разработка» и/или привлечь больше разработчиков к проведению тестов.
Так можно сфокусировать ресурсы на узком месте, «разблокировать» поток и сократить Cycle time для всех будущих задач.
Заключение
Успех в Kanban измеряется не загрузкой команды, а скоростью, с которой система доставляет ценность клиенту. Если вы измеряете только скорость, вы маскируете неэффективность.
Что стоит запомнить:
- Проблема не в команде, а в системе. Рост Lead time всегда сигнализирует о простое и ожидании (долгом ревью, застрявшем тестировании), а не о замедлении работы разработчиков.
- Используйте ограничение WIP. Это ваш рычаг ускорения потока, ведь по закону Литтла чем меньше задач команда делает одновременно, тем быстрее каждая из них завершается.
- Отслеживайте три метрики для управления командой на трех разных уровнях. Какие данные можно получить с их помощью:
- Lead time — скорость реакции на рынок, эффективность для демонстрации владельцу продукта;
- Cycle time — диагностика «бутылочных горлышек», эффективность команды;
- Throughput — точное прогнозирование даты релиза.
