6 основных практик Канбан-метода

Когда я впервые показал команде доску с тремя колонками — «Надо», «Делаю», «Готово» — все обрадовались. Порядок, прозрачность, красота. Через три недели задачи перестали двигаться. Колонка «Делаю» раздулась до 40 карточек, никто не понимал, кто за что отвечает, и люди начали прятать задачи, чтобы не получать новые.

Я тогда работал в продуктовой команде из восьми человек. Мы думали, что внедрили Канбан. На самом деле мы повесили доску — и на этом остановились.

Разница между «доской» и «Канбан-методом» — в шести практиках. Без них доска — это просто список дел с красивым интерфейсом.

Почему «просто доска» — не Канбан

Канбан-метод сформулировал Дэвид Андерсон в 2007 году, опираясь на производственную систему Toyota. Это не инструмент и не приложение — это метод управления потоком работы через постепенные изменения в существующем процессе.

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

Метод держится на шести практиках. Они не работают по отдельности — каждая усиливает остальные. Вот они по порядку.

Практика 1. Сделать невидимую работу видимой

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

Как выглядит типичная ошибка

Большинство команд начинают с трёх колонок: To Do → In Progress → Done. Это не описание процесса — это описание состояния. Задача «в работе» может означать что угодно: её пишут, её правят, она ждёт ревью, она завернулась на доработку.

Настоящая визуализация выглядит иначе:

Бэклог → Уточнение → Разработка → Код-ревью → Тестирование → Готово к деплою → Задеплоено

Каждая колонка — конкретный шаг. Команда видит не «кто чем занят», а «где сейчас находится работа».

Swimlanes и блокеры

Если команда обрабатывает разные типы задач — фичи, баги, техдолг — их стоит разделить горизонтальными дорожками (swimlanes). Иначе баги будут конкурировать с плановыми задачами в одной очереди, и приоритеты будут размываться.

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

Визуализация — это не про красоту. Это про то, чтобы проблемы стало невозможно не заметить — Дэвид Андерсон

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

Практика 2. Меньше задач одновременно — быстрее результат

WIP расшифровывается как Work In Progress — незавершённая работа. WIP-лимиты — это ограничение на количество задач, которые команда или конкретный человек может вести одновременно.

Интуитивно кажется, что больше задач в работе = больше прогресса. На деле всё наоборот.

Закон Литтла в одном предложении

Чем больше задач одновременно в системе, тем дольше каждая из них добирается до готовности. Это математика, а не мнение.

Цифры условные, но пропорция реальная — её легко проверить на своих данных за последние два месяца.

Как поставить лимит

Простое правило для старта: WIP = количество человек в команде × 1,5. Это не идеал, но лучше, чем ничего. Дальше лимит корректируется на основе реального Cycle Time.

Что делать, когда лимит нарушен: не брать новую задачу, а помочь протолкнуть существующую. Это называется «stop starting, start finishing» — один из базовых принципов метода.

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

Практика 3. Найти узкое место раньше, чем оно остановит всё

Управление потоком — это наблюдение за тем, как задачи движутся через систему, и устранение того, что их тормозит.

Поток нарушен, когда задачи накапливаются в одной колонке, пока соседние стоят пустыми. Это называется узким местом — и оно всегда есть. Вопрос только в том, где именно.

Как читать накопительную диаграмму потока

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

• одна полоса резко расширяется — там скапливается работа
• разрыв между полосами растёт — Cycle Time увеличивается
• плато на диаграмме — поток остановился

Пример из практики: в одной из команд код-ревью занимало в среднем 4 дня. Разработчик писал задачу за 2 дня, а потом она лежала в очереди к единственному senior-разработчику. Решение оказалось простым — выделить одного junior для парного ревью. Среднее время ревью сократилось до полутора дней.

Шаг для команды: посмотрите, в какой колонке задачи стоят дольше всего. Это ваше первое узкое место.

Практика 4. Правила должны висеть на стене, а не жить в голове

Явные политики — это зафиксированные вслух договорённости о том, как работает система. Когда задача переходит в следующую колонку? Что значит «готово»? Кто принимает решение о приоритете?

Почему устные договорённости не работают

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

Явная политика для колонки «Готово к тестированию» может выглядеть так:

• код прошёл автотесты
• написан unit-тест для новой логики
• задача описана в PR с примером воспроизведения
• разработчик проверил на staging-окружении

Если хотя бы один пункт не выполнен — задача остаётся в разработке. Без обсуждений.

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

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

Шаг для команды: напишите Definition of Done для одной колонки — той, где чаще всего возникают вопросы «а это уже готово?». Согласуйте за 15 минут.

Практика 5. Регулярные встречи, которые реально меняют процесс

В Канбан нет одного стендапа — есть система встреч с разными горизонтами. Каждая решает свою задачу.

Чем Daily Kanban отличается от скрам-стендапа

В Scrum стендап ходит по людям: «Что делал вчера? Что буду делать сегодня? Есть ли препятствия?»

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

На практике такой формат занимает меньше времени и снимает ощущение отчёта.

Шаг для команды: на следующем стендапе начните не с людей, а с правой колонки доски. Пройдитесь по каждой задаче: что мешает, что нужно.

Практика 6. Менять процесс маленькими шагами — не революциями

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

Принцип одного изменения

Любое улучшение — это гипотеза: «Если мы сделаем X, то Y улучшится». Одна гипотеза, один эксперимент, одна метрика. Иначе невозможно понять, что именно сработало.

Пример: команда предположила, что уменьшение WIP-лимита с 8 до 5 сократит Cycle Time. Поставили эксперимент на две недели, измерили. Cycle Time сократился с 12 до 8 дней. Зафиксировали изменение.

Мы в Strive встроили этот принцип в сам продукт — в Strive можно отслеживать Cycle Time и Throughput прямо внутри доски, без отдельных таблиц. Когда метрика видна в реальном времени, команда начинает задавать правильные вопросы сама — без коуча рядом.

С чего начать прямо сейчас

Шесть практик не нужно внедрять одновременно. Есть минимальный жизнеспособный Канбан, с которого можно начать за один день:

1. Визуализация — нарисуйте реальный маршрут задачи, а не идеальный
2. WIP-лимиты — поставьте любой лимит на колонку «В работе»
3. Явные политики — напишите DoD для одной колонки

Остальные три практики — поток, встречи, улучшение — придут сами, как только первые три начнут работать.

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