Kanban

Назначение: управление потоком работы команды, визуализация и оптимизация процесса.

Аудитория: PM, Scrum Master, команды разработки, operations-команды.

Статус: устоявшийся (Андерсон, 2010).

Не путать с: Scrum (итеративный фреймворк с ролями и спринтами), WIP-лимитами (отдельный инструмент, часть Kanban), Lean (философия-предок Kanban — отдельной статьи в БЗ пока нет).

Общее #

Kanban — это метод управления потоком работы, при котором процесс становится наглядным, а объём незавершённой работы ограничивается явными лимитами. Команда не планирует работу порциями (как в спринтах Scrum), а берёт новую задачу тогда, когда в потоке появляется свободное место. Цель метода — не «делать больше», а делать быстрее, выравнивая поступление работы с пропускной способностью команды.

Слово канбан (看板, «рекламный щит», «карточка») пришло из производственной системы Toyota Production System (TPS), где инженер Оно Тайити (Taiichi Ohno) в 1950-х годах использовал физические карточки как сигнал для передачи деталей между станциями. Карточка двигалась по конвейеру и буквально «говорила» предыдущей станции: «дай мне ещё деталей». Так завод Toyota ограничивал перепроизводство — главный вид потерь в Lean.

Перенос идеи в разработку ПО выполнил Дэвид Андерсон (David J. Anderson). В 2007 году он обобщил свой опыт работы в Microsoft и Corbis и впервые представил Kanban как самостоятельный метод, а в 2010 году изложил его в книге Kanban: Successful Evolutionary Change for Your Technology Business. В отличие от Scrum, Kanban не вводит ролей, итераций и церемоний — он описывает способ управлять тем, что команда уже делает.

Ключевая идея метода — эволюционное, а не революционное изменение. Kanban не требует перестроить процесс «с нуля» или ввести новые роли; он начинается с того, что есть: текущий процесс визуализируют, ограничивают незавершённую работу и постепенно улучшают. Принцип сформулирован Андерсоном как «начните с того, что вы делаете сейчас» (start with what you do now).

Метод построен на трёх опорах:

• Визуализация — процесс отражается на Канбан-доске, где каждая стадия — отдельная колонка.
• Ограничение незавершённой работы — для колонок устанавливаются WIP-лимиты; без них доска остаётся просто картинкой.
• Непрерывное улучшение — команда управляет потоком и экспериментирует с процессом, опираясь на данные и метрики.

Kanban относится к семейству Agile-методологий: он разделяет ценности гибкости, частой поставки и непрерывного улучшения, но достигает их иным путём — через поток, а не итерации. Подробнее о месте Kanban среди подходов к управлению проектами — во введении в управление проектом.

История #

Toyota и карточки Оно Тайити #

В основе Kanban лежит производственная система Toyota (TPS), которую в 1950-х годах выстраивал Оно Тайити. Главный инструмент — карточка канбан, передававшаяся между рабочими станциями как сигнал «произведи» или «доставь». Система была нацелена на устранение семи видов потерь (муда): перепроизводства, ожидания, лишней транспортировки, излишней обработки, запасов, перемещений и дефектов. Принцип just-in-time — «точно вовремя» — означал, что каждая деталь производится ровно тогда, когда нужна следующей стадии.

Философская база TPS и производных от неё подходов позже получила имя Lean («бережливое производство»). Канбан в разработке ПО унаследовал от Lean идею потока, вытягивания (pull) и борьбы с незавершённой работой как формой «запаса». Свою книгу Оно Тайити издал в 1978 году (английский перевод — Toyota Production System: Beyond Large-Scale Production, 1988).

Перенос в программную инженерию #

Первые попытки перенести идею «вытягивания» в разработку ПО относятся к началу 2000-х. В 2004 году появились ранние описания «Kanban for Software», а реальная проработка метода связана с работой Дэвида Андерсона и его коллег (в том числе Дэвида Ардуозо) в команде Microsoft XIT (External IT) в 2004–2006 годах. Там впервые применили доску с колонками и ограничениями незавершённой работы для сопровождения внутренних ИТ-сервисов.

