Scrum, Kanban или Scrumban: как выбрать под свою команду
Начните не с вопроса «какая методология современнее», а с того, как приходит работа. Можно ли договориться о цели на короткий период? Насколько часто возникают срочные обращения? Где задачи ждут дольше всего? Ответы определяют, какая организация процесса поможет, а какая добавит церемоний.
По материалам «Библии CTO» канала «Точка Роста» (@t4karosta). Примеры ниже — учебные, не отчёты о результатах реальных компаний. Исходный гайд и рабочий шаблон.
Три подхода — три способа организовать работу
| Подход | На чём держится | Что проверить у себя |
|---|---|---|
| Scrum | Цель спринта, короткий цикл получения результата и обратной связи | Может ли команда держать общую цель и регулярно показывать готовое изменение? |
| Kanban | Видимый поток работы, ограничения WIP и явные правила | Видны ли очереди и может ли команда ограничивать новую работу? |
| Scrumban | Сочетание итерационного ритма и управления потоком | Описано ли, какие правила действуют для плановой работы и срочных запросов? |
Scrum — не просто набор встреч, а Kanban — не просто колонки со стикерами. Название доски ничего не меняет без договорённостей о входе задач, качестве завершения и решениях при перегрузке. Scrumban тоже требует правил: «берём понемногу отовсюду» недостаточно.
Какую проблему закрывает каждый ритуал
| Проблема | Полезная практика | Проверка результата |
|---|---|---|
| Команда тянет в разные стороны | Общая цель и планирование | Участники одинаково объясняют ожидаемый результат |
| Задачи зависают без внимания | Ежедневное обсуждение продвижения к цели и препятствий | Блокировки получают владельца и следующее действие |
| Обратная связь приходит слишком поздно | Регулярный показ результата | Пользователь или заказчик видит рабочее изменение |
| Ошибки процесса повторяются | Ретроспектива с одним экспериментом | На следующей встрече есть данные об изменении |
| Начато больше, чем можно закончить | Лимиты WIP | Команда завершает работу прежде, чем открывает новую |
Ситуация 1: поддержка корпоративного портала
В учебном кейсе исходной доски шесть специалистов работают с исправлениями и запросами внутренних отделов. Объём непредсказуем, обращения часто срочные. Для такой ситуации на доске предложен Kanban: показать весь поток, ограничить незавершённую работу и измерять время прохождения.
Практический первый шаг — собрать все источники запросов в одном месте. Иначе «свободный» разработчик уже занят задачами из личных сообщений. Затем договориться, что действительно считается срочным и кто вправе изменить порядок. Само ограничение WIP без права отказать новой задаче работать не будет.
Ситуация 2: новый модуль и поддержка одновременно
Другая команда из учебного примера развивает SaaS-модуль и отвечает действующим клиентам. Здесь предложен Scrumban: плановая работа сохраняет ритм, поток поддержки остаётся видимым и ограниченным. Важно учитывать общую мощность команды, а не обещать её целиком двум направлениям.
Не делайте из срочной дорожки обход всех правил. У обращения должны быть критерий срочности, владелец и понятная цена: какая плановая работа сдвигается. Для критического инцидента может действовать отдельная процедура, но её тоже нужно описать.
Как проверить выбор на практике
- Зафиксируйте текущие очереди, частоту прерываний и возраст незавершённых задач.
- Выберите одно изменение: например, ограничить работу перед проверкой.
- Объясните команде правила входа, выхода и обработки исключений.
- Пройдите несколько рабочих циклов и сравните поток, качество и нагрузку.
- Измените договорённость, если она не решает исходную проблему.
Не сравнивайте продуктивность людей по числу карточек: задачи различаются по сложности и риску. Анализируйте систему работы. Для обсуждения спорных приоритетов пригодится карта интересов и причин конфликта.
Где сверить определения
Формальные элементы Scrum описаны в Scrum Guide. Исходная доска даёт прикладные примеры выбора, но не заменяет руководство по фреймворку. Если меняете его обязательные элементы, называйте свой процесс адаптацией, а не точным Scrum.
