Cycle time
Тема дорожной карты · Agile / Scrum / Kanban
Cycle Time — это время, затраченное на выполнение задачи от момента, когда задача переходит в статус 'In Progress', до момента завершения задачи 'Done'. Cycle Time является ключевой метрикой для оценки скорости потока работы через систему. Важно отметить, что медианное значение Cycle Time обычно более точное, чем среднее, так как несколько задержек могут существенно искажать среднее значение. Уменьшение Cycle Time обычно достигается за счет уменьшения размера задач или ограничения WIP (Work In Progress).
Как это работает
Для определения Cycle Time каждую завершенную задачу следует записывать с момента перехода в статус 'In Progress' до момента завершения задачи. Затем строятся гистограммы на основе скользящих окон 30, 60 и 90 дней. Форма гистограммы имеет большое значение: узкое распределение с центром на 4 дня указывает на то, что большинство задач завершается в течение 3-5 дней, что свидетельствует о высокой предсказуемости. В случае широкого распределения, например от 1 дня до 30+ дней, трудно предсказать, за какое время будет завершена следующая задача. Для улучшения Cycle Time обычно применяются самые дешёвые интервенции: уменьшение среднего размера задачи (дробление крупных задач на более мелкие), уменьшение WIP (Work In Progress) и устранение явных handoffs (перемещения задач между участниками).
Когда применять
Cycle Time является одной из самых надежных метрик для прогнозирования сроков завершения задач. Для более точных прогнозов рекомендуется использовать медианное значение Cycle Time и 85-й перцентиль. Например, можно сказать: 'Задачи обычно завершаются за 3-7 дней, 85% задач завершается за 10 дней'. Это гораздо более точное представление, чем простое утверждение типа '~5 дней'.
Типичные ошибки
(1) Отчётность среднего вместо медианы/перцентилей — среднее значение может быть искажено несколькими задержками, поэтому важно отчитываться о медианном значении и 85-м перцентиле. (2) Путаница между Cycle Time и Lead Time — Lead Time включает в себя время ожидания задачи в backlog до начала работы, в то время как Cycle Time не включает это время. Разные метрики подходят для решения разных проблем. (3) Оптимизация Cycle Time за счёт ухудшения качества — сокращение Cycle Time ниже здорового уровня может привести к использованию кратчайших путей, которые могут ухудшить качество. Поэтому важно отслеживать rate defect escape (темп утечки дефектов) вместе с Cycle Time для проверки качества работы.