Scrumban и гибридные процессы: как совмещают Scrum и Kanban

Почти в каждой второй компании на вопрос «какой у вас процесс» отвечают: «ну, у нас Scrumban». Если копнуть, за этим словом почти всегда стоит одно из двух. Либо «мы делали Scrum, но перестали ходить на ретро, оценивать и держать спринт-гол, зато оставили двухнедельный ритуал под названием планирование». Либо «у нас Kanban, но начальство просит даты, поэтому мы всё равно называем куски работы спринтами». И то и другое — не гибрид, а распад процесса, которому дали благозвучное имя.

Настоящий гибрид выглядит иначе: это осознанный набор решений по каждой оси процесса, где каждое решение можно защитить — «мы держим фиксированное ревью раз в две недели, потому что стейкхолдеры физически не собираются чаще; мы отказались от спринт-бэклога, потому что 40% работы приходит как инциденты; мы поставили WIP-лимит 3 на код-ревью, потому что там очередь». Разница между гибридом и распадом — в том, можете ли вы для каждого отклонения от канона назвать причину, метрику и условие отката.

Эта статья — про механику. Мы разберём происхождение Scrumban (оно не такое, как принято думать), разложим процесс на независимые оси, посчитаем математику пополнения очереди и стоимости каденции, пройдём по каталогу реальных гибридов и честно скажем, где каждый превращается в карго-культ. Предполагается, что вы уже прочитали Agile и Scrum и Kanban и управление потоком — здесь мы не пересказываем ни роли Scrum, ни закон Литтла, а строим поверх них.

Часть 1. Откуда на самом деле взялся Scrumban

Термин ввёл Кори Ладас в серии эссе 2008 года, позже собранных в книгу «Scrumban: Essays on Kanban Systems for Lean Software Development». И вот первое, что регулярно теряют при пересказе: Ладас не проектировал «золотую середину». Он проектировал маршрут перехода. Его тезис: Scrum — хорошая стартовая площадка для команды, которая никогда не работала итеративно, потому что он даёт жёсткие рамки и заставляет проявить проблемы. Но как только команда научилась работать в такте, сам такт становится ограничением: он навязывает пакетирование (batching) там, где его можно убрать. Scrumban — это Scrum, из которого по одному вынимают итерационные костыли, заменяя их вытягивающими механизмами: сначала сплошная доска вместо спринт-бэклога, потом WIP-лимиты вместо капасити, потом планирование по требованию вместо планирования по календарю.

То есть в оригинале Scrumban — не пункт назначения, а вектор. То, что индустрия зафиксировала его как стабильное состояние, — не преступление (многие команды в этом состоянии живут годами и хорошо), но важно понимать: у Ладаса нет «гайда по Scrumban», нет ролей, нет обязательных событий. Есть набор приёмов: order point (точка заказа), bucket size planning (планирование по «вёдрам» горизонтов), ready queue, классы обслуживания.

Параллельно в 2009 году Хенрик Книберг и Маттиас Скарин написали бесплатную книгу «Kanban and Scrum — making the best of both», где впервые аккуратно разложили: Scrum предписывает больше, Kanban предписывает меньше, и это не иерархия «лучше/хуже», а разный объём заданных ограничений. Их формулировка — «Kanban and Scrum are tools; the tool doesn’t do the job, you do» — до сих пор лучшая защита от бренд-мышления.

Третья линия — институциональная. В 2018 году Scrum.org совместно с Дэниелом Ваканти и Стивом Портером выпустили «The Kanban Guide for Scrum Teams»: официальное признание, что практики потока не противоречат Scrum Guide, а дополняют его. А Scrum Guide 2020 убрал из определения слова про обязательный формат Sprint Backlog как списка задач и вообще стал заметно тоньше — то есть сам канон подвинулся навстречу.

Часть 2. Процесс — это набор ручек, а не бренд

Единственный способ обсуждать гибриды без религиозных войн — перестать говорить «Scrum или Kanban» и начать говорить об осях. Практически любой процесс разработки описывается положением шести-семи независимых регуляторов.

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

Согласованные комбинации:

• Обязательство на период + ограничитель = капасити + объём заморожен. Это канонический Scrum. Он работает, потому что обязательство защищено заморозкой: команда может обещать, потому что ей не подкидывают.
• Пополнение по требованию + WIP-лимит + классы обслуживания. Это канонический Kanban: обещаний по объёму нет, но есть обещания по времени прохождения (SLE), защищённые лимитом.

