Scrum или Kanban: что выбрать команде

Главный критерий: можно ли планировать на две недели

Scrum строится на предположении, что команда может взять объём работы и две недели его не менять. Если это предположение не выполняется — если каждый день приходит что-то, что нельзя отложить, — процесс будет ломаться каждый цикл, и никакая дисциплина этого не исправит.

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

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

В чём они действительно различаются

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

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

Предмет управления тоже разный. В Scrum спрашивают «что успеем за цикл», в Kanban — «за сколько дней задача проходит путь и что её держит». Соответственно и обещания заказчику формулируются по-разному: планом на цикл или статистикой времени прохождения.

Когда нужны оба

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

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

Разделять можно по-разному: отдельные доски, дежурство по очереди, фиксированная доля времени команды на поток. Что именно выбрать — вопрос объёма потока: при небольшом достаточно дежурного, при значительном нужна отдельная группа.

Переход с одного на другой

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

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

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

Scrum и Kanban: таблица различий

Быстрая проверка: что выбрать

Отметьте утверждения, верные для вашей команды. Больше отмеченных — сильнее аргумент в пользу Scrum; мало — берите Kanban.

Как это выглядит в Shtab

Оба процесса собираются из одних и тех же элементов, поэтому переход не требует переноса данных.

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