Scrumban

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

Подход описал Кори Ладас (Corey Ladas) в эссе 2008 года, которое позже вошло в книгу. Исследования показывают, что механизм работает и за пределами одного офиса. В эмпирическом исследовании Ахмада Банияма́ли, Мухаммада Оваиса Ахмада и Йоуни Симиля (2016) Scrumban применили в двух площадках Software Factory, в Финляндии и Италии. Распределённая команда разрабатывала веб-приложение для тайм-банкинга. Вывод авторов: итеративная разработка, прозрачность работы и ограничение незавершённой работы снимают часть проблем координации, характерных для географически распределённых проектов.

Ниже разобрано, откуда взялся метод и что в нём действительно от Ладаса, а что добавили позднейшие пересказы. Отдельно описано, где подход перестаёт работать, какие ошибки встречаются при внедрении и как пройти первые недели перехода.

Scrumban — это не «Scrum без правил». Он переносит запуск планирования с календаря на состояние потока и ставит перед незавершённой работой явный лимит.

Происхождение и исследовательская база Scrumban

Линия первоисточника: Кори Ладас, 2008–2009

Термин ввёл Кори Ладас. Его эссе «Scrumban» датировано 2008 годом и вышло в издательстве Modus Cooperandi Press в Сиэтле. В перепечатке на сайте Agile Alliance автор указывает момент написания: апрель 2008 года. В 2009 году эссе вошло в книгу «Scrumban: Essays on Kanban Systems for Lean Software Development». По данным ACM Digital Library, у книги около 124 цитирований. Расхождение в датах: одни источники называют 2008 год (появление термина и эссе), другие 2009-й (выход книги). Оба верны, просто относятся к разным публикациям.

Исходная задача Ладаса — эволюционный переход команд от Scrum к канбан-системам бережливой разработки. Scrum Alliance прямо называет Scrumban в формулировке 2008 года переходным методом. В аннотации к книге сказано, что бережливые методы вроде канбана расширяют выгоды Scrum, дают механизм поиска возможностей для улучшения процесса и опираются на метрики и ежедневные управленческие техники, которые делают непрерывное улучшение достижимым на практике.

Эссе в версии Agile Alliance состоит из нескольких разделов. Их названия хорошо передают ход мысли автора:

• «Канбан — это больше, чем учётная карточка» (A Kanban is More than an Index Card). Карточка на доске нужна не для записи задачи, а как сигнал: в системе есть свободная ёмкость. Ладас разбирает пример, где простое правило даёт эффективный WIP-лимит, равный 6.

• «Хрустящий снаружи, мягкий внутри» (Crunchy on the Outside, Chewy on the Inside). Внешняя оболочка процесса может оставаться привычной, а внутри работа уже идёт потоком.

• «Scrumban второго уровня» (Level 2 Scrumban). Переход к более глубокой перестройке системы.

• «Долой страховочные колёса» (Off with the Training Wheels). Отказ от опор, которые нужны были на переходе.

Ладас также отмечает, что электронные инструменты хорошо справляются со списками (бэклоги, баги) и отчётами. Отсюда видно, что физическую или общую визуальную доску он считал центром системы, а трекер — вспомогательным средством.

Линия Kanban: производственные корни

Вторая половина названия восходит к канбану Toyota. Здесь источники снова расходятся. Atlassian пишет, что Toyota ввела визуальные карточки в 1953 году. В методичке Aptitude сказано, что канбан-подход разработан в 1940-х и вдохновлён супермаркетами, где на полках держат ровно столько товара, сколько нужно покупателям, а карточки на производственных линиях сигнализируют о потребности в деталях. Вероятно, речь о разных этапах одной истории: замысел и раннее применение против формализованной практики. Для руководителя важнее принцип: работа вытягивается по сигналу о свободной ёмкости, а не проталкивается по плану. Подробнее эта линия разобрана в материале о Канбан-методе.

Линия практиков: Аджай Редди и Боб Пейн

В 2015 году вышла книга «The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban» коуча Аджая Редди. Главная мысль книги: Kanban служит катализатором постепенных изменений в уже существующем процессе разработки и усиливает выгоды Scrum, а не заменяет его. Редди объясняет, чем Scrumban является и чем не является, и показывает применение на примерах из практики. Его цель — прагматичный результат на уровне команды и организации.