Противоречивые комбинации, которые встречаются чаще всего:

• Обязательство на спринт без заморозки объёма. Команда даёт спринт-гол, а внутрь спринта каждый день влетают срочные задачи. Обязательство превращается в ритуальную ложь; velocity скачет; ретро обсуждает «почему опять не успели». Это не гибрид, это Scrum со снятым предохранителем.
• WIP-лимиты без права остановиться. Лимит поставлен, но когда он упирается, менеджер разрешает «просто начать ещё одну». Лимит — это не число на доске, это обязательство не начинать. Без него доска рисует красивую картинку системы, которой нет.
• Отказ от оценок без метрик потока. Убрали story points, но не считают throughput и cycle time. Теперь у команды нет вообще никакого языка для срока. Через квартал возвращаются к оценкам, но уже с испорченной репутацией.

Практический вывод: гибрид проектируется не как «возьмём отсюда и отсюда», а как ответ на вопрос «что удерживает систему от расползания». В Scrum это заморозка спринта, в Kanban — WIP-лимит. Если вы вынимаете одно, вы обязаны поставить другое. Гибрид без единого ограничителя — это просто список задач.

Часть 3. Ядро Scrumban: пополнение по требованию

Самая содержательная механика, которую Ладас принёс из бережливого производства, — order point (точка заказа). Идея: не планировать по календарю, а планировать, когда очередь готовой к работе постановки опустилась до порога.

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

Как выбрать $R$? Это классическая задача точки перезаказа. Пусть $\bar{D}$ — среднее потребление задач в день (это и есть ваш throughput), $L$ — время подготовки порции (lead time планирования: от «объявили сессию» до «постановка готова»), $\sigma_D$ — стандартное отклонение дневного потребления. Тогда

$$R = \bar{D} \cdot L + z \cdot \sigma_D \cdot \sqrt{L}$$

Второе слагаемое — страховой буфер: $z$ выбирается по желаемой надёжности ($z \approx 1{,}65$ для 95%, $z \approx 2{,}33$ для 99%). Пример: команда закрывает в среднем 1,2 задачи в день при $\sigma_D = 0{,}6$, подготовка порции занимает 3 дня. Тогда $R = 1{,}2 \cdot 3 + 1{,}65 \cdot 0{,}6 \cdot \sqrt{3} \approx 3{,}6 + 1{,}7 \approx 5{,}3$, то есть триггер ставим на 6 задач в Ready.

Второй параметр — сколько добавлять за раз (размер порции $Q$). Здесь работает та же экономика размера партии, что и в производстве: слишком мелкая порция — слишком часто отвлекаем всех на планирование, слишком крупная — постановки устаревают, пока до них дойдут, и мы фиксируем решения раньше, чем нужно. Об этом — следующая часть.

Жизненный цикл элемента в Scrumban:

Обратите внимание на два перехода, которых нет в наивных схемах. Blocked → Ready (а не Blocked → In Progress): если задача заблокирована надолго, она обязана освободить WIP-слот, иначе лимит становится фикцией. И Ready → Backlog: если постановки протухают, не дождавшись старта, — это прямое измерение того, что порция пополнения слишком велика.

Смоделируем политику пополнения численно, чтобы не выбирать $R$ и $Q$ на глаз.

import random
import statistics

