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

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

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

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

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

Промежуточный случай: внепланового много, но не большинство

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

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

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

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

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

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

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

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

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

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

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

Когда команд несколько

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

Если команды независимы и делают разное, унифицировать процесс не нужно — пусть каждая работает по своей природе работы. Сравнивать их между собой по скорости при этом нельзя: единицы оценки у каждой команды свои.

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

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

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

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

Считайте стоимость перехода заранее. Неделя-две уйдёт на перенастройку доски, правил и отчётов. Ещё один-два цикла команда будет привыкать, и скорость на это время просядет. Дороже всего обходится потеря сравнимости: накопленная статистика старого процесса к новому неприменима. Обратимость тоже разная — лимиты и фиксацию объёма снимают за день, а роли, договорённости с заказчиком и структуру бэклога собирают обратно месяцами.

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

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

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

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

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

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

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