Боб Пейн (LitheSpeed) в презентации 2022 года называет Scrumban «мощной химерой» и сводит его к нескольким блокам. Роли: обязательных нет, используются текущие, при желании берутся роли Scrum, дальше всё развивается по необходимости. Команда: небольшая, кросс-функциональная, самоорганизующаяся, с общей ответственностью. Ритм: итерация с таймбоксом даёт прозрачность, предсказуемость и метрики, а ритм встреч (планирование, демо для стейкхолдеров, уточнение бэклога, ежедневная синхронизация) команда определяет сама. Ещё один его тезис: управлять нужно потоком, а не людьми.

Академическая линия: что показали исследования

Научной литературы о Scrumban немного. В основном это кейсы и опросы, а не контролируемые эксперименты.

• Никитина, Кайко-Маттссон, Стрэйл (2012, ICSSP) описали переход от Scrum к Scrumban в одной компании-разработчике. В статье разобраны ход перехода, изменения в процессе, полученные улучшения и уроки. Авторы отмечают, что отчётов о самом процессе смены методологии в литературе почти нет.

• Йылмаз и О'Коннор (2016) внедрили гибридный Scrumban с геймификацией в турецкой компании малого и среднего бизнеса. Сначала провели фокус-группу, чтобы понять, что можно улучшить, затем кросс-секционный опрос персонала об изменениях.

• Банийамали, Ахмад, Симиля (2016) изучали распределённую разработку в Финляндии и Италии (кейс описан во вступлении).

• Алкудах и Разали (2018) исследовали, как Scrumban собирается из практик Scrum и Kanban под конкретный проект. Главное предупреждение: неудачная комбинация практик может увеличить потери и сроки и снизить качество. В обзоре Бхавсара и соавторов (2020) их работа приведена как свидетельство того, что Scrumban снижает потери времени и повышает продуктивность и качество по сравнению с чистыми Scrum и Kanban.

• Албарк и Куреши (2018) предложили L-Scrumban, связку Lean, Scrum и Kanban. По опросу, 89 % участников «очень высоко согласились», что методология эффективна на всём жизненном цикле проекта, а 88 % — что одних принципов Lean недостаточно для решения технических и управленческих задач.

• Стоика, Гилик-Мику, Мирча (2016) проследили эволюцию от каскадной модели к Scrumban. Главным барьером внедрения гибких методов они называют организационную культуру. Из обзорных данных: отсутствие опыта с гибкими методами (41 %), нехватка поддержки менеджмента (38 %), сопротивление изменениям (42 %) и уже действующая жёсткая каскадная рамка (40 %).

• Махнич (2015) перестроил выпускной курс по программной инженерии: Kanban вводился либо в связке со Scrum (как Scrumban), либо «в чистом виде» без части активностей Scrum, которые считались потерями. Роль владельца продукта исполнял эксперт предметной области.

• Бхавсар, Шах, Гопалан (2020) описали Scrumban как интеграцию двух методов и предложили вариант Scrumbanfall с элементами каскадной модели. Они ссылаются на работу Патила и Неве (2018): Kanban сам по себе не покрывает весь цикл разработки.

• Лунесу, Мюнх, Маркези (2018) построили имитационную модель распределённой разработки в облаке. Она позволяет руководителю проекта сравнивать подходы к организации процесса до того, как менять реальную команду.

• Лутфиани, Харахап, Аини (2020) спроектировали управление проектом онлайн-обучения (iLearning) на Scrumban и пришли к выводу, что так управление становится эффективнее. Это пример переноса метода за пределы разработки ПО.

Расхождение с популярными пересказами. В маркетинговых гайдах встречается утверждение, что гибкие подходы повышают продуктивность на 25–30 % за 6–18 месяцев (monday.com). Первоисточник там не указан, а академические работы из этого обзора таких цифр не дают: в них описаны кейсы и мнения участников. Опрос Албарк и Куреши измеряет согласие респондентов, а не фактическую производительность.

Ключевые идеи и принципы Scrumban

1. Принцип: Scrumban — сплав, а не сумма

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

   • Scrum: фиксированные итерации, заданные роли, обязательный набор событий, планирование по календарю.

   • Kanban: непрерывный поток, никаких предписанных ролей, лимиты по этапам, работа вытягивается по сигналу.

   • Scrumban: поток с лимитами и вытягиванием плюс тот ритм встреч, который команда сочла полезным. Планирование запускается по событию, итерации необязательны.