def simulate(order_point: int, batch: int, lead_days: int,
             mean_throughput: float, cv: float,
             days: int = 250, seed: int = 7) -> dict:
    """Симуляция очереди Ready с пополнением по точке заказа.

    order_point  — порог R, при котором запускается сессия пополнения
    batch        — размер порции Q (сколько постановок готовим за сессию)
    lead_days    — сколько дней идёт подготовка порции
    mean_throughput — средняя пропускная способность команды, задач/день
    cv           — коэффициент вариации потребления (разброс)

    Сложность: O(days) по времени, O(1) по памяти.
    """
    rnd = random.Random(seed)
    ready = batch                 # стартуем с полной порции
    pending: list[int] = []       # дни, когда придут заказанные порции
    starved_days = 0              # дней простоя: брать было нечего
    sessions = 0                  # сколько раз собирались на планирование
    ready_levels = []

    for day in range(days):
        # приходят ранее заказанные порции
        arrived = [d for d in pending if d == day]
        ready += batch * len(arrived)
        pending = [d for d in pending if d > day]

        # спрос дня: гамма-подобный разброс вокруг среднего
        demand = max(0, round(rnd.gauss(mean_throughput, mean_throughput * cv)))
        taken = min(demand, ready)
        if taken < demand:
            starved_days += 1     # команда упёрлась в пустую очередь
        ready -= taken

        # триггер: уровень ниже точки заказа и заказ ещё не в пути
        if ready <= order_point and not pending:
            pending.append(day + lead_days)
            sessions += 1

        ready_levels.append(ready)

    return {
        "простоев, дней": starved_days,
        "доля простоев": round(starved_days / days, 3),
        "сессий планирования": sessions,
        "средний интервал между сессиями, дней": round(days / max(sessions, 1), 1),
        "средний уровень Ready": round(statistics.mean(ready_levels), 1),
    }

# Сравниваем три политики при одинаковой команде
for R, Q in [(3, 6), (6, 10), (12, 20)]:
    print(f"R={R:2d} Q={Q:2d}", simulate(R, Q, lead_days=3,
                                         mean_throughput=1.2, cv=0.5))

Типичный вывод показывает разменную кривую: маленькие $R$ и $Q$ дают частые сессии (дорого по времени людей) и заметный процент простоя; большие — почти нулевой простой, но средний уровень Ready под 15 задач, то есть полтора месяца замороженных решений. Оптимум обычно там, где доля простоев уходит ниже 2–3%, а сессии случаются раз в неделю-полторы. Именно поэтому у большинства «Scrumban-команд» планирование де-факто оседает на недельном ритме — но теперь это не догма, а результат расчёта, который вы можете пересчитать, когда throughput изменится.

Часть 4. Каденции можно расцепить — и это главный трюк гибридов

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

Почему это работает: у каждого события своя транзакционная стоимость и своя стоимость удержания. Планирование дёшево провести (полтора часа, 3–4 человека), но дорого откладывать (люди простаивают). Демо для двадцати стейкхолдеров дорого провести (двадцать человеко-часов плюс подготовка), но не так дорого откладывать. Релиз при нормальной CI/CD почти бесплатен в проведении — значит, его частота должна быть максимальной.

Формально: пусть $C_{tr}$ — стоимость одного проведения события, $C_h$ — стоимость удержания результата за единицу времени (в тех же деньгах или человеко-часах). При периоде $T$ суммарная стоимость на единицу времени

$$C(T) = \frac{C_{tr}}{T} + \frac{C_h \cdot T}{2}$$

Минимум достигается при

$$T^{\ast} = \sqrt{\frac{2 \cdot C_{tr}}{C_h}}$$

Это ровно формула Уилсона (EOQ) из теории запасов, применённая к событию процесса; в контексте разработки её популяризировал Дональд Рейнертсен. Посчитаем на пальцах для демо: подготовка и проведение — 24 человеко-часа ($C_{tr} = 24$). Стоимость удержания: если фича готова, но её не показали, обратная связь запаздывает; оцените в 2 человеко-часа переделок за неделю задержки ($C_h = 2$ в неделю). Тогда $T^{\ast} = \sqrt{48/2} \approx 4{,}9$ недели — то есть демо раз в месяц, а не раз в две недели. А для релиза: $C_{tr} = 0{,}5$ часа (автоматизировано), $C_h = 20$ часов в неделю (недовыпущенная ценность плюс риск конфликтов) → $T^{\ast} = \sqrt{1/20} \approx 0{,}22$ недели, то есть чаще чем раз в день. Числа условны, но структура вывода реальна: частота события должна падать при росте стоимости проведения и расти при росте стоимости задержки. Двухнедельный спринт делает всё это одинаковым — и почти всегда ошибается минимум в двух из четырёх случаев.

Важная оговорка: расцепление имеет свою цену — когнитивную. Когда все события на одной границе, никто не думает, когда что. Когда их четыре с разными периодами, нужен календарь, автоматизация и дисциплина. Для команды из 4 человек это дёшево, для отдела из 60 — уже нет, там синхронные границы работают как дешёвый механизм координации (подробнее — в Масштабирование фреймворков).

