Скрам и канбан: отличия, что выбрать и зачем некоторые команды используют оба инструмента
На одном из аудитов я спросил тимлида: «Вы работаете по скраму или канбану?» Он подумал секунду и сказал: «По скраму, но без спринтов. И без стори-поинтов. И ретро мы не проводим». Я уточнил: «То есть у вас просто доска и стендап?» — «Ну да». Это был канбан. Они просто не знали.
Путаница между скрамом и канбаном встречается постоянно — и у тех, кто только выбирает методологию, и у тех, кто давно работает. Эта статья расставит по местам: чем скрам и канбан отличаются, когда нужен каждый, и что такое Scrumban — гибрид, о котором говорят всё чаще.
Почему скрам и канбан постоянно путают
Внешне они похожи: и там, и там есть доска с задачами, ежедневные стендапы и фокус на командной работе. Это создаёт ощущение, что разница косметическая. На самом деле у них разная философия и разные ответы на один вопрос: как управлять неопределённостью?
Скрам говорит: разбей работу на короткие циклы, договорись о целях заранее и защити команду от изменений внутри цикла. Канбан говорит: не планируй далеко вперёд — просто делай следующую задачу в очереди и убирай то, что мешает двигаться.
Откуда они появились — и почему это важно
Скрам создали Кен Швабер и Джефф Сазерленд в 1990-х для разработки программного обеспечения. Он изначально проектировался как фреймворк: с ролями, событиями и артефактами. Всё строго описано в Scrum Guide.
Канбан появился в Toyota в 1950-х как производственная система управления запасами, а в IT его адаптировал Дэвид Андерсон в 2007 году. В отличие от скрама, канбан — это метод улучшения существующего процесса, а не замена ему.
Скрам — это фреймворк. Канбан — это метод. Первый говорит, как работать. Второй помогает работать лучше — Дэвид Андерсон, основатель метода Kanban для IT.
Скрам и канбан: главные отличия
Разберём ключевые точки расхождения — не абстрактно, а на конкретных ситуациях.
Итерации против непрерывного потока
В скраме работа делится на спринты — фиксированные отрезки времени от одной до четырёх недель. В начале спринта команда берёт задачи из бэклога и берёт на себя обязательство сделать их до конца. Добавить задачу в идущий спринт нельзя — только в следующий.
В канбане спринтов нет. Задачи поступают и выполняются непрерывно. Приоритеты можно менять в любой момент — новая срочная задача встаёт в начало очереди, и всё.
Это принципиальное отличие определяет, какому типу команд подходит каждый метод:
- Скрам — для команд, которые работают над продуктом с понятными целями на ближайшие недели
- Канбан — для команд, где поток задач непредсказуем: поддержка, багфиксинг, операционные команды
- Обоим методам одинаково нужна видимость работы — доска обязательна в любом случае
Роли: жёсткие против гибких
Скрам требует трёх ролей: Product Owner (владелец продукта), Scrum Master (фасилитатор процесса) и команда разработки. Без этих ролей скрам, строго говоря, не скрам.
Канбан не требует никаких новых ролей. Люди продолжают работать в тех же должностях. Это одна из причин, почему внедрить канбан проще — он не перестраивает организационную структуру.
Метрики: разные вопросы — разные цифры
Скрам и канбан измеряют разные вещи, потому что задают разные вопросы:
| Вопрос | Скрам | Канбан |
|---|---|---|
| Сколько мы делаем? | Velocity (стори-поинты за спринт) | Throughput (задач в неделю) |
| Укладываемся ли в сроки? | Burndown chart | Cycle time (время от старта до финиша) |
| Где узкие места? | Sprint retrospective | Cumulative flow diagram |
| Что делать дальше? | Sprint planning | Приоритет в бэклоге |
Когда выбирать скрам, а когда канбан
Нет универсального ответа — есть контекст. Вот как его читать.
Признаки того, что вам нужен скрам
- Команда работает над продуктом с дорожной картой и релизами по расписанию
- Задачи можно планировать заранее хотя бы на одну-две недели
- Важно регулярно показывать прогресс стейкхолдерам — спринт-ревью для этого идеально подходит
- Команда новая и нуждается в ритме и структуре, чтобы выработать привычки
- Есть ресурс на Scrum Master — человека, который будет следить за процессом
Признаки того, что вам нужен канбан
- Поток задач непредсказуем: каждый день прилетают новые приоритеты
- Команда занимается поддержкой, инфраструктурой или операционными задачами
- Вы хотите улучшить существующий процесс, а не менять его полностью
- Маленькая команда или один человек — накладные расходы скрама не оправданы
- Нет возможности выделить Scrum Master и владельца продукта
Когда не работает ни тот ни другой
Обе методологии бессильны, если в организации нет базовой культуры договорённостей. Скрам развалится, если Product Owner не может принимать решения. Канбан деградирует, если никто не соблюдает WIP-лимиты. Инструмент не лечит дисфункцию — он её проявляет.
Scrumban: что это и когда он имеет смысл
Scrumban — это гибрид, который берёт структуру из скрама и гибкость из канбана. Термин ввёл Коrey Ladas в 2008 году, описывая переход команд от скрама к канбану.
На практике Scrumban выглядит так: команда сохраняет некоторые ритуалы скрама, но добавляет канбан-механику. Типичная конфигурация:
- Планирование — раз в две недели, как в скраме
- Стендапы — ежедневные, но ведутся по доске, как в канбане
- WIP-лимиты — жёсткие, как в канбане
- Ретроспектива — по расписанию, как в скраме
- Спринты — исчезают или становятся условными
Scrumban хорошо работает для команд, которые переросли скрам и ищут больше гибкости, но не готовы полностью отказаться от ритмичного планирования.
Сравнительная таблица: скрам и канбан по ключевым параметрам
| Параметр | Скрам | Канбан |
|---|---|---|
| Цикличность | Спринты (1–4 нед.) | Непрерывный поток |
| Роли | 3 обязательные роли | Нет новых ролей |
| Изменение приоритетов | Только между спринтами | В любой момент |
| Ограничение WIP | Через объём спринта | Явные WIP-лимиты |
| Метрика времени | Velocity | Cycle time |
| Церемонии | Планирование, ревью, ретро, стендап | Только стендап (по желанию) |
| Сложность внедрения | Высокая | Низкая |
| Лучше для | Продуктовая разработка | Поддержка, ops, сервисы |
Что на самом деле важнее методологии
Скрам и канбан — это инструменты, а не религии. Команды, которые тратят месяцы на споры «мы делаем правильный скрам или нет?», как правило, решают не ту проблему.
Важнее методологии — три вещи:
- Видимость работы. Каждый в команде должен понимать, что сейчас делается, что ждёт и где застряло. Это даёт любая доска — хоть скрам, хоть канбан, хоть стикеры на холодильнике.
- Договорённости о приоритетах. Методология не поможет, если каждый руководитель считает свои задачи самыми важными. Это вопрос не инструмента, а решений на уровне организации.
- Регулярный разбор проблем. Ретроспектива в скраме, разбор метрик в канбане — не важно, как это называется. Важно, что команда регулярно смотрит на то, что мешает работать, и что-то меняет.
Команда, которая выбрала «неправильную» методологию, но честно её применяет, добьётся больше, чем команда с идеально настроенным скрамом, где никто не читает доску.
Скрам и канбан решают одну и ту же задачу — помогают команде организовать работу и быстрее доводить задачи до результата, — но делают это разными способами. Скрам строится вокруг спринтов, ролей и регулярных церемоний, тогда как канбан делает акцент на непрерывном потоке задач и визуализации процесса. Выбор между ними зависит от характера проекта и стиля работы команды: где-то важна чёткая структура и планирование, а где-то гибкость и плавный поток задач. Поэтому многие команды комбинируют оба подхода, используя канбан-доску для визуализации работы внутри скрам-процесса.