2. Принцип: визуализация на доске

   Доска Scrumban — это канбан-доска с этапами работы команды. По описанию Asana, на ней могут быть продуктовый бэклог, бэклог текущего цикла, этапы («не начато», «в процессе», «на рассмотрении») и колонка для завершённого. Часть команд держит на доске только ближайший бэклог, а продуктовый ведёт отдельно. Правила перехода между колонками должны быть явными: Пейн подчёркивает, что улучшить можно только то, что понимаешь, поэтому процесс нужно описать, опубликовать и обсудить с командой.

3. Принцип: лимиты незавершённой работы (WIP limits)

   У каждого этапа потока есть явный предел числа одновременно находящихся в нём задач. Если колонка заполнена, это не повод начать новую задачу, а сигнал о заторе: команда сначала помогает разгрузить этап. Лимиты защищают от распыления внимания и ускоряют прохождение работы. У Ладаса лимит может возникать из простого правила, а не только из цифры над колонкой: в его примере правило даёт эффективный предел в 6 задач.

   Переполненная колонка показывает, где система не справляется. Ответ на это — закончить начатое, а не взять новое.

4. Принцип: вытягивание (pull principle)

   Задачи не распределяет руководитель. Исполнитель забирает следующую задачу из колонки слева, когда у него освобождается место. Поэтому нагрузка определяется пропускной способностью системы, а не желанием загрузить всех. Отсюда тезис «управляй потоком, а не людьми».

5. Принцип: планирование по требованию (on-demand planning)

   Это главное отличие от Scrum. Вместо планирования раз в спринт задаётся порог для колонки «Готово к работе». Когда число задач в ней падает до порога, команда собирается и пополняет буфер. monday.com приводит пример: назначать сессию планирования, когда в колонке Ready остаётся меньше пяти задач. Порог подбирается так, чтобы задачи не кончились раньше, чем пройдёт планирование. Так исчезают оба сценария из вступления: простой при пустой очереди и раннее планирование при полной. Как устроен непрерывный горизонт планирования за пределами одной команды, разобрано в материале о непрерывном планировании.

6. Принцип: итерации — по желанию, ритм — по договорённости

   Итерации в Scrumban могут оставаться, но они больше не задают границу планирования. Scrum Alliance так и называет соответствующий раздел: «Спринты фиксированной длины (или нет!)». Если итерации сохраняются, они служат ритмом обзора и демонстрации. Ретроспективы и демо можно проводить по календарю независимо от того, как часто срабатывает триггер планирования.

7. Принцип: приоритизация и корзины горизонтов (bucket size planning)

   Приоритеты задаются в момент пополнения буфера: в «Готово к работе» попадает то, что сейчас важнее всего. Это ответ на частый вопрос, как Scrumban справляется с приоритизацией. Решение откладывается до последнего ответственного момента, а не фиксируется на две недели вперёд. Для длинных горизонтов используется планирование корзинами: идеи лежат в «дальних» корзинах и по мере созревания переходят в ближние, пока не станут конкретными задачами в буфере. Так стратегический бэклог и оперативная работа связаны без детального плана на месяцы вперёд.

8. Принцип: заморозка функциональности и сортировка (feature freeze и triage)

   Когда приближается фиксированная дата релиза, команда перестаёт брать в работу новые функции: это заморозка. Затем она проводит сортировку: из незавершённого выбирает, что доведёт до конца, а что сознательно отложит. Без такой процедуры поток не даёт ответа на вопрос, что войдёт в релиз.

9. Принцип: роли не предписаны

   В Scrumban нет обязательных ролей. Команда сохраняет те, что есть. Пейн добавляет, что можно взять роли Scrum и дальше развивать их по необходимости. Это снижает сопротивление при переходе: переход не требует ломать оргструктуру.

10. Принцип: непрерывное улучшение

    Канбан-составляющая делает узкие места видимыми, а ретроспективы превращают их в изменения процесса. Miro относит к ключевым компонентам Scrumban улучшение процесса в духе кайдзен. Аннотация к книге Ладаса связывает его с метриками и ежедневными управленческими техниками.

11. Принцип: когда метод уместен

    Atlassian и Asana называют похожие условия:

    • разработка с меняющимися требованиями;

    • несколько параллельных инициатив у одной команды;

    • стартапы и быстро меняющаяся среда;

    • долгосрочная поддержка продукта, где поток мелких задач важнее больших релизов;

    • случаи, когда Scrum «не совсем работает»: работа плохо укладывается в итерации или много срочных входящих задач.

    Переход возможен с обеих сторон, на что указывает Scrum Alliance. Команда на Scrum добавляет лимиты и триггер планирования. Команда на Kanban добавляет ритм обзоров и ретроспектив.