Параллельно Карл Скотленд (Karl Scotland) и Кори Ладас (Corey Ladas) развивали практические приёмы канбана в веб-разработке. Ладас в 2009 году издал книгу Scrumban: Essays on Kanban Systems for Lean Software Development, в которой показал гибрид канбана и Scrum — так называемый Scrumban.

Канонизация метода #

Ключевым событием стал 2010 год, когда Дэвид Андерсон опубликовал книгу Kanban: Successful Evolutionary Change for Your Technology Business. В ней метод был зафиксирован как набор из четырёх принципов и шести практик, опирающийся на две теоретические модели:

• Закон Литтла (Little’s Law, L = λW) из теории очередей — связывает число элементов в системе, скорость их поступления и среднее время выполнения.
• Теория ограничений (Theory of Constraints) Элияху Голдратта из книги The Goal (1984) — узкое место определяет пропускную способность всей системы.

В дальнейшем метод продолжил развиваться: в 2018 году вышла модель зрелости Kanban — Kanban Maturity Model (Андерсон и Теодора Божева), которая описала семь уровней зрелости организаций и связала их с практиками. Сегодня Kanban — один из двух (наряду со Scrum) самых распространённых Agile-подходов в мире.

Четыре принципа Kanban #

Андерсон сформулировал метод не как набор правил «как работать», а как принципы отношения к изменениям. Принципы описывают, как внедрять метод, а не каким должен быть процесс.

1. Начните с того, что вы делаете сейчас #

Start with what you do now. Kanban не требует менять процесс, роли или структуру команды до начала работы. Первое действие — зафиксировать текущий процесс таким, какой он есть: стадии, правила перехода, кто и что делает. Только увидев реальное положение дел, можно осмысленно его улучшать. Это отличает Kanban от Scrum, где с самого начала вводятся роли Product Owner, Scrum Master и Developers.

2. Соглашайтесь на эволюционные, постепенные изменения #

Agree to pursue incremental, evolutionary change. Вместо «большого взрыва» — перестройки процесса под новый фреймворк — команда вносит маленькие, постепенные изменения, каждое из которых можно оценить и при необходимости откатить. Эволюционный подход снижает сопротивление и риск: люди продолжают работать в привычной структуре, а изменения накапливаются шаг за шагом. В этом смысле Kanban — метод эволюционный, а не революционный.

3. Уважайте текущие роли, обязанности и ответственность #

Respect the current process, roles, responsibilities and titles. Kanban не упраздняет существующие роли и не назначает новых. Текущая организация процесса и ответственности может быть неоптимальной, но она не является препятствием для старта. Уважение к сложившейся структуре снижает страх перед изменениями и позволяет сосредоточиться на потоке работы, а не на реорганизации людей.

4. Поощряйте лидерство на всех уровнях #

Leadership at all levels. Улучшения в Kanban не исходят только от руководителя или тренера — каждый участник команды вправе предлагать и проводить эксперименты. Лидерство здесь понимается как ответственность за процесс: наблюдение за потоком, выявление узких мест, формулировка гипотез улучшения. Это перекликается с Agile-принципом о том, что лучшие решения рождают самоорганизующиеся команды.

Шесть практик Kanban #

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

1. Визуализируйте рабочий процесс #

Visualize the workflow. Процесс отражается на Канбан-доске: каждая стадия — отдельная колонка, каждая единица работы — карточка, которая движется слева направо. Колонки соответствуют реальным стадиям (например, «Бэклог → В работе → Ревью → Готово»), а на доске видны и правила перехода между ними. Цель — сделать процесс «натянутым на стекло»: любой участник в любой момент видит, где что находится, где скопилась работа и что блокирует поток.

2. Ограничьте незавершённую работу #

