Типичная ошибка при проектировании Канбан-системы — устанавливать WIP-лимиты на отдельные колонки, но оставлять некоторые без ограничения и не ограничивать количество незавершенной работы во всей системе.
не на всех шагах процесса есть ограничения
На рисунке пример Канбан-системы с определенными точками «начала» и «конца» и WIP-лимитами в колонках Ready (3), Design (3), Dev (2) и QA (2). А начатая, но незавершенная работа (WIP) в колонке Ready for QA никак не ограничена. Значит, что поток не законсервирован — работа в Ready for QA может увеличиваться без ограничений. Это push-система с низкой предсказуемостью.
Не думайте, что можно устанавливать WIP-лимиты только на отдельные шаги процесса. Вы должны поддерживать постоянное количество WIP в системе. Чем больше вы нарушаете этот принцип, тем менее предсказуемыми становитесь
Даниэль Ваканти, Метрики для предсказуемости
На следующем рисунке в Канбан-системе жестко ограничено количество начатой, но незавершенной работы — максимум 12 элементов.
push-система превратилась в настоящую pull-систему
Ограничивать WIP нужно для консервации потока — конвертации системы из push в pull. Это ведет к оптимизации на уровне системы и повышает предсказуемость.
Профессиональный Скрам с Канбаном — оптимизация потока ценности с помощью визуальной pull-системы, в которой начатая незавершенная (WIP) работа ограничена (Руководство по Канбану для Скрам-команд).
Хорошая кумулятивная диаграмма (CFD) в pull-системе выглядит так:
законсервированный поток в системе
CFD демонстрирует систему, в которой время цикла (Cycle Time) и пропускная способность (Throughput) стабильны на протяжении долгого времени.
Если не ограничивать WIP во всей системе, работа может «расползаться», что нивелирует ваши попытки добиться предсказуемости:
поток непредсказуемый и «расползается»
Основные мысли
- Для предсказуемости и системной оптимизации WIP-лимиты устанавливаются во всей системе.
- Отсутствие WIP-лимитов во всей системе приводит к непредсказуемости и «расползанию» потока на кумулятивной диаграмме.
