Kanban: поток, WIP-лимиты и вытягивание

← назад к разделу

Команда завела доску, расставила задачи по колонкам — и решила, что теперь у неё Kanban. На самом деле Kanban начинается не с доски, а с двух идей: сделать поток работы видимым и ограничить количество дел, которые команда тащит одновременно. Без этого доска — просто список задач в трёх столбиках.

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

Откуда это пришло: сигнальная карточка с завода

Слово «вытягивание» звучит как выдумка консультантов, пока не знаешь, откуда оно.

Kanban (по-японски примерно «сигнальная карточка») — часть производственной системы Toyota, которую там выстраивали с пятидесятых годов. Идея была простая и физическая: участок не делает деталей «на всякий случай», а ждёт карточку с следующего участка. Карточка означает «у меня освободилось место, можно подавать следующую». Нет карточки — нет производства, и склад между участками не растёт. Оттуда же пришло представление, что запас незавершённой работы — это не задел, а замороженные деньги и спрятанные проблемы: пока деталь лежит в очереди, дефект в ней ещё не найден.

К разработке программ это приложил Дэвид Андерсон в середине двухтысячных — сначала в Microsoft, потом в Corbis, где команда поддержки жила в потоке заявок и Scrum ей не подходил. Книга, с которой метод разошёлся, вышла в 2010 году. Андерсон же сформулировал метод не как «доска с колонками», а как набор практик: сделать работу видимой, ограничить незавершённое, управлять потоком, сделать правила явными, ввести циклы обратной связи, улучшать совместно.

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

Доска как карта потока

Основной инструмент Kanban — доска с колонками. Каждая колонка — это этап, через который проходит задача: например, Backlog → Анализ → Разработка → Тестирование → Готово. Задача (карточка) движется слева направо, и в любой момент видно, где она находится и что с ней происходит.

Важное отличие от простого to-do-списка: колонки в Kanban описывают реальные этапы вашего процесса, а не абстрактные «сделать / делаю / сделано». Если между разработкой и тестированием у вас есть code review — заводите отдельную колонку. Иначе доска не покажет, где на самом деле буксует работа.

Что даёт визуализация:

• Видно, на каком этапе скапливаются задачи — это и есть узкое место потока.
• Видно, кто чем занят и не перегружен ли какой-то этап.
• Видно «зависшие» карточки, которые давно не двигались.

Доска — не украшение, а диагностический прибор: скопление карточек в колонке говорит, что там тормозит — не хватает людей, задачи слишком крупные или следующий этап не успевает их забирать.

Правила колонок, записанные явно

Колонки честно называют этапы — и ровно здесь начинается ежедневный спор: «это уже в тестировании или ещё нет?», «почему карточка висит в ревью, если ревьюер её не видел?». Спор повторяется потому, что условие перехода живёт в головах, и у каждого своё.

Лечится это скучно: у каждой колонки записывают условие входа и условие выхода. Не инструкцию на страницу, а две-три строки прямо на доске.

Что это меняет на практике:

• Исчезает спор о состоянии. Карточка в колонке ровно тогда, когда выполнено условие входа, а не тогда, когда кто-то её перетащил.
• Видно фальшивое движение. Перетащить карточку в «Тестирование», пока стенд не собран, теперь означает нарушить записанное правило, а не «немного опередить события».
• Правила становятся предметом изменения. Явное правило можно обсудить на встрече и поменять; неявное только нарушают.

Это одна из опор метода, и её формулируют коротко: делайте правила явными. То же относится к самим лимитам (число на колонке — это правило), к порядку в очереди и к тому, что считается готовым.

WIP-лимиты: почему меньше значит быстрее

Человек ведёт пять задач и не может сказать, когда закончит хоть одну, — вот это и меряют. WIP (Work In Progress) — количество задач, которые находятся в работе одновременно. Главная механика Kanban — ставить лимиты на WIP: например, «в колонке Разработка одновременно не больше двух карточек».

На первый взгляд это звучит контринтуитивно: разве ограничение не замедлит команду? Наоборот. Объясняет это закон Литтла — простое соотношение из теории очередей:

Среднее время прохождения = Среднее число задач в работе / Пропускная способность

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

Но на спокойном отрезке смысл такой: чем больше задач вы держите в работе одновременно, тем дольше в среднем каждая из них проходит путь до «Готово». Пропускная способность у команды своя и быстро не меняется, а число одновременных задач как раз и регулируется лимитом. Подставим числа — команда доводит до «Готово» восемь задач в неделю:

живой пример

throughput = 8  # задач в неделю доходит до «Готово»
for wip in (24, 16, 8):
    print(f"в работе {wip:2} -> каждая задача идёт {wip / throughput:.1f} нед.")

Втрое меньше задач в работе — втрое короче ожидание, при той же команде и той же скорости.

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

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

Это и показано на анимации выше. Пять задач по два дня работы каждая: возьмёшь все пять сразу — до 10-го дня не готово ничего; будешь вести по очереди — первая уйдёт заказчику на 2-й день, вторая на 4-й и так далее. Суммарно те же 10 дней — и это ещё щедрый счёт в пользу верхней доски: цену переключений мы в ней не учли, а с ней последняя задача уехала бы дальше 10-го дня. Зато ценность пошла в пять раз раньше. WIP-лимит и заставляет доводить начатое до конца, прежде чем хвататься за новое.

Заблокированная карточка

Карточка ждёт ответа от смежной команды, доступа, ответа заказчика. Работать по ней нельзя. Соблазн понятный: отложить её в сторонку, чтобы не занимала слот, и взять новую.

Так делать нельзя, и это принципиально. Заблокированная карточка остаётся в колонке и продолжает занимать место под лимитом. Иначе лимит обходится законным путём: в работе честные две карточки и ещё пять «отложенных», то есть ровно то состояние, от которого лимит защищает. Плюс ожидание перестаёт попадать в замеры: карточка, ушедшая с доски, не копит время в колонке, и отчёт получается красивее реальности.

Как с ней обращаются:

• Отметка блокировки — заметная: другой цвет, флажок, наклейка. На доске должно быть видно не только «где карточка», но и «почему стоит».
• Записывают причину и дату. Через месяц это единственный способ узнать, что команда четыре раза за квартал стояла из-за одного и того же согласования.
• У блокировки есть владелец — конкретный человек, который её снимает. Не «команда», не «ждём»: у ожидания должно быть имя.
• Снятие блокировки важнее нового кода. Разблокировать начатое приоритетнее, чем начать следующее, — это та же мысль, что и в лимите.
• Если блокировок много, лимит поднимать не надо. Соблазн «поднять лимит, раз половина стоит» лечит симптом. Правильный ответ — считать блокировки и убирать их причины: это самый дешёвый способ ускорить поток без найма.

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

Вытягивание вместо выталкивания

Kanban работает по принципу вытягивания (pull), а не выталкивания (push). Разница в том, кто инициирует движение задачи.

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

При вытягивании этап забирает следующую задачу сам — но только когда у него освободилось место под WIP-лимитом. Разработчик завершил карточку, у него появился свободный слот — он идёт и берёт следующую из предыдущей колонки. Работа не проталкивается вперёд насильно, а вытягивается по мере готовности.

Что это меняет:

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

Что делать с найденным узким местом

Доска показала: в «Тестировании» девять карточек, лимит четыре, дальше пусто. Узкое место найдено. Почти все команды на этом останавливаются — «ну да, видим» — и продолжают брать новое в начало доски. От этого очередь растёт.

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

Что это значит буквально, по шагам:

1. Перестать вливать. Никто не берёт новую карточку из очереди, пока затор не рассосался. Свободный разработчик не начинает следующую задачу — у него нет на это слота, и это правильно.
2. Помочь там, где затор. Разработчик садится проверять по критериям приёмки, разбирать дефекты, готовить данные и стенд. Да, он делает это хуже тестировщика. Но восемь часов «хуже, чем тестировщик» разгружают поток сильнее, чем восемь часов идеального кода, который встанет в ту же очередь.
3. Убрать из узкого места лишнее. Часть работы в заторе часто не требует его квалификации: подготовка окружения, прогон рутинных проверок, оформление дефектов. Это выносят.
4. Посмотреть, что туда приходит. Девять карточек в тестировании — иногда не проблема тестирования, а проблема размера карточек или качества кода перед ним. Если половина возвращается с дефектами, разгружать надо не колонку, а причину.
5. Только потом менять лимиты и людей. Постоянное узкое место на одном и том же этапе — сигнал о структуре: не хватает человека, не хватает автоматизации, слишком много ручных шагов. Но это вывод по нескольким неделям, а не по одному утру.