Часть 5. Каталог реальных гибридов

Разберём главные.

5.1. Flow-based Scrum: Scrum, который научился считать

Самый недооценённый гибрид, потому что он выглядит скучно — вы ничего не отменяете. Вы оставляете все события и роли, но добавляете четыре вещи из Kanban Guide for Scrum Teams: явное определение потока (какие столбцы и что значит «начал/закончил»), WIP-лимиты, активное управление элементами в работе и измерение метрик потока. Дальше эти метрики попадают в события: на дейли обсуждают не «что я делал вчера», а aging WIP — что стоит дольше 85-го процентиля и почему; на ретро смотрят на распределение cycle time; на планировании используют throughput вместо velocity.

Эффект почти всегда один и тот же и очень предсказуемый: пропадает «хоккейная клюшка» — паттерн, когда 80% задач закрываются в последние два дня спринта. Клюшка — прямое следствие того, что спринт разрешает начинать всё сразу. WIP-лимит это запрещает.

Как проверить, есть ли у вас клюшка, — простым SQL по выгрузке трекера:

-- Распределение закрытий по дням спринта: ищем пакетирование в конце
WITH items AS (
    SELECT
        i.id,
        s.name                                            AS sprint,
        s.start_date,
        s.end_date,
        i.done_at::date                                   AS done_day,
        (i.done_at::date - s.start_date)                  AS day_index,
        (s.end_date - s.start_date)                       AS sprint_len
    FROM issues i
    JOIN sprints s ON i.sprint_id = s.id
    WHERE i.done_at IS NOT NULL
      AND s.end_date >= current_date - INTERVAL '180 days'
)
SELECT
    -- нормируем позицию внутри спринта: 0.0 — начало, 1.0 — конец
    width_bucket(day_index::numeric / NULLIF(sprint_len, 0), 0, 1, 5) AS fifth,
    count(*)                                              AS closed,
    round(100.0 * count(*) / sum(count(*)) OVER (), 1)    AS pct
FROM items
GROUP BY 1
ORDER BY 1;

Если в последней пятой части спринта закрывается больше 40% задач — у вас не итеративная разработка, а мини-водопады по две недели. Это самый частый диагноз, ради которого команды и переходят на гибрид.

5.2. Два потока: фичи спринтами, поддержка потоком

Реальная боль команд, владеющих продом: спринт планируется на 100% капасити, а потом приходит инцидент, и план рассыпается. Классическое решение — резервировать процент капасити под непредвиденное — работает плохо, потому что резерв всегда «съедается» и потому что он не отвечает на вопрос «что делать, когда инцидентов вдвое больше нормы».

Правильнее развести это на два независимых механизма: фичевый поток с обязательством и потоком инцидентов с классами обслуживания и собственным WIP-лимитом. Ключевая деталь: инцидентный поток должен иметь явный лимит одновременных дежурных, а не «все бросаются». Один человек на дежурстве, второй — резерв, остальные защищены.

Пунктирные стрелки — это эскалационная политика, и она важнее самой доски. Она заранее отвечает на вопрос «что мы делаем, когда инцидентов больше нормы», и делает остановку фич не поражением менеджера, а срабатыванием заранее согласованного правила. Подробности по классам обслуживания и SLE — в Kanban и управление потоком, по управлению инцидентными рисками — в Управление рисками.

5.3. Dual-track: discovery и delivery в одной команде

Гибрид другой природы: он смешивает не Scrum с Kanban, а два разных типа работы. Delivery-трек — предсказуемый поток реализации. Discovery-трек — исследование: интервью, прототипы, эксперименты. У них принципиально разные метрики (в delivery — cycle time и throughput, в discovery — количество проверенных гипотез и скорость обучения) и разные критерии «готово».

Практическая реализация: один бэклог, две доски, общий WIP-бюджет людей. Discovery-трек имеет свой WIP-лимит (обычно 2–3 гипотезы одновременно), и выход discovery — вход в Ready-очередь delivery. Это связывает механику Scrumban с продуктовым процессом: точка заказа Ready-очереди становится и триггером для discovery тоже. Если тема продуктовых гипотез вам ближе, см. трек Product Management.

Где ломается: когда discovery отдают отдельной группе «продуктовых аналитиков», не сидящей в команде. Тогда между треками появляется очередь передачи, и получается тот самый водопад — только теперь с research-фазой.

