Канбан: поток задач, WIP-лимиты и прогнозируемость

Канбан вырос из производственной системы Toyota (Тайити Оно, Эдвардс Деминг), а в 2006 году был адаптирован для интеллектуальной работы в Corbis. Сегодня минимальные правила зафиксированы в официальном «The Kanban Guide» (декабрь 2020): канбан — это стратегия оптимизации потока ценности через визуальную pull-систему.

Три базовые практики

1. Определить и визуализировать рабочий процесс. Команда договаривается об определении процесса (Definition of Workflow): что такое задача, где старт и финиш, через какие состояния она проходит, какие правила движения. Доска — только отражение этой договорённости.
2. Активно управлять задачами в потоке. Не «повесить карточки и забыть», а ежедневно разбирать: что застряло, что стареет, что заблокировано.
3. Улучшать процесс. Изменения вносятся по мере необходимости, а не только по расписанию.

WIP-лимиты и pull-система

Незавершённая работа (Work In Progress) ограничивается явно — числом или токенами на колонку. Новая задача «втягивается» в работу, только когда освободилась ёмкость. Это главный механизм канбана: лимит незавершёнки ускоряет поток, потому что команда доделывает, а не начинает.

Четыре метрики потока

• WIP — сколько задач начато, но не завершено
• Throughput — сколько задач завершается за единицу времени
• Work Item Age — сколько задача уже в работе
• Cycle Time — время от старта до финиша

На основе исторического cycle time строится ожидание уровня сервиса (SLE): например, «85% задач завершаются за 8 дней». Так прогноз сроков перестаёт быть гаданием.

Как мы это используем

В проектах внедрения и поддержки мы начинаем с визуализации реального процесса клиента «как есть», без реорганизации. Затем добавляем WIP-лимиты на узких местах и накапливаем метрики — через несколько недель у заказчика появляется прогнозируемый поток задач вместо очереди «всё срочно».

Первоисточники

• The Kanban Guide, December 2020
• Atlassian: Working with WIP limits for kanban