Limit Work in Progress. Для каждой колонки (или группы колонок) устанавливается максимальное число задач, которые могут в ней находиться одновременно, — WIP-лимит. Когда лимит достигнут, в колонку нельзя добавить новую задачу, пока оттуда не уйдёт старая. Это ключевая практика метода: без WIP-лимита Канбан-доска — это просто визуализация, а не Kanban. Лимиты заставляют команду завершать начатое, прежде чем брать новое, и делают узкие места видимыми — там, где работа скапливается, колонка «упирается» в лимит.

3. Управляйте потоком #

Manage flow. Фокус смещается с «управления людьми» на управление потоком работы — скоростью и плавностью, с которой карточки движутся через доску. Команда следит, где ускоряется и застревает поток, и действует так, чтобы карточки двигались быстрее и равномернее. Это означает, что сначала завершают начатое (вниз по течению), а уже потом берут новое (вверх по течению), — так называемый принцип «завершай, потом стартуй» (stop starting, start finishing).

4. Сделайте правила процесса явными #

Make process policies explicit. Чтобы потоком можно было управлять, правила должны быть записаны и согласованы: что значит «задача готова к переходу в следующую колонку» (Definition of Ready), что значит «задача завершена» (Definition of Done), какие критерии проверки. Явные правила превращают колонки из «статусов» в договорённости: если правило нарушено или не работает, его меняют сознательно, а не молча обходят. Без явных правил лимиты и метрики теряют смысл.

5. Внедрите циклы обратной связи #

Implement feedback loops. Kanban не предписывает фиксированных встреч, но требует регулярных циклов обратной связи — кадансов (cadences). Кадансы — это ритм встреч разного уровня: ежедневный обзор доски, еженедельный обзор очереди, ежемесячный обзор сервиса (service delivery review) и более редкий operations review — стратегический обзор нескольких команд вместе. Обратная связь замыкает цикл улучшения: данные с доски и метрик превращаются в решения о следующих экспериментах.

6. Улучшайте совместно, развивайтесь экспериментально #

Improve collaboratively, evolve experimentally. Команда улучшает процесс совместно, через проверяемые эксперименты, а не через единоличные решения руководителя. Гипотеза формулируется, проводится эксперимент (например, изменение WIP-лимита или добавление колонки), результат измеряется — и процесс обновляется. В основе этой практики лежат научные модели: теория ограничений Голдратта (работа с узким местом) и закон Литтла (математика потока). Опора на модели отличает «осознанное улучшение» от случайных догадок.

Канбан-доска #

Канбан-доска — центральный артефакт метода. Это визуальное представление процесса, где работа течёт слева направо, от запроса до результата. Доска делает три вещи: показывает текущее состояние, ограничивает объём незавершённой работы и exposes правила перехода.

Структура доски #

Минимальная Канбан-доска содержит три потока — «Сделать → В работе → Готово», — но на практике процесс детализируют под реальный поток ценности. Типовая структура для команды разработки выглядит так:

• Backlog — накопленный список всех запросов, приоритизированный сверху вниз. WIP-лимит обычно не установлен (это «озеро» входящей работы).
• Ready (или «Selected», «Next») — задачи, выбранные для ближайшей работы и готовые к старту по критериям входа (Definition of Ready). Здесь уже может действовать лимит.
• In Progress — задачи, над которыми работают прямо сейчас. Жёсткий WIP-лимит: столько задач, сколько позволяет лимит.
• Review (код-ревью, тестирование) — отдельная стадия проверки со своим лимитом, чтобы выявить узкое место между разработкой и приёмкой.
• Done — завершённые задачи, удовлетворяющие Definition of Done.

Каждая колонка может делиться на «в работе» и «готово к вытягиванию» (doing / done), что делает момент готовности к переходу явным. Вертикальные линии «пул-лэйнов» (swimlanes) разделяют потоки по классам обслуживания или командам.

Карточка #

Карточка (ticket) — единица работы на доске. Содержание зависит от зрелости команды, но типовая карточка несёт:

• Тип работы — фича, дефект, задача, запрос от заказчика. Разные типы могут иметь разные классы обслуживания.
• Описание — что нужно сделать, критерии приёмки.
• Ответственный — кто работает над задачей прямо сейчас (в Kanban желательна концентрация на одной задаче, а не «у всех по три»).
• Признак блокера — флаг, что задача стоит и ждёт внешнего события; блокер снимается с потока отдельный сигнал.
• Дата входа и выхода — для расчёта Lead Time; без временных метрик метрики невозможны.
• Класс обслуживания (class of service) — приоритет и правила обработки.

Классы обслуживания #

Классы обслуживания (Classes of Service, CoS) — это набор политик, определяющих, как разные типы работы проходят через систему. Андерсон выделил четыре стандартных класса:

• Standard — обычная работа, плановая. Идёт в порядке приоритета, ничего экстренного.
• Expedite — срочная, критичная задача (например, продакшен-инцидент). Обходит очередь, но обычно разрешается только одна-две такие задачи одновременно, чтобы «пожарная» работа не стала нормой.
• Fixed Date — задача с фиксированным сроком (релиз к дедлайну, обязательство перед регулятором). Планируется так, чтобы успеть к дате.
• Intangible — «неосязаемая» работа: технический долг, обучение, улучшение инфраструктуры. Важна, но не имеет срочности; её включают в поток, когда есть свободная пропускная способность.

Классы обслуживания превращают «всё срочное» в осознанный компромисс: команда явно выбирает, какую работу ускорять, и видит цену expedite-задачи для остального потока.

Метрики Kanban #

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

Lead Time и Cycle Time #

Lead Time (время выполнения заказа) — интервал от момента, когда запрос поступил в систему (клиент попросил фичу), до момента, когда она дошла до «Готово». Это то время, которое «чувствует» заказчик.

Cycle Time (время цикла) — интервал от момента, когда команда начала работу над задачей, до её завершения. Это то время, которое тратит команда.

Разница между ними — время ожидания в очереди (Ready). Большой разрыв означает, что задача долго лежит «в бэклоге на старт»: заказчик уже ждёт, а работа ещё не началась.

Обе метрики связаны с объёмом незавершённой работы через закон Литтла. В стационарной системе выполняется равенство L = λW, где L — среднее число элементов в системе, λ — средняя скорость их поступления (throughput), W — среднее время нахождения элемента в системе. Отсюда прямо следует практический вывод: чем меньше незавершённой работы (L), тем меньше среднее время выполнения (W) — при той же пропускной способности. Это математическое обоснование WIP-лимитов: ограничивая L, команда сокращает W и тем самым ускоряет доставку. Закон Литтла — математическая основа всего метода.

Кумулятивная диаграмма потока (CFD) #

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

Как читать CFD:

• Наклон полосы «Готово» (самой нижней) — это throughput, скорость доставки. Чем круче, тем быстрее команда выдаёт результат.
• Расстояние по вертикали между полосой «В работе» и «Готово» — объём незавершённой работы (WIP) в данный момент.
• Расширение полос (растёт расстояние между «в работе» и «готово») — WIP растёт, поток замедляется; вероятное узкое место.
• Сужение — WIP падает, поток ускоряется.

Главный диагностический сигнал — расширение верхней части диаграммы: если полоса «в работе» расползается, значит, задачи входят в систему быстрее, чем выходят, и очередь нарастает. Это ранний признак узкого места, видный за недели до того, как он станет кризисом. WIP-лимит — инструмент, который не даёт этой полосе бесконтрольно расширяться.

Throughput и Control Chart #

Throughput (пропускная способность) — число задач, завершённых за единицу времени (за день, неделю). Это «скорость выхода» потока; в отличие от velocity в Scrum, throughput измеряется в количестве задач, а не в story points, и не требует предварительной оценки сложности.

Control Chart (контрольная карта) — график, где по оси X отложено время завершения задач (Cycle Time), а по оси Y — частота. Точки сгруппированы вокруг среднего, а горизонтальные линии отмечают среднее и стандартные отклонения. Карта показывает:

• типичный Cycle Time и его разброс;
• «выбросы» — задачи, занявшие аномально долго; их разбирают как источник улучшений;
• стабильность системы — если точки укладываются в контрольные пределы, процесс предсказуем.

Service Level Expectation (SLE) #

Service Level Expectation (SLE) — прогноз сроков выполнения, построенный не на оценках, а на статистике реального потока. Вместо обещания «мы сделаем это за 5 дней» команда смотрит на распределение Cycle Time и формулирует вероятность: «85% задач такого типа мы завершаем за 8 дней или быстрее». Процентиль (обычно 50%, 85% или 95%) выбирают под терпимость заказчика к риску.

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

Kanban vs Scrum #

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

Критерий	Kanban	Scrum
Каденс (ритм)	Непрерывный поток, задача берётся при появлении места	Спринты фиксированной длины (1–4 недели)
Роли	Не предписывает	Product Owner, Scrum Master, Developers
Изменения в процессе	В любой момент — новый элемент можно добавить в очередь когда угодно	Желательны между спринтами; во время спринта цель фиксируется
Оценка задач	Не обязательна; часто обходятся без неё	Story points / планируемая скорость (velocity)
Метрики прогноза	Lead Time, Cycle Time, SLE (процентили)	Velocity (сумма story points за спринт)
Ограничение работы	Явные WIP-лимиты по колонкам	Объём, выбранный на Sprint Planning + Sprint Goal
Встречи	Кадансы на усмотрение команды	Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
Доска	Перманентная, не обнуляется	Обнуляется (создаётся заново) каждый спринт
Бэклог	Единый непрерывный, приоритизированный	Product Backlog + Sprint Backlog
Подходит для	Operations, поддержка, сопровождение, работа по запросу	Продуктовая разработка, предсказуемый спрос

Когда выбирать Kanban #

Kanban предпочтителен, когда работа приходит по запросу (on-demand), а её объём и приоритет непредсказуемы: support, maintenance, operations, инфраструктурные команды, bug-fixing. Здесь спринты искусственны — задачи нельзя «отложить до следующего спринта», их нужно брать по мере поступления. Kanban также естественен, когда переход на Scrum встречает сопротивление: метод не требует новых ролей и церемоний, а начинается с текущего процесса. Наконец, Kanban выигрывает там, где важна скорость доставки отдельных задач (Lead Time), а не ритмичная поставка инкрементов.

Когда выбирать Scrum #

Scrum лучше подходит для продуктовой разработки с предсказуемым составом команды и стабильным спросом: есть Product Owner, есть бэклог, есть возможность планировать спринты. Жёсткий ритм спринтов создаёт дисциплину планирования и обратной связи, а обязательные события (Review, Retrospective) гарантируют регулярную инспекцию. Когда нужна сильная общая цель на короткий горизонт (Sprint Goal) и явные роли ответственности — Scrum уместнее.

Scrumban #

Scrumban — гибрид, предложенный Кори Ладасом (2009): сохраняются спринты, роли и события Scrum, но планирование становится «по требованию» (pull), а вместо оценки сложности используется WIP-лимит и метрики потока. Scrumban удобен как переходный путь от Scrum к Kanban или как способ сохранить структуру Scrum, добавив контроль потока. На практике многие команды, называющие себя «скрам-командами», работают в гибридном режиме, негласно ограничивая незавершённую работу в спринте.

Масштабирование Kanban #

Kanban хорошо работает на уровне одной команды, но его принципы — визуализация, лимиты, поток, метрики — масштабируются на несколько команд и на уровень портфеля. Масштабирование не отменяет команды; оно добавляет слои координации сверху.

Уровень команды #

На уровне команды всё сводится к классическому Kanban: одна доска, WIP-лимиты по колонкам, метрики Lead/Cycle Time. Это базовый случай, на котором метод работает проще всего и где достигается быстрый эффект — поток ускоряется уже за счёт ограничения незавершённой работы и явных правил.

Несколько команд #

