Что такое канбан простыми словами: доска, колонки и WIP-лимиты

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

Канбан простыми словами и откуда он взялся

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

Родился подход на заводах Toyota в середине XX века как часть бережливого производства. Когда на конвейере заканчивались детали, рабочий передавал карточку на предыдущий участок — это был сигнал «произведи ещё». Так производство «вытягивалось» реальным спросом, а не плановым графиком, и склады не забивались лишним.

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

Доска и колонки: как выглядит канбан на практике

Сердце метода — доска, разбитая на колонки по этапам работы. Самый базовый вариант — три колонки: «Нужно сделать», «В работе», «Готово». Реальные команды детализируют этапы под свой процесс.

Типичная доска команды разработки может выглядеть так:

• Бэклог — всё, что хотим сделать
• Готово к работе — отобрано и уточнено
• В разработке — пишется код
• Ревью — проверка коллегами
• Тестирование — проверка качества
• Готово — выкачено или принято

Каждая задача — это карточка, которая физически переезжает из колонки в колонку. По одному взгляду на доску видно, где затор: если в «Ревью» висит десяток карточек, значит код пишут быстрее, чем проверяют. О том, как грамотно проектировать этапы, мы подробно писали в материале про колонки канбан-доски.

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

WIP-лимиты и принцип вытягивания

WIP-лимит (Work In Progress, незавершённая работа) — это максимальное число задач, которое разрешено держать в колонке одновременно. Например, лимит «3» в колонке «В разработке» означает: пока там три карточки, четвёртую брать нельзя.

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

Из лимитов вырастает принцип вытягивания (pull). Задача переходит на следующий этап только тогда, когда там освободилось место, а не когда её туда «протолкнули» сверху. Освободился слот в «Тестировании» — тестировщик сам берёт следующую готовую карточку. Работа течёт по реальной пропускной способности команды, а не по желанию менеджера загрузить всех под завязку.

Метрики потока: чем измерять канбан

Канбан управляется не оценками в часах, а измерением фактического потока. Три ключевые метрики:

• Время цикла (cycle time) — сколько проходит от момента, когда задачу взяли в работу, до её завершения. Это главный показатель скорости.
• Пропускная способность (throughput) — сколько задач команда завершает за период, например за неделю.
• Незавершённая работа (WIP) — сколько задач в работе прямо сейчас.

Эти три величины связаны: чем меньше задач в работе, тем короче время цикла. Чтобы прогнозировать сроки, команды строят накопительную диаграмму потока и считают перцентили: например «85% задач закрываются за 6 дней или быстрее». Это честнее, чем обещать точную дату, и помогает защитить оценку перед заказчиком фактами, а не интуицией.

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

Канбан и скрам: в чём разница

Канбан и скрам часто противопоставляют, хотя они решают разные задачи. Скрам организует работу через фиксированные итерации (спринты), роли (владелец продукта, скрам-мастер) и церемонии. Канбан же — это непрерывный поток без обязательных спринтов и ролей.

Коротко об отличиях:

• Ритм: скрам работает спринтами по 1—2 недели, канбан — непрерывно, задачи поступают по мере готовности
• Изменения: в скраме состав спринта стараются не трогать до его конца, в канбане приоритеты можно менять в любой момент
• Метрики: скрам опирается на velocity и стори-поинты, канбан — на время цикла и пропускную способность
• Внедрение: скрам требует перестроить процесс, канбан накладывается на существующий

Канбан хорошо подходит командам поддержки, DevOps, потоку входящих заявок и любой работе с непредсказуемым потоком. Скрам — продуктовым командам, которым нужны планируемые релизы. Многие совмещают подходы. Полное сравнение мы разобрали в статье канбан против скрама.

Как начать и где вести доску

Внедрить канбан можно за один день, и это его сила. Минимальный план:

• Нарисуйте текущий процесс как колонки — честно, как работа идёт на самом деле
• Перенесите все активные задачи на доску
• Поставьте WIP-лимиты на ключевые колонки и начните их соблюдать
• Раз в неделю смотрите на метрики и убирайте заторы

Физическая доска со стикерами работает для команды в одной комнате, но для распределённых команд и для метрик нужен цифровой инструмент. В TeamVector канбан-доска связана с остальным контуром проекта: одна и та же задача видна и на доске, и на диаграмме Ганта с критическим путём, а статусы подтягиваются из связанных коммитов и веток GitLab. Это убирает двойной учёт — разработчику не нужно вручную двигать карточку, если он закрыл задачу в Git.

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

Частые вопросы