Правило, которое стоит унести: поток идёт со скоростью узкого места, поэтому улучшение в любом другом месте ничего не даёт. Ускорили разработку вдвое, а тестирование не тронули — получили ту же скорость поставки и вдвое более длинную очередь. Это и есть причина, по которой «все загружены» и «работа идёт быстро» — разные вещи.

Классы обслуживания: куда девать срочное

Главный практический вопрос потоковой команды: прилетел инцидент, а лимит забит. Куда его? Ответ «разберёмся по ситуации» означает, что каждый раз это будет решать тот, кто громче.

Kanban отвечает заранее: у карточек есть классы обслуживания — заранее договорённые правила обращения с разными видами работы.

Что важнее самой таблицы — договорённости вокруг неё:

• Срочный класс ограничен по числу. Одна срочная карточка на доске, максимум две. Иначе «срочное» становится обычным потоком, и лимит снова ничего не значит.
• Признак срочного записан заранее. Не «важно для руководителя», а проверяемое условие: недоступность, потеря денег, нарушение обязательства перед заказчиком. Спор о приоритете переносится на момент, когда никто не нервничает.
• За срочное платят видимо. Срочная карточка выталкивает обычную работу, и это должно быть видно на доске, а не всплывать в конце недели как «мы не успели».
• Класс определяет и ожидания по срокам. Обычной карточке обещают вилку по истории потока, неопределённой не обещают ничего — это честнее, чем называть дату и не выполнять.

Команды поддержки часто идут дальше и резервируют мощность: например, держат один слот в колонке «Разработка» только под срочное. Слот простаивает, когда инцидентов нет, — и это цена за то, что инцидент не ломает всё остальное.

Метрики потока

Kanban измеряет не «сколько story points сожгли за спринт», а как течёт работа. Три базовые метрики.

Lead time — время от появления запроса, то есть от попадания карточки в очередь, до момента «Готово». Это то, что чувствует заказчик: сколько ждать результата после просьбы. Отдельно считают время работы над карточкой — от момента, когда её взяли в колонку «Разработка», и это в трекерах отдельная метрика, не та же самая; путать их нельзя, иначе ожидание в очереди из отчёта выпадает и он получается красивее реальности. Чем меньше и стабильнее lead time, тем предсказуемее команда.

Throughput (пропускная способность) — сколько задач команда завершает за период, например за неделю. Стабильный throughput позволяет прогнозировать: если команда делает в среднем 8 задач в неделю, то 24 задачи в очереди — это примерно три недели.

Cumulative Flow Diagram (CFD) — накопительная диаграмма потока. По горизонтали время, по вертикали количество задач, а цветные полосы показывают, сколько карточек в каждой колонке в каждый день. По CFD сразу видно:

• Расширяющаяся полоса какого-то этапа — там растёт очередь, узкое место.
• Ширина полосы «в работе» по вертикали — это текущий WIP.
• Наклон верхней границы — темп прихода, нижней — throughput; расстояние между ними по горизонтали — lead time.

Эти метрики честнее скорости: они описывают доставку, а не внутреннюю оценку объёма работ, — заказчику важно не сколько «попугаев» запланировали, а как быстро и стабильно задачи доходят до готовности.

Прогноз из пропускной способности

Метрики выше описывают прошлое. Заказчику нужно другое: «когда будет готово?» Kanban отвечает на это без оценок вообще — из истории потока.

Возьмём команду, которая доводит до готового в среднем восемь карточек в неделю, а по неделям это выглядело так: 6, 9, 8, 5, 11, 7. В очереди 24 карточки.

Заказчику называют вилку: от двух до пяти недель, вероятнее три. Это и есть прогноз: не одно число, а диапазон, посчитанный из фактов, а не из ощущений.

Три условия, без которых он врёт:

• Карточки сравнимы по размеру. Не одинаковы, а сравнимы: разброс в пять раз ещё терпим, в пятьдесят — нет. Поэтому крупное дробят, а «эпик» в очередь не ставят.
• Очередь не пополняется по дороге. Если за три недели в неё прилетит ещё двадцать карточек, прогноз был верен и бесполезен. Поэтому считают по фиксированному набору и отдельно смотрят темп прихода.
• Процесс не менялся. История шести недель описывает ту команду и тот процесс. После смены половины состава или ухода ручного тестирования в автоматику историю считают заново.