Когда над общим потоком работают несколько команд, появляются общие стадии и зависимости между досками. Здесь вводят upstream/downstream-доски: одна команда передаёт работу другой, и сигнал на передачу — свободное место в следующей доске (тот же принцип вытягивания, что и между колонками). Кадансы типа operations review собирают представителей команд, чтобы разобрать узкие места на стыках. Главный риск на этом уровне — локальная оптимизация: каждая команда ускоряет свой участок, а глобальный поток от этого не выигрывает (теория ограничений Голдратта: улучшать нужно узкое место всей системы, а не отдельной команды).

Portfolio Kanban и Lean Portfolio Management #

На уровне портфеля Kanban применяется к потоку инициатив: крупным темам, эпикам, инвестиционным решениям. Portfolio Kanban отражает движение инициатив от идеи через анализ к реализации и поставке, с WIP-лимитами на число одновременно анализируемых и реализуемых инициатив. Лимиты на уровне портфеля решают ту же задачу, что и на уровне команды: не дать организации взяться за слишком много одновременно и размазать усилия.

Этот подход тесно связан с Lean Portfolio Management (LPM) — практикой управления портфелем в духе Lean: финансирование по потокам ценности, а не по проектам; децентрализованные решения; явные лимиты незавершённой работы на уровне стратегических инициатив. LPM отвечает на вопрос «на что мы вообще тратим деньги и сколько одновременно», а Kanban даёт механизм — визуализацию и лимиты — для этого уровня. На масштабировании метода построена упомянутая выше Kanban Maturity Model (2018), связывающая уровни зрелости организации с применимыми практиками.

Плюсы #

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

• Плавный поток. Ограничение незавершённой работы и фокус на завершении начатого сокращают Lead Time: задачи доходят до «Готово» быстрее и предсказуемее, а не копятся в очередях.
• Минимум бюрократии и «встреч по расписанию». Метод не предписывает обязательных ролей и церемоний; кадансы команда подбирает сама. Это снижает накладные расходы и особенно ценно для команд, у которых работа приходит непредсказуемо.
• Раннее выявление узких мест. WIP-лимиты и кумулятивная диаграмма потока делают узкое место видимым задолго до того, как оно станет кризисом: колонка «упирается» в лимит, а полоса на CFD расширяется.
• Плавная адаптация к меняющемуся спросу. Работа берётся по запросу (pull): новый приоритет просто переупорядочивает входящую очередь, не требуя пересмотра «спринта» или оценок.
• Низкий порог входа. Kanban начинается с того, что уже есть: текущий процесс визуализируют и лимитируют, не меняя ролей и структуры. Это метод эволюционного изменения — его можно запустить за пару недель и постепенно улучшать.

См. также #

• WIP-лимит — ключевой механизм Kanban: без лимитов доска остаётся просто визуализацией.
• Scrum — вторая ключевая Agile-методология; сравнение с Kanban приведено в соответствующем разделе.
• Agile — семейство гибких методологий, внутри которого существует Kanban.
• Введение в управление проектом — общая карта методологий проектного управления и место Kanban среди них.

Заключение #

Kanban — это метод управления потоком, а не набор предписанных ролей и итераций. Его сила — в трёх простых опорах: визуализировать процесс, ограничить незавершённую работу и улучшать процесс экспериментально, опираясь на данные. Математический фундамент метода — закон Литтла (L = λW): чем меньше незавершённой работы, тем быстрее она выполняется, и именно это превращает ограничение WIP из «дисциплинарной меры» в инструмент ускорения.

Эволюционный характер метода — «начните с того, что есть» — делает его самым низкопороговым из Agile-подходов: команду не нужно перестраивать, достаточно увидеть поток и ограничить его. Поэтому Kanban так часто приживается там, где Scrum кажется тяжёлым: в support, operations и maintenance, где работа приходит по запросу, а не планируется спринтами. И именно поэтому метод естественно масштабируется — от колонки на доске одной команды до портфеля инициатив всей организации.