5.4. Shape Up: фиксированный цикл без спринтов

Shape Up от Basecamp — интересный гибрид, потому что он берёт из Scrum ровно одну вещь (фиксированный таймбокс, но 6 недель) и радикально меняет всё остальное: вместо оценки — appetite («сколько мы готовы на это потратить»), вместо бэклога задач — «shaped pitches», вместо трекера — hill chart, вместо переноса незавершённого — правило «не успели за цикл → работа умирает, при желании переподаём». Плюс двухнедельный cooldown между циклами, когда команда сама решает, чем заниматься.

Что здесь честно и полезно: инверсия оценки (фиксируем время, торгуем объёмом) — это тот же приём, что и в Оценке и планировании, только доведённый до правила. Правило «не успели — умерло» жестоко, но убивает главный источник накопления незавершёнки.

Где ломается: Shape Up спроектирован под контекст Basecamp — зрелый продукт, малая автономная команда, отсутствие жёстких внешних обязательств, почти нет унаследованного саппорта. В команде с SLA и дежурствами шестинедельный непрерываемый цикл нереализуем: он будет прерван на первой же неделе. Копировать Shape Up целиком в аутсорс или в энтерпрайз — классический карго-культ.

5.5. Water-Scrum-Fall: гибрид, которого никто не проектировал

Термин Дэйва Уэста (Forrester, 2011): аналитика и требования делаются водопадом впереди, разработка «итеративно» в середине, релиз — большим пакетом раз в квартал по расписанию релизного комитета. Разработка при этом искренне считает, что работает по Agile.

Диагностика простая: посчитайте flow efficiency end-to-end — от момента, когда бизнес попросил, до момента, когда пользователь получил. Если внутри спринта эффективность 40%, а end-to-end 4% — весь ваш процесс это узкие места на входе и на выходе, а спринт оптимизирует середину, которая ничего не решает. Это конкретный случай общего закона: не оптимизируйте не-ограничение. Как обнаруживать и что с этим делать — в DORA и инженерных метриках.

Часть 6. Как выбирать: дерево решений

Гибрид не выбирают по вкусу — его выводят из свойств спроса и связности работы.

Та же картина в координатах «предсказуемость спроса × потребность во внешней синхронизации»:

Диагонали здесь важнее квадрантов: чем сильнее спрос непредсказуем, тем меньше смысла в обязательстве на период; чем сильнее внешняя связность, тем нужнее общий такт, даже если внутри команды он экономически неоптимален. Scrumban живёт ровно в этом противоречии: такт снаружи, поток внутри.

Часть 7. Как это выглядит в конфигурации

Гибрид, не зафиксированный в явных политиках, деградирует за два-три месяца — люди забывают, новые не знают. Держите описание процесса в репозитории рядом с кодом, а не в Confluence на сорок страниц.

# process/board-policy.yml — политики доски, ревьюится как код
board:
  name: "Платформа: основной поток"
  cadence:
    replenishment: { trigger: "order_point", order_point: 6, batch: 10 }
    review:        { trigger: "calendar", every: "2 weeks", day: "thursday" }
    retro:         { trigger: "calendar", every: "4 weeks" }
    release:       { trigger: "continuous" }          # деплой по мержу

  columns:
    - name: Ready
      wip: null                                       # буфер, лимитируется order_point
      entry_criteria:
        - "критерии приёмки записаны и приняты командой"
        - "внешние зависимости подтверждены владельцами"
        - "оценка не требуется; понятен размер: S / M / L"
    - name: In Progress
      wip: 3                                          # 4 разработчика, лимит < числа людей
      policy: "начинаем только если освободился слот; иначе помогаем ближайшему к выходу"
    - name: Review
      wip: 2
      policy: "ревью приоритетнее нового кода; PR старше 24 ч эскалируется в чат"
    - name: Done
      definition: "в проде, дашборд подтверждает работу фичи"

  classes_of_service:
    - { name: expedite,   wip: 1, rule: "инцидент P1; вытесняет всё, WIP-лимиты игнорируются" }
    - { name: fixed_date, wip: 2, rule: "жёсткая дата снаружи; стартуем по обратному отсчёту" }
    - { name: standard,   wip: 3, rule: "FIFO из Ready" }

  service_level_expectation:
    standard: { percentile: 85, days: 9 }             # 85% задач закрываются за 9 дней
    fixed_date: { percentile: 95, days: 14 }

  escalation:
    - when: "expedite занят и пришёл второй P1"
      then: "поднимаем резервного дежурного, ставим на паузу одну standard-задачу"
    - when: "два дня подряд Ready < 3"
      then: "внеочередная сессия пополнения в тот же день"
    - when: "aging WIP превысил 85-й процентиль"
      then: "обсуждаем на дейли первым пунктом, ищем разблокировку, не начинаем новое"