Дальше есть более честный инструмент: розыгрыш на истории. Вместо среднего берут случайную неделю из прошлых, потом ещё одну, и так пока не наберётся 24 карточки; повторяют такой розыгрыш тысячу раз и смотрят распределение. Ответ получается в виде «в 85 % розыгрышей уложились в четыре недели». Считается это в любой таблице за десять минут, а звучит для заказчика убедительнее любой оценки, потому что опирается на то, как эта команда работала на самом деле.

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

Scrum и Kanban: когда что

Kanban часто противопоставляют Scrum, но это инструменты для разных ситуаций, а не соперники.

Scrum хорош, когда работа режется на итерации (sprint) с целью на 1-2 недели и фиксированным набором задач, а команда защищает эту цель от вмешательств. Ролевая структура (Product Owner, Scrum Master), церемонии и оценка в story points дают ритм и предсказуемость.

Kanban лучше подходит, когда поток задач непрерывный и приоритеты меняются на лету:

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

Есть и гибрид — ScrumBan. Он берёт ритм и церемонии из Scrum, но добавляет доску с WIP-лимитами и вытягивание из Kanban, часто отказываясь от жёстких границ спринта. Это разумный выбор для команд, которые начинали со Scrum, но столкнулись с постоянным потоком срочных задач, ломающим итерации.

Глубже: метрики снаружи: четыре метрики поставкирасширенное

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

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

Связь с потоком прямая. Время от коммита до прода это хвост lead time карточки, и если карточка идёт три дня, а до прода доезжает через две недели, узкое место не в разработке, а в выпуске: ручное тестирование, окно выката, очередь на ревью. WIP-лимит на колонку «готово к выкату» ловит это так же, как на колонку «в работе». Доля неудачных изменений растёт вместе с размером изменения, и это аргумент за маленькие карточки сильнее любого другого.

Снимают их не руками: события выката и инциденты связывают с коммитами, и метрики считаются из конвейера, о чём статья про принципы конвейера в разделе CI/CD. На доске команды рядом с потоком висят эти четыре, и ретроспектива смотрит на них раньше, чем на velocity.

Коротко

• Kanban — управление потоком работы: сделать движение задач видимым и не перегружать систему. Доска с колонками-этапами — диагностический прибор: скопление карточек показывает узкое место.
• WIP-лимиты ограничивают число одновременных задач: по закону Литтла это сокращает время прохождения каждой, а последовательная работа отдаёт первую ценность раньше параллельной. Вытягивание (pull) — этап берёт задачу сам, когда освободился слот; темп задаёт узкое место, а не план.
• Метрики потока: lead time (время до готовности), throughput (задач за период), cumulative flow (диаграмма очередей). Стабильный поток и поддержка — Kanban; продуктовые итерации — Scrum; гибрид — ScrumBan.
• Снаружи команду меряют четырьмя числами: частота выкатки, время от коммита до прода, доля неудачных изменений, время восстановления; узкое место часто не в разработке, а в выпуске, и WIP-лимит на «готово к выкату» его ловит.
• Kanban пришёл из производственной системы Toyota (сигнальная карточка «можно подавать следующую»), к разработке его приложил Дэвид Андерсон в середине двухтысячных; метод накладывают на текущий процесс, не заменяя его.
• У каждой колонки записывают условие входа и выхода — тогда исчезает спор о состоянии карточки, видно фальшивое движение, а правило можно обсудить и поменять.
• Заблокированная карточка остаётся на доске и занимает место под лимитом; у блокировки есть заметная отметка, записанная причина и владелец, который её снимает.
• Найденное узкое место разгружают всей командой, а не берут новое: поток идёт со скоростью узкого места, поэтому ускорение в другом месте только удлиняет очередь.
• Классы обслуживания договариваются заранее: срочный класс ограничен по числу и с проверяемым признаком, у работы с датой планируют от даты назад, неопределённой дату не обещают.
• Прогноз считают из пропускной способности: вилка по худшей и лучшей неделе, в пределе розыгрыш на истории — при сравнимых карточках и неизменном процессе.

Что почитать дальше

• Scrum — итеративный фреймворк с ролями, спринтами и церемониями: с чем Kanban чаще всего сравнивают.
• Оценка и планирование — story points и velocity: чем оценка отличается от замера потока.
• Модели разработки — обзор подходов к организации работы над продуктом.
• Extreme Programming — инженерные практики, без которых частая доставка небезопасна.
• Принципы CI/CD - где считают четыре метрики поставки и почему путь до прода чаще тормозит в выпуске, а не в разработке.