Команда завела доску, расставила задачи по колонкам — и решила, что теперь у неё Kanban. На самом деле Kanban начинается не с доски, а с двух идей: сделать поток работы видимым и ограничить количество дел, которые команда тащит одновременно. Без этого доска — просто список задач в трёх столбиках.
Kanban — это способ управлять потоком работы. Он не делит время на итерации и не требует ролей вроде Scrum Master. Он говорит: смотри, как задачи текут от «надо сделать» до «готово», находи места, где они застревают, и не перегружай систему. Разберём, как это устроено и почему ограничение работы, как ни странно, ускоряет доставку.
Доска как карта потока
Основной инструмент Kanban — доска с колонками. Каждая колонка — это этап, через который проходит задача: например, Backlog → Анализ → Разработка → Тестирование → Готово. Задача (карточка) движется слева направо, и в любой момент видно, где она находится и что с ней происходит.
Важное отличие от простого to-do-списка: колонки в Kanban описывают реальные этапы вашего процесса, а не абстрактные «сделать / делаю / сделано». Если между разработкой и тестированием у вас есть code review — заводите отдельную колонку. Доска должна честно показывать, как работа действительно движется, иначе она не поможет увидеть проблемы.
Что даёт визуализация:
- Видно, на каком этапе скапливаются задачи — это и есть узкое место потока.
- Видно, кто чем занят и не перегружен ли какой-то этап.
- Видно «зависшие» карточки, которые давно не двигались.
Доска — это не украшение, а диагностический прибор. Скопление карточек в одной колонке — сигнал, что там что-то тормозит: не хватает людей, задачи слишком крупные или следующий этап не успевает их забирать.
WIP-лимиты: почему меньше значит быстрее
WIP (Work In Progress) — это количество задач, которые находятся в работе одновременно. Главная механика Kanban — ставить лимиты на WIP: например, «в колонке Разработка одновременно не больше трёх карточек».
На первый взгляд это звучит контринтуитивно: разве ограничение не замедлит команду? Наоборот. Объясняет это закон Литтла — простое соотношение из теории очередей:
Среднее время прохождения = Среднее число задач в работе / Пропускная способность
На пальцах: чем больше задач вы держите в работе одновременно, тем дольше в среднем каждая из них проходит путь до «Готово». Если пропускная способность (сколько задач команда завершает в неделю) фиксирована, то уменьшив число одновременных задач, вы уменьшаете время их прохождения.
Второй враг — многозадачность. Когда человек ведёт пять задач сразу, он постоянно переключается между ними, и каждое переключение стоит времени на «вспомнить, где я остановился». В итоге пять задач, начатых одновременно, все финишируют поздно. А если делать их по очереди — первая будет готова быстро, вторая чуть позже, и так далее. Заказчик получает ценность раньше.
Простой пример. Пять задач по два дня работы каждая:
| Подход | Задача готова к концу дня |
|---|---|
| Все пять параллельно | все пять — к 10-му дню |
| По одной, последовательно | 2, 4, 6, 8, 10-й день |
Суммарно работа занимает те же 10 дней, но во втором случае первая ценность доставлена уже на 2-й день, а не на 10-й. WIP-лимит заставляет команду доводить начатое до конца, прежде чем хвататься за новое.
Вытягивание вместо выталкивания
Kanban работает по принципу вытягивания (pull), а не выталкивания (push). Разница в том, кто инициирует движение задачи.
При выталкивании работа спускается сверху или с предыдущего этапа независимо от того, готов ли следующий её принять. Аналитик закончил спецификацию и «перебросил» её разработчикам, даже если те заняты по горло. Задачи копятся перед перегруженными этапами, образуются очереди.
При вытягивании этап забирает следующую задачу сам — но только когда у него освободилось место под WIP-лимитом. Разработчик завершил карточку, у него появился свободный слот — он идёт и берёт следующую из предыдущей колонки. Работа не проталкивается вперёд насильно, а вытягивается по мере готовности.
Что это меняет:
- Темп задаёт узкое место, а не начальник и не оптимистичный план.
- Задачи не скапливаются перед перегруженными этапами — некуда, лимит не пускает.
- Проблемы с производительностью становятся видны сразу: если колонка перед узким местом переполнена, всем очевидно, где чинить процесс.
Вытягивание превращает WIP-лимиты из формального правила в живой механизм саморегуляции потока.
Метрики потока
Kanban измеряет не «сколько story points сожгли за спринт», а как течёт работа. Три базовые метрики.
Lead time — время от момента, когда задачу взяли в работу (или даже поставили в очередь), до момента «Готово». Это то, что чувствует заказчик: сколько ждать результата после запроса. Чем меньше и стабильнее lead time, тем предсказуемее команда.
Throughput (пропускная способность) — сколько задач команда завершает за период, например за неделю. Это скорость выхода готового результата. Стабильный throughput позволяет прогнозировать: если команда делает в среднем 8 задач в неделю, то 24 задачи в очереди — это примерно три недели.
Cumulative Flow Diagram (CFD) — накопительная диаграмма потока. По горизонтали время, по вертикали количество задач, а цветные полосы показывают, сколько карточек в каждой колонке в каждый день. По CFD сразу видно:
- Расширяющаяся полоса какого-то этапа — там растёт очередь, узкое место.
- Ширина полосы «в работе» по вертикали — это текущий WIP.
- Наклон верхней и нижней границ — это lead time и throughput наглядно.
Эти метрики честнее скорости, потому что описывают доставку ценности, а не внутреннюю оценку объёма работ. Заказчику важно не сколько «попугаев» вы запланировали, а как быстро и стабильно задачи доходят до готовности.
Scrum и Kanban: когда что
Kanban часто противопоставляют Scrum, но это инструменты для разных ситуаций, а не соперники.
Scrum хорош, когда работа хорошо режется на итерации (sprint) с планированием, целью на 1-2 недели и фиксированным набором задач. Это удобно для продуктовой разработки, где команда договаривается о цели спринта и защищает её от вмешательств. Ролевая структура (Product Owner, Scrum Master), церемонии и оценка в story points дают ритм и предсказуемость.
Kanban лучше подходит, когда поток задач непрерывный и приоритеты меняются на лету:
- Поддержка и эксплуатация: заявки прилетают в непредсказуемом темпе, планировать двухнедельными итерациями бессмысленно.
- Потоковая работа с однотипными, но постоянно поступающими задачами.
- Команды, где важно в любой момент подхватить срочное, не ломая спринт.
Коротко: стабильный поток задач и поддержка — Kanban; продуктовые итерации с целью на спринт — Scrum.
Есть и гибрид — ScrumBan. Он берёт ритм и церемонии из Scrum (например, регулярную встречу для планирования), но добавляет доску с WIP-лимитами и вытягивание из Kanban, часто отказываясь от жёстких границ спринта. Это разумный выбор для команд, которые начинали со Scrum, но столкнулись с постоянным потоком срочных задач, ломающим итерации.
Коротко
- Kanban — управление потоком работы: сделать движение задач видимым и не перегружать систему.
- Доска с колонками-этапами — диагностический прибор: скопление карточек показывает узкое место.
- WIP-лимиты ограничивают число одновременных задач; по закону Литтла это сокращает время прохождения каждой задачи.
- Многозадачность вредит: последовательное выполнение доставляет первую ценность раньше, чем параллельное.
- Вытягивание (pull) — этап берёт задачу сам, когда освободился слот; темп задаёт узкое место, а не план.
- Метрики потока: lead time (время до готовности), throughput (задач за период), cumulative flow (диаграмма очередей).
- Стабильный поток и поддержка — Kanban; продуктовые итерации — Scrum; гибрид — ScrumBan.
Что почитать дальше
- Scrum — итеративный фреймворк с ролями, спринтами и церемониями.
- Модели разработки — обзор подходов к организации работы над продуктом.