Часть этих политик можно и нужно автоматизировать. Пример скрипта, который каждое утро проверяет инварианты доски по API трекера и пишет в канал команды:

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone

@dataclass
class Item:
    key: str
    column: str
    entered_column_at: datetime
    started_at: datetime | None
    cls: str = "standard"

WIP_LIMITS = {"In Progress": 3, "Review": 2}
SLE_DAYS = {"standard": 9, "fixed_date": 14}   # 85-й процентиль

def check_board(items: list[Item], now: datetime) -> list[str]:
    """Проверка инвариантов гибридной доски. O(n) по времени, O(k) по памяти."""
    alerts: list[str] = []

    # 1. Нарушение WIP-лимитов
    counts: dict[str, int] = {}
    for it in items:
        counts[it.column] = counts.get(it.column, 0) + 1
    for column, limit in WIP_LIMITS.items():
        actual = counts.get(column, 0)
        if actual > limit:
            alerts.append(f"WIP превышен: {column} = {actual} при лимите {limit}. "
                          f"Не начинать новое, разгружать столбец.")

    # 2. Голодание Ready-очереди — пора запускать пополнение
    ready = counts.get("Ready", 0)
    if ready <= 6:
        alerts.append(f"Ready = {ready} ≤ точки заказа. Назначить сессию пополнения.")

    # 3. Aging WIP: элементы, перешагнувшие свой SLE
    for it in items:
        if it.started_at is None or it.column in ("Ready", "Done"):
            continue
        age_days = (now - it.started_at).days
        limit = SLE_DAYS.get(it.cls, 9)
        if age_days > limit:
            alerts.append(f"{it.key}: в работе {age_days} дн. при SLE {limit} дн. "
                          f"({it.cls}) — обсудить первым пунктом на дейли.")

    # 4. Застой в столбце — сигнал скрытой блокировки
    for it in items:
        stuck = (now - it.entered_column_at).days
        if it.column == "Review" and stuck >= 2:
            alerts.append(f"{it.key}: висит в Review {stuck} дн. Ревью приоритетнее нового кода.")

    return alerts

if __name__ == "__main__":
    now = datetime.now(timezone.utc)
    demo = [
        Item("PLT-341", "In Progress", now - timedelta(days=1), now - timedelta(days=12)),
        Item("PLT-355", "Review",      now - timedelta(days=3), now - timedelta(days=5)),
        Item("PLT-360", "In Progress", now - timedelta(days=2), now - timedelta(days=2)),
        Item("PLT-361", "In Progress", now - timedelta(days=1), now - timedelta(days=1)),
        Item("PLT-362", "In Progress", now,                     now),
    ]
    for line in check_board(demo, now):
        print("•", line)

Ключевой принцип автоматизации гибрида: бот сообщает о нарушении политики, а не считает людей. Сообщение «PLT-341 в работе 12 дней при SLE 9» — про систему; сообщение «у Иванова три задачи в работе» — про человека, и оно запускает защитное поведение (задачи перестают заводить, работу дробят на невидимые куски).

Часть 8. Сколько это стоит

Гибриды продают как «убираем лишние встречи». Посчитаем честно, на команде из 8 человек со средней полной стоимостью часа 4000 ₽ (число условное, замените своим).

Выглядит как чистая победа — но это только левая часть уравнения. Правая:

• Стоимость перехода. Реалистично 1,5–2 месяца сниженной производительности (10–20%): люди переучиваются, доска перестраивается, метрики набираются. Для этой команды это 150–250 человеко-часов.
• Стоимость нестандартности. Новый разработчик, знающий Scrum, встраивается за неделю; в самописный процесс — за три-четыре. При найме 4 человек в год это ещё около 100 часов.
• Стоимость поддержки процесса. Кто-то должен следить за политиками, лимитами, метриками. Обычно 2–4 часа в неделю тимлида — 100–200 часов в год.
• Стоимость потери обязательства. Если бизнес потерял понятный ему ответ «что будет к 30-му» и вы не заменили его вероятностным прогнозом, вы платите доверием — это самая дорогая и самая невидимая статья.

