Перейти к основному содержимому

Когда Kanban лучше Scrum


Два ответа на одну боль

И Scrum, и Kanban помогают команде поставлять ценность итеративно вместо многолетнего каскада. Разница — в ритме, обязательствах и метриках.

ВопросScrumKanban
Когда планируем?Начало спринтаReplenishment по cadence
Когда меняем приоритеты?Между спринтами (в идеале)По политикам потока
Как обещаем срок?Sprint Goal + velocityLead time / cycle time
Как ограничиваем работу?Sprint scopeWIP-лимиты

Нет "лучшего" метода — есть контекст команды. Обзор — Как выбрать процесс.


Матрица выбора

КонтекстЛучше подходит
Новый продукт, стабильный PO, нужен ритм демоScrum (7.14)
Поток багов + фич + инцидентовKanban
Жёсткий госконтракт по фазамWaterfall + Kanban внутри фазы
Команда зрелая, много прерыванийKanban или Scrumban
Нужна сертификация/ритуалы для заказчикаScrum-оболочка + Kanban внутри
Поддержка L2/L3, on-callKanban (глава 7)
Стартап, поиск product-market fitЧасто Scrum (короткие эксперименты)
Platform/SRE, много unplanned workKanban

Сигналы, что пора смотреть на Kanban

СигналПояснение
Sprint Goal рвётся каждую неделюПоток не укладывается в контейнер спринта
Velocity не помогает прогнозуStory points не коррелируют со временем
30 задач In ProgressНужны WIP, не новый спринт
"Срочно" из Slack минует доскуНужны классы обслуживания
Scrum-театр (999 Scrum)Ритуалы есть, инкремента нет
Команда support+devГлава 7

Scrumban

Scrumban — гибрид:

  • Спринт как контейнер отчётности и цели (для заказчика и PO);
  • WIP-лимиты внутри спринта;
  • пополнение backlog по мере освобождения слотов;
  • метрики cycle time дополняют velocity.

Когда Scrumban уместен

СитуацияЭлемент ScrumЭлемент Kanban
Заказчик требует "двухнедельные итерации"Sprint Review, GoalWIP, pull
P1 несколько раз за спринтSprint boundary формальныйExpedite, классы
Команда привыкла к DailyDaily остаётсяФокус на поток, не burndown

Полезно, когда заказчик требует "двухнедельные итерации", а реальность — постоянные P1.

Пример Scrumban

Sprint Goal: "Оплата картой + стабильность SLA P1".

WIP: dev = 4, review = 2.

Expedite: максимум 2 P1 за спринт; третий — эскалация на найм/on-call.

Review: показывают Done за спринт и CFD за месяц.


Kanban и Scrum — что можно комбинировать

Из ScrumИз Kanban
Daily (15 мин)WIP-лимиты
Sprint Review с демоCFD, cycle time
RetrospectiveReplenishment, delivery review
Product BacklogClasses of service
Definition of DoneExplicit policies на колонки

Не обязательно выбрасывать всё из Scrum при переходе на Kanban — выбрасывают жёсткий scope commit на спринт, если он не работает.


Waterfall + Kanban

На госпроектах фазы зафиксированы контрактом. Внутри фазы "Разработка":

  • Kanban-доска;
  • WIP и метрики для подрядчика и заказчика;
  • отчётность для контракта — milestones, не sprint burndown.

Сравнение метрик

ScrumKanban
Velocity (points/sprint)Throughput (items/week)
Sprint burndownCFD
Commitment vs Done in sprintCycle time percentiles
Forecast по average velocityForecast по 85% cycle time

Kanban не запрещает velocity — но не делает points обязательными. См. глава 4.


Роли при переходе

Scrum-рольВ Kanban
Product OwnerОстаётся — prioritizes Ready
Scrum MasterМожет стать flow coach — WIP, policies, metrics
DevelopersPull из Ready

Kanban Guide не назначает обязательных ролей — но ответственность за поток остаётся.


Сценарий миграции Scrum → Kanban

Месяц 1: добавить WIP на доску спринта, не меняя длину спринта (Scrumban).

Месяц 2: ввести классы обслуживания и cycle time отчёт.

Месяц 3: убрать обязательство "весь scope спринта", оставить Sprint Goal как ориентир.

Месяц 4: optional — убрать спринт, оставить cadence review раз в 2 недели.

Детали внедрения — STATIK.


Когда Scrum всё же лучше

  • Новая команда — Scrum даёт структуру ритуалов.
  • Нужен жёсткий инкремент каждые 2 недели для инвесторов.
  • PO учится prioritization — Sprint Planning дисциплинирует.
  • Мало прерываний — поток предсказуем.

Диагностика Scrum — 7.14/999.


Вопросы заказчика

"Мы же Agile, почему не Scrum?"Ответ
Для supportKanban — рекомендация ITIL-подобных потоков
Для продукта с P1Scrumban или Kanban
Для нового MVPScrum часто проще стартовать

Ссылайтесь на методологии, не на "моду".


Процесс меняется со временем

Процесс эволюционирует (STATIK): стартуете с того, что есть, визуализируете, вводите WIP, измеряете, меняете колонки.

Выбор Scrum или Kanban — не навсегда. Команда может вернуться к спринтам после стабилизации prod.


Scrumban на одной доске (пример)

ЭлементНастройка
Спринт2 недели, цель на стикере
WIPIn Progress ≤ 4 на весь сп sprint
ReplenishmentПонедельник + по необходимости
ReviewПятница — Done за спринт + CFD
ExpediteНе более 1 за спринт без эскалации

Burndown optional; если команда смотрит только burndown и игнорирует WIP — burndown убрать, чтобы не дублировать ложную метрику.


Decision tree для PO


Переговоры с заказчиком о смене процесса

Аргумент заказчикаОтвет PO
"Хотим sprint demo"Оставить Review раз в 2 нед, работать Kanban внутри
"Нужна velocity"Throughput + cycle time прозрачнее для ops
"Agile = Scrum в договоре"Scrumban, формулировка "итеративная поставка"
"Как прогноз без points?"85% cycle time по похожим задачам

Команды разного размера

РазмерРекомендация
3–5Kanban или Scrum, один WIP на команду
6–9Kanban + явный review WIP
10+Две доски или два потока с отдельным WIP
РаспределённаяЦифровая доска обязательна, CFD weekly

Сезонность и Kanban

Black Friday, конец квартала, релиз OS — throughput падает. Не сравнивайте CFD декабря с июнем. Заранее:

  • снизить replenishment standard work;
  • поднять intangible после сезона;
  • согласовать fixed date до marketing-кампании.

Связь с 7.14 событиями

Scrum eventKanban-аналог
Sprint PlanningReplenishment
Daily ScrumDaily + focus Blocked/WIP
Sprint ReviewDelivery review
RetrospectiveImprovement cadence
Backlog refinementGrooming Ready

Можно оставить названия Scrum для заказчика, содержание — Kanban.


Чек-лист выбора (краткий)

  • Прерывания чаще раза в день → Kanban
  • Стабильный PO + demo каждые 2 нед → Scrum
  • Договор требует спринт + P1 daily → Scrumban
  • Только support tickets → Kanban (глава 7)

Ошибки при выборе (антипаттерны)

ОшибкаПоследствие
Scrum "потому что все так делают"Scrum-театр без инкремента
Kanban без метрикДоска без прогноза
Scrumban без WIPСпринт + хаос inside
Переключение каждый месяцКоманда не учится на потоке

Стабильность процесса минимум 6–8 недель перед сменой.


Что дальше

Внедрение Kanban и типичные ошибки — пошаговый STATIK и антипаттерны.