Scrum и Kanban: в чём разница

Два самых распространённых способа организовать работу по Agile. Разбираем механику каждого, сравниваем в таблице и решаем, что выбрать под свою ситуацию — включая гибрид.

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

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

Scrum: работа пачками с фиксированным тактом

Каркас Scrum держится на трёх опорах.

Спринт — таймбокс

Итерация фиксированной длины (обычно 1–4 недели, чаще всего две). Длина не меняется от спринта к спринту: это метроном, который задаёт ритм всей остальной механике. В начале спринта команда набирает объём, в конце показывает работающий инкремент. Спринт не продлевают — если не успели, объём переносится, а дата остаётся.

Цель спринта — то самое «обязательство»

Тут важная тонкость, на которой ломается половина команд. Обязательство в современном Scrum — это не «мы клянёмся закрыть все 14 задач». Это цель спринта: одно предложение о том, зачем этот спринт нужен. Например: «пользователь может оплатить заказ картой и получить чек». Набор задач — гипотеза о том, как цели достичь; если на третий день выяснилось, что цели можно достичь иначе, состав задач меняется, а цель — нет. Команда обязуется перед целью, а не перед списком.

Роли и события

Три роли: Product Owner (что делаем и в каком порядке), Scrum-мастер (следит, чтобы процесс работал, и убирает препятствия), команда разработки (как делаем). Четыре события: планирование, ежедневная синхронизация, обзор спринта с демо, ретроспектива. Про каждую роль и каждое событие будут отдельные уроки — сейчас важно, что всё это привязано к такту спринта.

ДОСКА SCRUM (сбрасывается каждый спринт)
Цель спринта: пользователь может оплатить заказ картой и получить чек

Sprint Backlog     | In Progress (2)   | Review        | Done
-------------------+-------------------+---------------+------------------
Чек в PDF          | Форма оплаты      | Вебхук банка  | Валидация карты
Ошибки оплаты      | Логи транзакций   |               | Схема таблицы
Повтор платежа     |                   |               | payments

Осталось 4 дня. Не влезло — уедет в следующий спринт.

Kanban: непрерывный поток

В Kanban нет спринтов, нет ролей и нет обязательных встреч. Есть четыре практики, и они звучат скучно ровно до того момента, как вы их применяете.

1. Визуализируй процесс

Колонки доски — это реальные стадии вашей работы, а не абстрактные «To Do / Doing / Done». Если у вас есть аналитика, ревью и тестирование — на доске должны быть аналитика, ревью и тестирование. Скрытая стадия = скрытая очередь.

2. Ограничивай незавершённое (WIP-лимит)

Главная механика. Над колонкой пишется число — сколько задач максимум может в ней находиться. Достигли лимита — новое брать нельзя, идите помогать закрывать то, что уже начато. Это контринтуитивно (кажется, что люди простаивают), но именно это делает Kanban Kanban'ом: он лечит любимую болезнь команд — двадцать начатых задач и ноль доведённых до конца.

3. Управляй потоком и измеряй его

Метрики Kanban — про время, а не про объём: lead time (сколько задача живёт от запроса до поставки), cycle time (сколько она в работе), throughput (сколько задач закрывается в неделю). Никаких story points и velocity здесь не нужно.

4. Сделай политики явными

Что значит «готово к тестированию»? Кто имеет право двигать карточку? Что делать с срочным инцидентом? Если правила не написаны — они у каждого свои.

ДОСКА KANBAN (живёт непрерывно, лимиты в скобках)

Очередь (5) | Анализ (2) | Разработка (3) | Ревью (2) | Тест (2) | Готово
------------+------------+----------------+-----------+----------+--------
Поиск       | Экспорт    | Оплата картой  | Логи !!!  | Чек PDF  | ...
Фильтры     |            | Возвраты       |           |          |
Экспорт CSV |            | Отчёт по дням  |           |          |

!!! Ревью упёрлось в лимит → разработку брать НЕЛЬЗЯ.
    Свободные разработчики идут ревьюить. Это и есть узкое место.

Обратите внимание на последнюю строку: доска сама показала, где затык. В Scrum вы бы узнали об этом на ретро через две недели.

Как это работает: закон Литтла

За WIP-лимитами стоит не вера, а формула из теории очередей. Закон Литтла в применении к доске: среднее время прохождения задачи = количество задач в работе, делённое на пропускную способность.

const throughput = 3; // команда стабильно закрывает 3 задачи в неделю

[12, 8, 6, 4].forEach(wip => {
  const cycleTime = wip / throughput;
  console.log(`В работе ${wip} задач → средний срок задачи ${cycleTime.toFixed(1)} нед.`);
});

Результат:

В работе 12 задач → средний срок задачи 4.0 нед.
В работе 8 задач → средний срок задачи 2.7 нед.
В работе 6 задач → средний срок задачи 2.0 нед.
В работе 4 задач → средний срок задачи 1.3 нед.

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

Таблица сравнения

Когда что выбирать

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

Scrumban: гибрид, на котором живёт полстраны

В реальности большинство команд работают между этими полюсами, и это нормально. Типичный Scrumban:

• Оставляем спринт как каденс встреч: раз в две недели — обзор и ретро, потому что цикл обратной связи нужен.
• Убираем набор пачкой: задачи вытягиваются по одной, когда освобождается слот в разработке.
• Вводим лимиты WIP по колонкам — главное, что стоит забрать из Kanban.
• Планирование запускается по триггеру: когда в очереди осталось меньше N задач, собираемся и пополняем её, а не ждём календаря.
• Заводим класс срочности для инцидентов: отдельная дорожка на доске, свой лимит (например, не больше одной срочной одновременно), право прервать плановую работу.
• Velocity нередко заменяют на throughput и cycle time — они честнее и не требуют оценок.

Опасность у гибридов одна: под словом «Scrumban» часто прячут «мы отменили ретро, а планирование делаем как получится». Гибрид законен, когда вы сознательно убрали элемент и знаете, чем компенсировали. Незаконен, когда элемент просто отвалился.

Частые ошибки

• Считать Kanban «Scrum без правил». Ровно наоборот: лимит WIP — самое жёсткое правило, какое можно ввести в команде. Доска без лимитов — это не Kanban, это просто доска.
• Спринт как дедлайн-марш. Если недоделанное каждый спринт переносится, а качество режется — вы получили водопад с двухнедельным тактом.
• Понимать обязательство как «сделаем все задачи». Обязательство — цель спринта. Иначе команда начнёт занижать объём и перестанет брать риск.
• Менять содержимое спринта каждый день, оставаясь «в Scrum». Тогда спринт не даёт ничего, кроме встреч. Честнее перейти на Kanban.
• Сравнивать velocity разных команд. Story points — внутренняя валюта одной команды; курса обмена не существует.
• Брать новую задачу, «чтобы не простаивать». Закон Литтла выше объясняет, чем вы за это платите.

Итоги

• Scrum — работа пачками с фиксированным тактом; обязательство — цель спринта, а не список задач.
• Kanban — непрерывный поток: визуализация, лимиты WIP, метрики времени, явные политики. Ролей и событий не предписывает.
• WIP-лимит — не бюрократия, а прямое следствие закона Литтла: меньше начатого одновременно = быстрее доходит каждая задача.
• Scrum лучше там, где работа планируемая; Kanban — где поток входящий и приоритеты меняются быстрее спринта.
• Scrumban (каденс встреч от Scrum + вытягивание и лимиты от Kanban) — рабочий выбор, если вы осознанно решаете, что убрали и чем это компенсировали.