Вывод: экономика гибрида положительна почти всегда для команды, у которой уже есть проблема (клюшка, очереди, инциденты). И почти всегда отрицательна для команды, у которой Scrum просто «немного скучный». Гибрид — лекарство, а не витамин. Менять процесс без названного симптома и метрики, по которой вы поймёте, что вылечили, — чистые убытки.

Часть 9. Типичные ошибки

1. Scrumban как эвфемизм для «мы забили». Убрали ретро, планирование стало нерегулярным, метрик нет. Проверка: назовите три политики вашего процесса, которые кто-то может нарушить. Если нарушить нечего — процесса нет.
2. Оставленный спринт-гол при вытягивании. Если работа приходит непрерывно, а обещание даётся на две недели, вы получаете худшее из двух миров: гибкость входа и жёсткость обещания. Либо защищайте спринт, либо не обещайте объём.
3. WIP-лимит равен числу людей. Тогда он ничего не ограничивает: каждый и так делает по одной задаче, а очереди между этапами остаются. Рабочее правило: лимит на этап строго меньше числа людей, способных на нём работать — именно это заставляет помогать, а не начинать новое.
4. Точка заказа без замера lead time планирования. Порог поставили «на глаз» в 3 задачи, а подготовка порции занимает неделю — команда регулярно простаивает. Считайте $R$ по формуле из части 3 и пересчитывайте раз в квартал.
5. Классы обслуживания без лимита на expedite. Если «срочным» можно назначить что угодно и сколько угодно, все задачи станут срочными за месяц. Лимит expedite = 1 и правило «одновременно не больше одной» — обязательны.
6. Смена процесса вместо решения кадровой проблемы. Ни Scrum, ни Kanban, ни их смесь не чинят отсутствие инженерных практик, токсичное руководство или отсутствие владельца продукта. Часто «переход на Scrumban» — способ не обсуждать настоящую причину. См. Команда и коммуникация.
7. Копирование чужого гибрида целиком. Shape Up из Basecamp, «Spotify model», внутренний процесс знакомого стартапа — это решения, выведенные из чужих ограничений. Копировать нужно метод вывода, а не результат.
8. Метрики гибрида как KPI команд. Как только throughput или cycle time попадают в оценку людей, они начинают измерять не поток, а изобретательность в дроблении задач. Метрики потока — диагностические, разбор в DORA и инженерные метрики.
9. Отсутствие условия отката. Любое изменение процесса должно иметь формулировку «если через 8 недель метрика X не улучшилась на Y, мы возвращаемся». Без этого эксперимент превращается в новую догму.

Часть 10. Как это делают в проде: план перехода на 90 дней

Реалистичная последовательность для команды 6–10 человек, которая живёт в Scrum и упёрлась в клюшку и инциденты.

Что важно в этой последовательности и часто делают наоборот:

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

WIP-лимиты раньше, чем отмена спринтов. Это контринтуитивно: кажется, что сначала надо «уйти от Scrum». На деле WIP-лимиты дают 70% эффекта и не требуют менять организационные договорённости — их можно поставить внутри спринта в пятницу и увидеть эффект через две недели. Отмена спринтов же затрагивает всех, кто с вами синхронизируется, и стоит переговоров.

Ready-очередь появляется последней. Пока команда не научилась не начинать новое, отдельный буфер готовой работы просто станет вторым бэклогом.

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

Наконец, зафиксируйте изменение как эксперимент, а не как реформу. Формулировка, которая работает на практике:

Гипотеза: WIP-лимит 3 в разработке и 2 в ревью сократит 85-й процентиль cycle time с 14 до 9 дней за 8 недель, не снизив месячный throughput ниже 22 задач. Замер — еженедельно. Если через 8 недель процентиль выше 12 дней или throughput ниже 18, откатываемся и разбираем причину на ретро.

Такая формулировка защищает вас с двух сторон: от «давайте попробуем ещё три месяца» и от «эксперимент не сработал за неделю, возвращаем как было».