Ограничения, слепые зоны и критика Scrumban

Типовые ошибки при внедрении Scrumban

1. Ошибка 1: случайная сборка практик.

   Команда берёт из Scrum ежедневные встречи, из Kanban доску и на этом считает переход завершённым. Лимитов нет, триггера планирования нет, ретроспективы отменены как «лишние». Получается ровно то, о чём предупреждали Алкудах и Разали: процесс без ритма и без ограничений, где растут потери и сроки.

   Как избежать

   заранее записать, какие практики остаются, какие добавляются и какую проблему решает каждая. Минимальное ядро — доска, лимиты по этапам, порог буфера и ретроспектива.

2. Ошибка 2: декоративные WIP-лимиты.

   Лимиты написаны над колонками, но при переполнении никто не останавливается: «это срочное, возьмём сверх лимита». Через пару недель лимиты превышены везде, задачи висят на проверке, время выполнения растёт.

   Как избежать

   договориться о жёстком правиле. При превышении лимита новую задачу не берут, а свободные люди помогают разгрузить затор. Если лимит превышается постоянно, его пересматривают на ретроспективе, а не нарушают молча.

3. Ошибка 3: порог буфера взят с потолка.

   Порог «Готово к работе» назначен без учёта скорости команды. Если он слишком низкий, задачи кончаются раньше, чем удаётся собрать планирование, и команда простаивает. Если слишком высокий, планирование идёт почти непрерывно и съедает время, а задачи в буфере успевают устареть.

   Как избежать

   начать с порога, которого хватает на время организации встречи планирования, и корректировать его по фактам: сколько задач команда забирает за день и как часто срабатывал триггер.

4. Ошибка 4: двойное планирование.

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

   Как избежать

   явно разделить роли ритмов. Триггер отвечает за пополнение буфера, календарь — за демо и ретроспективу. Если итерации сохраняются, их планирование превращается в обзор целей, а не в набор задач.

5. Ошибка 5: ломка ролей на старте.

   Руководитель одновременно меняет процесс и роли: упраздняет скрам-мастера, переназначает владельца продукта. Сопротивление изменениям, которое Стоика и соавторы называют одним из главных барьеров, растёт вдвое.

   Как избежать

   оставить текущие роли, как рекомендует сам подход, и менять их только тогда, когда поток покажет, в чём роль мешает.

6. Ошибка 6: релиз без заморозки и сортировки.

   В непрерывном потоке нет естественного конца, и при приближении даты релиза команда продолжает брать новые функции. За день до срока выясняется, что половина начатого не готова, а выбора, что отложить, никто не делал.

   Как избежать

   заранее назначить дату заморозки, после которой новые функции не стартуют, и провести сортировку незавершённого с владельцем продукта.

План внедрения Scrumban

Scrumban — лёгкая техника уровня команды, поэтому план рассчитан на недели.

1. Неделя 1: аудит и визуализация. Соберите текущие задачи команды и выпишите реальные этапы, через которые проходит работа: не «как должно быть», а как есть. Постройте доску с этими колонками, включая «Готово к работе» и «Готово». Опишите правила перехода между колонками. Запишите, какие события Scrum остаются (ретроспектива, демо, ежедневная синхронизация) и какую проблему вы хотите решить переходом.

2. Неделя 2: WIP-лимиты. Неделю посмотрите, сколько задач обычно находится в каждой колонке. Установите лимиты чуть ниже наблюдаемого уровня и договоритесь о правиле: при превышении новую работу не берут. Отмечайте каждый случай, когда лимит упирается: это первая карта узких мест.

3. Неделя 3: буфер и порог. Определите, сколько задач команда забирает из «Готово к работе» за день и сколько времени нужно на организацию планирования. Задайте порог буфера так, чтобы его хватало на это время с запасом. Введите правило вытягивания: исполнитель сам берёт верхнюю задачу из буфера.

4. Неделя 4: запуск триггерного планирования. Отмените обязательное календарное планирование задач, оставив календарь для демо и ретроспектив. Назначьте ответственного за отслеживание буфера. Каждое срабатывание триггера фиксируйте: дата, сколько задач было в буфере, сколько добавили.

