Scrum и Kanban придуманы для одной команды: 5-9 человек, один backlog, одни ежедневные стендапы. Пока команда одна, всё просто — она сама решает, что делать, и сама отвечает за результат. Но крупный продукт редко делает одна команда. Банковское приложение, маркетплейс, ERP — это десятки, а то и сотни разработчиков. И тут возникает вопрос: как заставить 10, 20 или 50 команд двигаться в одну сторону, не превратив всё в хаос? Ответ пытаются дать фреймворки масштабирования Agile — SAFe, LeSS и другие. Разберём, откуда берётся проблема и что предлагают эти подходы.
Почему Scrum одной команды не масштабируется сам по себе
Когда над продуктом работает одна команда, все договорённости умещаются в голове. Все знают, кто что делает; если задача зависит от другой задачи — люди просто поговорили и разрулили.
Добавьте вторую команду — и появляются зависимости. Команда A не может закончить свою функцию, пока команда B не выдаст нужный API. Команда B не в курсе, что кого-то заблокировала, потому что у неё свой backlog и свои приоритеты. Умножьте это на десять команд — и получите ситуацию, где никто не видит общей картины, релизы срываются, а половина времени уходит на выяснение «а вы это уже сделали или нет».
Три главные боли масштабирования:
- Зависимости между командами. Одна ждёт другую; блокировки всплывают в последний момент.
- Общий backlog и приоритеты. У продукта один список задач, но команд много — кто решает, что важнее?
- Синхронизация. Если команды работают в разном ритме и релизят вразнобой, собрать из их кусков цельный продукт тяжело.
Фреймворки масштабирования — это, по сути, набор правил и церемоний, которые пытаются эти три боли снять. Отличаются они тем, сколько надстроек добавляют поверх обычного Scrum.
SAFe: тяжёлый фреймворк с уровнями
SAFe (Scaled Agile Framework) — самый популярный и самый «тяжёлый» из подходов. Его идея: раз команд много, нужны отдельные уровни управления, каждый со своими ролями и церемониями.
Уровней обычно три:
| Уровень | За что отвечает |
|---|---|
| Команда (Team) | Обычный Scrum или Kanban внутри одной команды |
| Программа (Program) | Координация нескольких команд, работающих над одним продуктом |
| Портфель (Portfolio) | Стратегия, бюджеты, связь с целями бизнеса |
Ключевые понятия SAFe:
- Agile Release Train (ART) — «поезд релизов». Это группа из 5-12 команд (50-125 человек), которые работают над общей целью и релизят синхронно. Все едут в одном поезде и по одному расписанию.
- PI Planning (Program Increment Planning) — большое общее планирование раз в 8-12 недель, где все команды поезда собираются вместе (очно или онлайн) и на два дня согласуют, кто что делает и как разруливать зависимости. Это сердце SAFe.
SAFe даёт структуру и предсказуемость, но платит за это весом: много ролей (Release Train Engineer, Product Manager, System Architect и другие), много церемоний, много документов. Критики говорят, что SAFe рискует превратить Agile обратно в тяжёлый управленческий процесс с большим числом менеджеров. Поэтому его чаще выбирают крупные корпорации, которым важнее контроль и предсказуемость, чем гибкость.
LeSS: Scrum как есть, но для многих команд
LeSS (Large-Scale Scrum) идёт от противоположного принципа: не добавлять надстройки, а оставить Scrum почти нетронутым и растянуть его на несколько команд.
Главные отличия от SAFe:
- Один общий backlog на весь продукт и один Product Owner. Он расставляет приоритеты для всех команд сразу — не появляется отдельного уровня «программы» со своими списками задач.
- Один общий sprint для всех команд. Все стартуют и финишируют одновременно, на общем обзоре показывают единый результат.
- Минимум новых ролей. LeSS не вводит кучу должностей — базовые роли Scrum остаются, просто применяются к нескольким командам.
LeSS работает для 2-8 команд (в варианте LeSS Huge — больше, с делением на области требований). Философия здесь такая: сложность нужно убирать, а не добавлять. Если для координации потребовалось много новых ролей и процессов — значит, проблему решают не в том месте. LeSS подходит организациям, готовым менять устройство команд ради простоты, а не наращивать управленческий слой.
Коротко разница: SAFe добавляет уровни и роли поверх команд; LeSS убирает всё лишнее и заставляет команды напрямую договариваться вокруг одного backlog.
Spotify-модель: пример, а не фреймворк
Часто в разговорах о масштабировании всплывает Spotify-модель с её squads, tribes, chapters и guilds. Важно понимать: это не фреймворк, а рассказ о том, как в одной компании была устроена работа в определённый момент.
Термины простые:
- Squad — маленькая автономная команда, аналог Scrum-команды, отвечает за свой кусок продукта.
- Tribe — группа squad'ов, работающих в близкой области.
- Chapter — люди одной специальности (например, все backend-разработчики) внутри tribe, чтобы делиться практиками.
- Guild — сообщество по интересам через всю компанию (например, все, кому интересно тестирование).
Модель красивая и её многие пытались копировать. Но есть нюанс: даже в самой Spotify это было описанием текущего состояния, а не готовым рецептом — и внутри компании эта схема со временем менялась. Копировать чужую структуру команд, не понимая, какие проблемы она решала, — частая ошибка. Spotify-модель полезна как источник идей (автономия команд, горизонтальные сообщества), но не как фреймворк, который можно «внедрить» по инструкции.
Главный принцип: сначала убрать зависимости, потом добавлять церемонии
Из всего вышесказанного следует главный вывод, который часто теряется за названиями фреймворков.
Масштабируют не ради масштаба. Все церемонии SAFe и LeSS существуют, чтобы бороться с зависимостями между командами. Но самый дешёвый способ справиться с зависимостью — это её убрать, а не научиться её координировать.
Что убирает зависимости в первую очередь:
- Архитектура. Если продукт разбит на слабо связанные части (сервисы, модули) с чёткими границами, команда может делать свой кусок, почти не завися от соседей. Хорошая архитектура снимает больше зависимостей, чем любое общее планирование.
- Автономные команды. Если у команды есть всё, чтобы довести задачу до конца самой — от базы данных до интерфейса, — ей не нужно ждать четыре другие команды.
И только когда зависимости объективно остаются (а полностью их убрать в большом продукте нельзя), имеет смысл добавлять координацию — PI Planning, общий backlog, синхронные sprint'ы. Порядок именно такой: сначала архитектура и границы команд, потом церемонии. Если сделать наоборот — навесить тяжёлый фреймворк на запутанную систему, — вы получите дорогой ритуал по управлению хаосом, а не решение проблемы.
Поэтому выбор фреймворка вторичен. Сначала честно спросите: почему командам вообще приходится так много друг друга ждать? Часто ответ лежит не в процессах, а в устройстве продукта и команд.
Коротко
- Scrum и Kanban придуманы для одной команды; при 10+ командах на один продукт появляются зависимости, борьба за общий backlog и проблема синхронизации.
- SAFe — тяжёлый фреймворк с уровнями «команда / программа / портфель», понятиями Agile Release Train и PI Planning; много ролей и церемоний, выбирают крупные корпорации ради предсказуемости.
- LeSS — «Scrum как есть» для нескольких команд: один backlog, один Product Owner, один общий sprint, минимум новых ролей; философия — убирать сложность, а не добавлять.
- Spotify-модель (squads / tribes / chapters / guilds) — это пример устройства работы одной компании, а не фреймворк; копировать её структуру вслепую — ошибка.
- Все церемонии масштабирования существуют ради борьбы с зависимостями между командами.
- Самый дешёвый способ справиться с зависимостью — убрать её: хорошая архитектура и автономные команды снимают больше зависимостей, чем любое общее планирование.
- Порядок правильный: сначала архитектура и границы команд, потом координационные церемонии — не наоборот.
Что почитать дальше
- Scrum
- Kanban
- Модели разработки