На одном из аудитов я спросил тимлида: «Вы по скраму работаете или по канбану?»
Он завис на секунду. «По скраму. Но работу на отрезки не делим. Задачи не оцениваем. Разборы не проводим».
Я уточнил: «То есть просто доска с задачами и короткие утренние встречи?»
«Ну… в общем, да».
Это был канбан. Просто никто не сказал им об этом.
Таких команд — большинство. Одни спорят, какую методологию выбрать. Другие три года «работают по скраму» и не подозревают, что давно делают что-то совсем другое. Разберёмся, в чём разница, когда нужен каждый — и что такое Scrumban, штука, о которой говорят всё больше.
Почему их вообще путают
Внешне похоже: доска с задачами, стендапы, командная работа. Кажется, что разница небольшая.
На самом деле у них разная философия — и разные ответы на один вопрос: как работать в условиях неопределённости?
Скрам говорит: разбей работу на короткие циклы, договорись о целях заранее и защити команду от изменений внутри цикла.
Канбан говорит: не планируй далеко — просто бери следующую задачу в очереди и убирай всё, что мешает двигаться.
Это не стиль — это принципиально разные модели управления работой.
Откуда они взялись
Скрам придумали Кен Швабер и Джефф Сазерленд в 90-х под разработку ПО. Фреймворк с ролями, событиями и артефактами. Всё строго прописано в Scrum Guide.
Канбан родился в Toyota в 50-х, благодаря Тайчи Оно, японскому инженеру, как система управления производством. В IT его адаптировал Дэвид Андерсон в 2007 году. Принципиальное отличие: канбан не заменяет процесс — он его улучшает.
Скрам — это фреймворк. Канбан — это метод. Первый говорит, как работать. Второй помогает работать лучше — Дэвид Андерсон, основатель метода Kanban для IT.
В чём реальная разница
Дело не только в ритме работы. Разница в планировании неизбежно тянет за собой разницу в людях — в том, кто за что отвечает и нужны ли вообще специальные роли.
Спринты против потока
В скраме — спринты: фиксированные отрезки от одной до четырёх недель. Команда берёт задачи, берёт обязательство, закрывает спринт. Добавить задачу в идущий спринт нельзя.
В канбане спринтов нет. Задачи идут непрерывным потоком. Новый приоритет — встаёт в начало очереди, и всё.
Роли
Скрам требует трёх ролей: Product Owner, Scrum Master, команда разработки. Без них это уже не скрам — это что-то другое.
Канбан не требует ничего. Люди работают в тех же должностях. Отсюда и низкий порог входа — не нужно перестраивать структуру.
Когда и что выбирать
Нужен скрам, если:
- Работаете над продуктом с релизами по расписанию
- Задачи можно планировать на неделю-две вперёд
- Нужно регулярно показывать прогресс стейкхолдерам
- Команда новая — нужен ритм и структура
- Есть кто-то, кто потянет роль Scrum Master
Нужен канбан, если:
- Каждый день прилетают новые приоритеты
- Команда занимается поддержкой или инфраструктурой
- Хотите улучшить процесс, а не сломать его
- Команда маленькая — накладные расходы скрама не нужны
- Нет ресурса выделить Scrum Master и PO
Scrumban — гибрид, о котором говорят всё чаще
Термин ввёл Кори Ладас в 2008 году, описывая переход команд от скрама к канбану. Сегодня Scrumban — самостоятельный подход.
Типичная конфигурация:
- Планирование раз в две недели, как в скраме
- Стендапы ежедневные, но ведутся по доске, как в канбане
- WIP-лимиты — жёсткие
- Ретроспектива по расписанию
- Спринты — условные или исчезают совсем
Хорошо подходит командам, которые переросли скрам и ищут гибкости — но не готовы полностью отказаться от ритмичного планирования.
Сравнение по ключевым параметрам
Скрам и канбан — инструменты, а не религии. Команды, которые месяцами спорят «а правильный ли у нас скрам?», как правило, решают не ту проблему.
Важнее трёх вещей нет.
Видимость работы. Каждый должен понимать, что делается, что ждёт и где застряло. Это даёт любая доска — хоть скрам, хоть канбан, хоть стикеры на холодильнике. Кстати, именно здесь удобно использовать Strive: в нём можно вести и канбан-доску, и скрам-бэклог в одном пространстве — не нужно переключаться между инструментами, когда процесс эволюционирует.
Договорённости о приоритетах. Никакая методология не поможет, если каждый руководитель считает свои задачи самыми важными. Это вопрос не инструмента — это вопрос решений на уровне организации.
Регулярный разбор проблем. Ретро в скраме, разбор метрик в канбане — не важно, как называется. Важно, что команда регулярно смотрит на то, что мешает, и что-то меняет.
Команда с «неправильной» методологией, которая честно её применяет, добьётся больше, чем команда с идеально настроенным скрамом, где никто не читает доску.