5. Неделя 5: релизный контур и первая ретроспектива. Если есть фиксированная дата поставки, назначьте дату заморозки и порядок сортировки. Проведите ретроспективу по данным: сколько раз срабатывал триггер, были ли простои, какие колонки превышали лимиты. Скорректируйте порог и лимиты.

   Далее: поддержание и обновление. Раз в цикл ретроспектив пересматривайте лимиты и порог по фактическим данным. Следите, не превратилась ли доска в формальность: расхождение с реальностью — первый признак отката. Если вы шли от Scrum к канбан-системе, решите, какие опоры («страховочные колёса») уже можно убрать. Когда команд станет несколько, переходите к механизмам межкомандной координации.

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

Как реализовать этот план с помощью фрейма «Scrumban» в OrgDevTools

Фрейм «Scrumban» — бесплатный тренажёр. Это модель доски с WIP-лимитами и автоматическим триггером планирования. Тот же фрейм доступен как Инструмент «SCRUMBAN — Гибрид Scrum и Kanban» в разделе проектов и задач. Там он привязан к записи инструмента, и состояние доски сохраняется вместе с ней. Фрейм состоит из трёх вкладок.

Вкладка «Доска» (недели 1–3 плана). Четыре колонки с дефолтными значениями:

• «Готово к работе»: лимит 8, карточек 5;

• «В работе»: лимит 4, карточек 3;

• «На проверке»: лимит 3, карточек 4;

• «Готово»: лимит 0, карточек 12.

В каждой колонке два числовых поля: «Карточек» (текущее количество задач) и «Лимит WIP». Значение 0 в лимите означает «без лимита», в режиме просмотра вместо него показывается «—». Отрицательные значения не принимаются. У колонки «Готово к работе» есть третье поле, «Порог буфера», по умолчанию 3. Цвет колонки меняется автоматически: красная с пометкой «превышен WIP-лимит — затор», если карточек больше лимита; янтарная, если в буфере столько же задач, сколько порог, или меньше; синяя в остальных случаях. На неделе 1 сверьте колонки фрейма со своими этапами, на неделе 2 внесите наблюдаемые количества и лимиты, на неделе 3 подберите порог.

Обратите внимание: триггер срабатывает при числе карточек меньше или равном порогу, хотя в тексте вердикта сказано «опустился ниже порога». При пороге 3 сигнал появится уже на трёх задачах в буфере.

Вкладка «Визуализация» (недели 2 и 5). Для каждой колонки строится полоса заполненности «карточки / лимит» с подписью в числах. Если лимит превышен, полоса красная. Ширина ограничена 100 %, поэтому степень перегруза видна по подписи, а не по длине полосы. Колонки без лимита показываются полосой на половину ширины без подписи лимита: это условное изображение, а не расчёт. Вкладка пригодится на ретроспективе, чтобы увидеть, где система ближе всего к затору.

Вкладка «Итоги» (недели 4–5 и далее). Блок «Вердикт» проверяет условия в строгом порядке:

1. Если хотя бы одна колонка превышает лимит, выводится 🚧 с перечнем перегруженных колонок и выводом, что новые карточки брать нельзя, пока затор не разгружен.

2. Если перегрузок нет, но буфер на пороге или ниже, выводится ⏰ «пора запускать планирование пополнения».

3. Иначе выводится ✅ «поток стабилен».

Порядок отражает логику метода: сначала закончить начатое, потом пополнять очередь. С дефолтными данными фрейм сразу показывает затор в «На проверке» (4 при лимите 3).

Кнопка «Создать задачу →» формирует задачу. Если сработал триггер, её название — «Запустить планирование пополнения буфера», в остальных случаях — «Разгрузить перегруженную колонку». В описание попадает список перегруженных колонок или текущее число задач в буфере. Учтите одну особенность: если одновременно есть перегрузка и сработал триггер, название задачи будет про планирование, а описание — про перегрузку. В таком случае поправьте задачу вручную, чтобы сначала шла разгрузка.

Книги по теме Scrumban

• Кори Ладас — «Scrumban: Essays on Kanban Systems for Lean Software Development» (2009). Первоисточник: переход от Scrum к канбан-системе, карточка как сигнал ёмкости, WIP-лимиты, планирование по требованию, метрики для непрерывного улучшения.

• Аджай Редди — «The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban» (2015). Kanban как катализатор постепенных изменений в существующем процессе, разбор того, чем Scrumban является и чем не является, применение на уровне команды и организации.