Мы уже много говорили об улучшениях и о том, как начать вносить изменения в свой процесс. Мы должны воспринимать изменения как проведение экспериментов. При проведении этих экспериментов нам необходим способ узнать, улучшают ли изменения наш процесс. Существует огромное число метрик для команд, использующих канбан и Lean.

Точно предсказать длительность проекта можно только сделав его на 1/3 – 2/3. Канбан-метод опирается на статистическую информацию, накопленную по ходу работы сервиса.

В статье мы затронем следующие метрики Канбан-метода:

  1. Time to market (TTM);
  2. Lead time (LT);
  3. Эффективность потока (E);
  4. Throughput;
  5. SLA;
  6. Cumulative flow diagram (CFD);
  7. Control chart (Контрольная диаграмма);
  8. Spectral chart (Спектральная диаграмма).

Эффективность потока (E)

E=(TT/LT) * 100%;

где TT (Total time = Customer lead time) – сумма всех отрезков времени, в течении которых реально проводилась работа над проектом;

LT – вся длительность проекта от начала до завершения. Работы больше не ведутся над проектом.

Данная метрика отличное начало для работы над процессом. Представим себе ситуацию, эффективность потока равна 5%. Значит 95 % времени задача чего то ждала. Параметр отличная нулевая оптимизационная точка с которой можно начинать улучшение. Канбан помогает увеличить эффективность за счет сокращения одновременно взятой работы в работу (WIP лимиты).

Накопительная диаграмма потока (Cumulative flow diagram)

График, по которому не глядя на сервис можно понять эффективность работы. Строится ежедневно. Достаточно сложен в чтении. Позволяет по единому взгляду понять среднее количество элементов в системе, средний Lead time, Throughput и подсвечивает узкие места.

Cumulative flow diagram

Возьмем дату 3 января 2013 года. Взглянув на график, мы видим, что было сделано 0 задач тестирования. В разработке было 2 задачи, в дизайне 2, в бэклоге 6.

Для того, чтобы построить Cumulative flow diagram нам нужен продукт, команда и цель улучшить сервис. Сервис состоит из 3 этапов: анализ, разработка и тестирование. В первый день мы имеем в колонке бэклог продукта (очередь) 10 элементов, анализ 3, разработка 2, тест 3, готово 0.

Пример построения накопительной диаграммы потока

На окончании 1 дня строим накопительную диаграмму потока.

В разработке пишем 5 (2 находятся сейчас и 3 прошли анализ).

На 2 день ситуация следующая. В анализе 1 задача, разработка 3, тест 3, готова 1. В систему новых задач не брали.

Накопительная диаграмма потока (Cumulative flow diagram)

На 3 день. 3 задачи в анализе, 4 в разработке, 2 в тесте, 2 в готово.

Cumulative flow diagram example2

На 4 день сложилась такая ситуация. Все задачи по тестированию перешли в готово. В готово 4, тест 0, разработка 5, анализ 2, очередь плюс 3 задачи от Заказчика.

Cumulative flow diagram example3

Cumulative flow diagram example4

WIP и Lead time – катеты гипотенузы. Гипотенуза – пропускная способность системы.

Время цикла (Cycle time) и время выполнения (Lead time)

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

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

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

Время цикла (Cycle time) и время поставки (Lead time)

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

Сбор метрики время цикла и время выполнения

Время цикла и выполнения – это метрики, которые легко собирать и отслеживать. Если ваш рабочий процесс визуализирован, то вы можете начать прямо сегодня. Отмечайте дату на каждой карточке рабочего элемента, когда вы поместили задачу на доску. Когда рабочий элемент достигнет последнего столбца на вашей доске (например, “Готово” или “В производстве”), отметьте эту дату. Разница между этими двумя датами – это время выполнения в вашем процессе.

Сбор метрики время поставки

Сбор данных для метрики время цикла так же прост. Это можно сделать, поставив отметку на рабочем элементе с датой, когда он входит в интересующий вас столбец: например, когда он входит в столбец разработка «Development», а затем снова, когда он достигает столбца «Готов к развертыванию» Ready to deploy.

Сбор метрики время цикла

Анализ метрики время цикла, время выполнения

Располагая эти две метрики на руках (например, время выполнения 44 дня и время цикла разработки и тестирования 8 дней), команда может начать проводить некоторый анализ и задавать вопросы о работе. 8 дней составляет около 20% от общего времени. Это число (8 дней) выросло или уменьшилось? Где тратиться оставшееся время? Необходимо ли нам начать отслеживать время цикла?

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

Визуализирование метрики время цикла и время выполнения

Команда отслеживает тренды времени выполнения и цикла на двух простых диаграммах, которые они рисуют на канбан-доске рядом с рабочим процессом. Это можно сделать в виде простой точечной диаграммы, как показано ниже.

Визуализирование метрики время цикла и время выполнения

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

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

Время цикла на различных стадиях процесса

Пропускная способность (Throughput)

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

Сбор метрики

Как и во время поставки, сбор данных по метрике пропускная способность довольно прост: подсчитайте количество выполненных рабочих заданий в неделю (или месяц). На визуализированной доске вы можете посчитать количество рабочих элементов в столбце «Готово» каждую пятницу, а затем очистить столбец.

Визуализация метрики

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

Визуализация метрики пропускная способность

Анализ метрики

Анализ пропускной способности может помочь вам сосредоточиться на выполнении работы. Добавив визуализацию, показывающую, сколько команда реализует задач каждую неделю, люди снова начнут концентрироваться на поставке.

Пропускная способность также может быть метрикой балансировки для улучшения времени выполнения. Если вы сокращаете время выполнения, и пропускная способность так же снижается, то возможно, вы слишком сильно сократили WIP.

Баги и заблокированные рабочие элементы

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

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

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

Сбор метрики

Благодаря визуализированному рабочему процессу эти две метрики (баги и заблокированные рабочие элементы) легко фиксируются путем подсчета количества элементов на доске:

  • Количество дефектов = количество розовых карточек в любое время или в неделю, например;
  • Количество заблокированных элементов = Количество стикеров с прикрепленным к ним заблокированным маркером.

Визуализация метрики

Это легко сделать в виде точечной диаграммы или столбчатой ​​диаграммы, показывающей тренды. У вас есть больше заблокированных рабочих элементы сейчас? С тех пор как вы приняли неделю только для исправления багов, количество новых ошибок было сохранено на новом минимуме или оно снова растёт? Какова была причина того, что на прошлой неделе было столько ошибок?

Визуализация количества багов в неделю

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

Анализ метрики

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

Вторая часть статьи