Чек-лист: у вас гибрид или распад процесса?

• Для каждого отступления от канона (Scrum или Kanban) названа причина и метрика.
• Есть хотя бы один действующий ограничитель работы: заморозка объёма или WIP-лимит. Не ноль.
• Политики доски записаны в репозитории и обновлялись за последние 3 месяца.
• Есть язык для срока: либо спринт-обязательство, либо SLE в процентилях. Не «когда будет — тогда будет».
• Каденции обзора и релиза выбраны отдельно, каждая с обоснованием.
• Срочная работа имеет явный класс, лимит и эскалационную политику.
• Ретроспектива живёт и приводит к изменению политик, а не к списку жалоб.
• Для последнего изменения процесса сформулированы гипотеза, метрика и условие отката.
• Новый человек понимает процесс за один разговор и один файл.

Восемь-девять галочек — у вас работающий гибрид. Меньше пяти — у вас брендированный хаос, и первое, что нужно починить, это не процесс, а отсутствие ограничителя.

Мини-итог

• Scrumban в оригинале Ладаса — маршрут перехода от такта к потоку, а не стабильная «середина»; но как стабильное состояние он тоже работает — если сделан осознанно.
• Процесс раскладывается на независимые оси: пополнение, обязательство, ограничитель, прогноз, роли, срочная работа, обратная связь. Гибрид — это конкретный набор положений, который можно назвать и защитить.
• Между осями есть отношения совместимости. Главное: если убираете заморозку спринта, обязаны поставить WIP-лимит. Система без единого ограничителя — не процесс.
• Пополнение по точке заказа $R = \bar{D} \cdot L + z \cdot \sigma_D \cdot \sqrt{L}$ заменяет календарное планирование и убирает пакетирование постановок.
• Каденции событий стоит расцепить: оптимальный период $T^{\ast} = \sqrt{2 C_{tr} / C_h}$ у планирования, демо, ретро и релиза принципиально разный.
• Самый дешёвый и недооценённый гибрид — flow-based Scrum: ничего не отменяем, добавляем WIP-лимиты и метрики потока. Он убирает «хоккейную клюшку» без организационных переговоров.
• Гибрид — лекарство, а не витамин: меняйте процесс только под названный симптом, с метрикой и условием отката.

Источники

• Corey Ladas. «Scrumban: Essays on Kanban Systems for Lean Software Development», Modus Cooperandi Press, 2009 — первоисточник термина, точка заказа и bucket size planning.
• Henrik Kniberg, Mattias Skarin. «Kanban and Scrum — making the best of both», InfoQ, 2009 — бесплатная книга, лучшее честное сравнение по объёму предписаний.
• Daniel Vacanti, Steve Porter, Yuval Yeret. «The Kanban Guide for Scrum Teams», Scrum.org — официальная интеграция метрик потока в Scrum.
• Ken Schwaber, Jeff Sutherland. Scrum Guide 2020 — актуальный канон, из которого видно, сколько свободы он на самом деле оставляет.
• Donald G. Reinertsen. «The Principles of Product Development Flow», Celeritas, 2009 — экономика размера партии и каденции, откуда взята формула оптимального периода.
• David J. Anderson. «Kanban: Successful Evolutionary Change for Your Technology Business», Blue Hole Press, 2010 — классы обслуживания, эволюционное изменение процесса.
• Daniel Vacanti. «Actionable Agile Metrics for Predictability» — процентили, SLE, аging WIP.
• Ryan Singer. «Shape Up», Basecamp, 2019 — доступна бесплатно; альтернативный гибрид с appetite вместо оценок.
• Dave West. «Water-Scrum-Fall Is The Reality Of Agile», Forrester, 2011 — диагноз самого распространённого непроектированного гибрида.
• Kanban Guide — минимальное определение канбан-практик на нескольких страницах, удобно как основа для собственных политик.

Что дальше

Мы разобрали, как совмещают два современных подхода. Но итеративность придумали не в 2001 году: спиральная модель, RAD и RUP предлагали инкрементальность за десятилетия до Agile — и часть их наследия до сих пор живёт в наших процессах под другими именами. Разберём, что из этого действительно работало и что стоит забрать себе: RAD, спиральная модель, RUP и итеративные подходы: наследие и что осталось.