Масштабирование Scrum: Nexus, LeSS, SAFe — что нужно знать для экзамена

Обычно это звучит так: «Нас стало сорок человек, продукт один, релизы разъезжаются. Давайте внедрим SAFe». Дальше приезжает консультант, рисует на стене поезд, все проходят двухдневный тренинг — и через полгода команды жалуются на те же самые вещи, что и до внедрения. Фича по-прежнему живёт три спринта, потому что ждёт соседнюю команду. Интеграция по-прежнему случается в конце квартала. Только теперь у этого есть красивое название.

Причина в подмене вопроса. Организация спрашивает «какой фреймворк выбрать», хотя настоящий вопрос — «почему наши команды не могут закончить работу самостоятельно». Фреймворк масштабирования не убирает зависимости. Он делает их видимыми и даёт ритуал для их согласования. Это полезно, но это лечение симптома, а не причины.

Эта статья решает две задачи сразу. Первая — практическая: понять физику масштабирования и разобраться, что на самом деле предлагают Nexus, LeSS и SAFe. Вторая — экзаменационная: понять, какая крошечная часть этой темы попадает в PSM I, и не потерять баллы, отвечая по SAFe там, где спрашивают по Scrum Guide.

Дисциплина различения. Как и в остальных статьях трека, я помечаю уровни: [SG] — прямо написано в Scrum Guide; [Nexus], [LeSS], [SAFe] — правила конкретного фреймворка, которых в Scrum Guide нет; [практика] — распространённый приём; [антипаттерн] — так делают часто, и это вредит. На PSM I засчитывается только уровень [SG].

Сначала главное: что из этого действительно нужно для PSM I

Скажу неприятную для многих вещь. PSM I не проверяет знание Nexus, LeSS или SAFe. Экзамен построен вокруг Scrum Guide, и вопросы по нескольким командам сводятся к нескольким строчкам самого Guide. Nexus проверяется на отдельной сертификации Scrum.org — SPS (Scaled Professional Scrum), а SAFe сертифицирует Scaled Agile, Inc., и к Scrum.org отношения не имеет.

Практический вывод: не тратьте недели на заучивание конфигураций SAFe перед PSM I. Выучите досконально то, что Guide говорит о нескольких командах, — это буквально два абзаца, и они дают все правильные ответы.

[SG] Абзац первый — про размер и деление. «Если Scrum-команды становятся слишком большими, им следует рассмотреть возможность реорганизации в несколько сплочённых Scrum-команд, каждая из которых сфокусирована на одном и том же продукте. Следовательно, они должны разделять одну и ту же цель продукта, Product Backlog и Product Owner».

[SG] Абзац второй — про Definition of Done. «Если несколько Scrum-команд работают вместе над продуктом, они должны совместно определить и соблюдать одно и то же Definition of Done».

Всё. Больше про масштабирование в Scrum Guide нет ничего. Из этих двух абзацев выводится набор ответов, который закрывает почти любой вопрос экзамена по теме.

Три ловушки, которые из этой таблицы вытекают и регулярно встречаются на экзамене:

1. «У каждой команды свой Product Owner» — неверно всегда, когда речь про один продукт. Может быть один PO и люди, которым он делегирует часть работы, но подотчётность неделима.
2. «Definition of Done у каждой команды своё» — неверно. Общее DoD обязательно; ужесточать локально можно, ослаблять нельзя.
3. «Общая цель спринта на все команды» — это не требование Scrum Guide. Такая конструкция есть в Nexus (Nexus Sprint Goal), но не в самом Scrum. На вопросе про Scrum Guide это неправильный ответ.

Подробнее про сами артефакты и обязательства — в статье Артефакты и обязательства, про распределение ответственностей — в статье Три ответственности.

Физика проблемы: почему N команд не дают N-кратной скорости

Прежде чем сравнивать фреймворки, надо понять, что именно ломается. Три механизма.

Коммуникационная нагрузка. Число возможных парных каналов связи в группе из n человек равно n(n-1)/2. Для 8 человек это 28 каналов, для 40 — 780. Никакой фреймворк это число не уменьшает; он лишь ограничивает, какие каналы обязаны быть активными. Именно поэтому Scrum Guide говорит про «10 или меньше» человек в команде: за этой границей общий контекст перестаёт держаться в головах.

Зависимости. Если фича требует работы двух команд, её срок определяется не суммой трудозатрат, а моментом, когда обе команды окажутся свободны и синхронны. Ожидание в очереди почти всегда больше самой работы. Это классика теории массового обслуживания, и она же объясняет, почему добавление команды в загруженную систему часто замедляет поток. Мы разбирали эту механику в статье про поток и Kanban — Kanban и поток.

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

Обратите внимание на две левые ветки. Они самые дешёвые и самые редко выбираемые. Прежде чем брать любой фреймворк, Scrum-мастер обязан задать вопрос: а нельзя ли просто убрать зависимость?

Главный рычаг: границы команд, а не ритуалы

Зависимости не падают с неба — они наследуют структуру системы и структуру организации. Отсюда прямой практический ход: если команда владеет вертикальным срезом ценности (UI, API, база, тесты, выкатка), она заканчивает фичу сама. Если команда владеет слоем, любая фича проходит через три очереди.

[LeSS] Фиче-команды. LeSS делает переход к фиче-командам центральным элементом, а не рекомендацией. Логика: сначала перестраиваем границы, потом смотрим, сколько координации осталось.

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

[практика] Что делает Scrum-мастер. Прямо влиять на оргструктуру он обычно не может, но может сделать проблему видимой:

• Считайте долю элементов бэклога, требующих больше одной команды. Если это 60%, никакой фреймворк не спасёт.
• Считайте время ожидания отдельно от времени работы. Разговор «эта фича делалась 4 дня и ждала 19» меняет обсуждение сильнее любой презентации.
• Показывайте это руководству регулярно, а не один раз. Работа со стейкхолдерами и сопротивлением — в статье Коучинг команды и конфликты.

Про закон Конвея, обратный манёвр Конвея и Team Topologies подробнее написано в статье Масштабирование процессов — здесь повторяться не буду.

Nexus: минимальная добавка ради интеграции

Nexus — фреймворк самой Scrum.org, разработанный Кеном Швабером. Его философия: не добавлять ничего, кроме того, что необходимо для решения одной проблемы — зависимостей и интеграции.

Размер: примерно от трёх до девяти Scrum-команд, работающих над одним Product Backlog и производящих один интегрированный инкремент.

Что Nexus добавляет к Scrum:

Порядок событий за спринт — та часть, которую чаще всего путают.

Что важно понять про Nexus Daily Scrum: это не замена командным дейли и не «скрам оф скрамс» со статусами. Он идёт первым, длится коротко и обсуждает ровно одно: интегрирован ли инкремент, какие зависимости всплыли, что мешает сборке. Каждая команда после него проводит своё обычное 15-минутное событие.

[антипаттерн] Nexus как отчётная вертикаль. Если Nexus Daily Scrum превратился в летучку, где представители докладывают проценты выполнения, вы получили лишний слой менеджмента и потеряли смысл. Признак здоровья: на этом событии обсуждают конкретные технические стыки и договариваются о действиях сегодня.

Когда Nexus подходит. Один продукт, 3–9 команд, главная боль — «мы не можем собрать всё вместе». Nexus дешёвый: он не требует переписывать оргструктуру и не вводит новых уровней планирования. Это самый близкий к Scrum вариант из всех.

LeSS: масштабирование через расмасштабирование

LeSS (Large-Scale Scrum) Крэга Лармана и Баса Водде исходит из противоположной SAFe идеи: масштабировать надо не процесс, а применение Scrum. Всё лишнее — убрать. Отсюда лозунг «descaling the organization».

Две конфигурации:

• LeSS — примерно до восьми команд, один Product Owner, один Product Backlog.
• LeSS Huge — больше восьми команд. Появляются Requirement Areas (области требований), у каждой свой Area Product Owner и Area Product Backlog. Общий Product Owner и общий Product Backlog при этом сохраняются.

Что в LeSS общее для всех команд: один спринт (все стартуют и финишируют одновременно), один Product Owner, один Product Backlog, одно Definition of Done, один потенциально поставляемый инкремент, общий Sprint Review, общая Overall Retrospective.

События LeSS:

• Sprint Planning One — представители всех команд и PO решают, какая команда что берёт, и обсуждают пересечения. Затем Sprint Planning Two — каждая команда планирует у себя (команды с сильно связанной работой могут планировать вместе, в одной комнате).
• Daily Scrum — обычный, у каждой команды. [практика LeSS] «Разведчики»: член одной команды приходит на дейли соседней, чтобы синхронизироваться без отдельной встречи.
• Overall Product Backlog Refinement — многокомандное уточнение крупных элементов.
• Overall Retrospective — после командных ретроспектив, с участием PO, Scrum-мастеров, представителей команд и менеджеров; тема — системные проблемы, которые команда не может решить сама.

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

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

SAFe: тяжёлый, популярный, спорный

SAFe (Scaled Agile Framework) — самый распространённый в корпорациях фреймворк и самый критикуемый в Agile-сообществе. Он не столько масштабирует Scrum, сколько строит целую операционную модель поверх него.

Анатомия в минимальном виде:

• ART (Agile Release Train) — «поезд» из нескольких команд, обычно 50–125 человек, работающих над одним решением. Это основная единица SAFe.
• PI (Program Increment) — интервал планирования, обычно 8–12 недель, то есть 4–6 итераций.
• PI Planning — двухдневное событие, где весь поезд планирует следующий PI: цели команд, зависимости на доске программы, риски по схеме ROAM.
• Роли, которых нет в Scrum: RTE (Release Train Engineer) — фасилитатор поезда, Product Management (над командными PO), System Architect, Business Owners.
• Конфигурации: Essential, Large Solution, Portfolio, Full — от одного поезда до портфельного уровня с потоками ценности и Lean-бюджетированием.
• WSJF — приоритизация по отношению стоимости задержки к длительности работы. Разбор формулы и её слабых мест — в статье Масштабирование процессов.

Где SAFe расходится со Scrum Guide. Это ключевая часть для понимания, и её стоит держать в голове отдельно от экзамена:

Честная критика. Основной риск SAFe — он позволяет организации выглядеть Agile, ничего не меняя по существу: те же квартальные обязательства, та же вертикаль, только с новыми названиями. Кен Швабер писал о нём резко; Рон Джеффрис публиковал разбор «SAFe — Good But Not Good Enough». Стоит прочитать оригинал, а не пересказы.

Честная защита. В организациях с сотнями людей, регуляторными аудитами и внешними зависимостями SAFe даёт то, чего нет у LeSS и Nexus: общий язык, предсказуемый ритм и явное место, где зависимости обсуждаются. Синхронное PI Planning на два дня часто оказывается первым событием, где команды впервые видят полную картину. Это реальная ценность, даже если цена высокая.

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

Scrum@Scale и сравнение фреймворков

Scrum@Scale Джеффа Сазерленда строится на идее «масштабировать сам Scrum рекурсивно»: Scrum of Scrums из представителей команд, у которого есть свой Scrum-мастер (SoS Master), и параллельно MetaScrum для владельцев продуктов с Chief Product Owner. Два независимых цикла — цикл Scrum-мастера (как) и цикл Product Owner (что) — пересекаются в нескольких точках. Фреймворк лёгкий и модульный, но менее конкретный, чем Nexus: он даёт схему, а не готовые события.

Сводная таблица для быстрого сравнения:

Сценарии из жизни и разбор

Сценарий 1. «У нас три команды, каждая со своим бэклогом и своим PO. Продукт один». Что не так: нарушено прямое требование Scrum Guide. Симптом, который это выдаёт, — три PO спорят, чья задача важнее, и решает это менеджер сверху. Что делает Scrum-мастер: не бежит объявлять «так нельзя», а показывает последствия. Соберите статистику за два месяца: сколько раз работа переделывалась из-за конфликта приоритетов, сколько раз фича ждала соседей. Затем предложите эксперимент на два спринта: один общий бэклог, один человек с правом порядка, остальные PO становятся ему помощниками по областям. Эксперимент с обратимостью проходит там, где «правильное решение» блокируется.

Сценарий 2. «Мы внедрили Nexus, но интеграция всё равно в конце спринта». Nexus не чинит инженерные практики — он их требует. Если нет непрерывной интеграции, автоматических тестов и общего пайплайна, Nexus Integration Team превращается в отряд ручных сборщиков. Что делать: сделать «интегрированный инкремент каждый день» явной целью на ближайшие ретроспективы и добиться, чтобы NIT занималась обучением команд практикам CI, а не сборкой вместо них. Полезный ориентир по инженерной части — метрики DORA, разбор в статье DORA и инженерные метрики.

Сценарий 3. «Руководство решило внедрять SAFe. Меня переименовали в Team Coach». Не тратьте капитал на спор о названии. Определите заранее, что для вас неприкосновенно: готовый инкремент каждую итерацию, право команды решать «как», ретроспектива с реальными действиями, PO с правом говорить «нет». Это ваш периметр. Всё остальное — детали конфигурации, по которым можно уступать. Такой подход сохраняет и отношения, и суть.

Сценарий 4. «Пять команд, у каждой свой Definition of Done, потому что стеки разные». Разные стеки — не оправдание. Общее DoD формулируется на уровне свойств результата, а не инструментов: покрыто автотестами, прошло ревью, задеплоено на стенд, не ломает интеграционный прогон, документация обновлена. Как это проверяется в конкретном стеке — уже дело команды. Команда вправе добавить свои пункты сверху, но не отменить общие. Подробнее про DoD — в статье Артефакты и обязательства.

Сценарий 5. «Нас 12 человек, давайте разделимся на две команды и возьмём Nexus». 12 человек — это чуть больше одной команды. Начните с простого: две команды, один PO, один бэклог, одно DoD, общий Sprint Review. Добавляйте элементы Nexus только тогда, когда появится конкретная боль, которую они лечат. Фреймворк, взятый «на вырост», обычно даёт ритуалы без содержания. Про типовые формы такого карго-культа — в статье Антипаттерны Scrum.

Вопросы в формате PSM I

Вопрос 1. Пять Scrum-команд работают над одним продуктом. Сколько Product Backlog должно быть?

• A. По одному на каждую команду
• B. Один на продукт
• C. Один общий плюс по одному локальному на команду
• D. Решает Scrum-мастер

Ответ: B. Scrum Guide прямо требует, чтобы команды на одном продукте разделяли один Product Backlog, один Product Goal и одного Product Owner. Вариант C выглядит «практичным» и потому соблазнителен, но локальные бэклоги ломают прозрачность: невозможно увидеть единый порядок работы и понять, что важнее. Вариант D неверен по существу — это не решение Scrum-мастера, а правило фреймворка.

Вопрос 2. Три команды работают над одним продуктом. Каким должно быть Definition of Done?

• A. У каждой команды своё, с учётом специфики технологии
• B. Одно общее, определённое совместно; команда может добавить более строгие критерии для себя
• C. Определяется Product Owner единолично
• D. Определяется организацией и не подлежит изменению

Ответ: B. Guide требует совместно определённого единого DoD. При этом отдельная команда вправе применять более строгие критерии — но не более мягкие. Вариант D частично верен только в частном случае: если стандарт DoD задан организацией, команды обязаны ему следовать как минимуму, но они всё равно могут ужесточить его; формулировка «не подлежит изменению» делает вариант неверным.

Вопрос 3. Кто отвечает за то, что все команды в Nexus производят интегрированный инкремент?

• A. Каждая Scrum-команда самостоятельно
• B. Nexus Integration Team
• C. Release Train Engineer
• D. Product Owner

Ответ: B. Это определение из Nexus Guide: NIT отвечает за то, чтобы хотя бы раз за спринт появлялся «готовый» интегрированный инкремент. Вариант C относится к SAFe и в Nexus не существует. Полезное замечание: сам этот вопрос — за пределами PSM I; он появится на SPS.

Вопрос 4. Несколько команд работают над одним продуктом. Что верно про спринт?

• A. Каждая команда обязана иметь спринты одинаковой длины
• B. Каждая команда обязана иметь общую цель спринта на всех
• C. Scrum Guide не задаёт правил синхронизации спринтов между командами
• D. Спринты должны идти со сдвигом, чтобы релизы были чаще

Ответ: C. В Scrum Guide нет требований о синхронизации длины спринтов или об общей цели спринта. Общие спринты и общая цель — это правила Nexus и LeSS, а не Scrum. Практически синхронные спринты почти всегда удобнее, потому что упрощают интеграцию и общий обзор, — но на вопросе «что говорит Scrum» ответ про отсутствие правила. Различать «Guide молчит» и «Guide запрещает» — один из главных навыков на экзамене.

Вопрос 5. Организация хочет масштабировать разработку и просит Scrum-мастера предложить первый шаг. Что уместнее всего?

• A. Выбрать фреймворк масштабирования и провести обучение
• B. Сделать зависимости и время ожидания видимыми, а затем уменьшать их
• C. Нанять больше разработчиков в существующие команды
• D. Ввести отдельную роль координатора между командами

Ответ: B. Эмпирический подход требует сначала сделать проблему прозрачной, затем инспектировать и адаптировать. Вариант A — решение до диагноза. Вариант C ухудшит ситуацию: команда больше 10 человек теряет управляемость. Вариант D добавляет посредника, не устраняя причину, и противоречит самоуправлению.

Вопрос 6. Одна Scrum-команда из 12 человек хочет разделиться. Что должно сохраниться после разделения?

• A. Цель продукта, Product Backlog, Product Owner
• B. Sprint Backlog и цель спринта
• C. Одинаковый состав компетенций в обеих командах
• D. Общий Daily Scrum

Ответ: A. Именно эти три сущности Guide называет общими для команд одного продукта. Sprint Backlog и цель спринта становятся у каждой команды своими. Одинаковый состав компетенций желателен для самостоятельности, но требованием не является. Общий Daily Scrum противоречит определению события: оно для разработчиков конкретной команды.

Как думать о таких вопросах. Если формулировка звучит как «сколько должно быть X при N командах», почти всегда правильный ответ — «один», когда X относится к продукту (бэклог, PO, цель продукта, DoD, инкремент), и «по одному на команду», когда X относится к спринту команды (Sprint Backlog, цель спринта, дейли, ретро). Больше техник разбора — в статье Экзамен PSM I.

Антипаттерны масштабирования

Фреймворк вместо диагноза. Организация покупает SAFe, не сформулировав, какую именно проблему решает. Через год измерений нет, улучшений нет, но есть сертифицированные сотрудники. Противоядие: до внедрения зафиксируйте 2–3 метрики, которые должны улучшиться, и срок проверки.

Масштабирование раньше времени. Две команды берут полный набор кросс-командных событий. Календарь забит, работать некогда. Противоядие: добавлять координационный механизм только под конкретную повторяющуюся боль.

Скрам оф скрамс как статус-митинг. Представители собираются, зачитывают проценты, расходятся. Никаких решений. Противоядие: правило «на выходе — минимум одно действие с владельцем и сроком», иначе встреча отменяется.

Component teams с названием feature teams. Команды переименовали, границы владения кодом остались. Зависимости никуда не делись. Противоядие: проверка «может ли команда довести элемент бэклога до DoD, не заводя задачу в другую команду».

Общий бэклог только на бумаге. Формально бэклог один, но фактически каждая команда работает по своему разделу, и порядок между разделами не определён. Противоядие: попросите PO упорядочить верхние 20 элементов сквозным списком без разбиения на команды. Если он не может — бэклог не один.

Интеграция раз в PI. Самая дорогая ошибка. Сборка всех веток раз в квартал означает, что первые реальные данные о работоспособности приходят через квартал. Противоядие: сделать частоту интеграции явным предметом ретроспектив и требовать её роста как инженерной цели.

Scrum-мастер как координатор релиза. При масштабировании на Scrum-мастера легко навешивают роль диспетчера зависимостей. Это удобно всем и разрушительно: команда перестаёт решать проблемы сама. Противоядие описано в статье Три ответственности.

Мини-итог

• Для PSM I достаточно двух абзацев Scrum Guide: команды одного продукта делят цель продукта, Product Backlog, Product Owner и единое Definition of Done. Sprint Backlog, цель спринта, дейли и ретро остаются у каждой команды своими.
• Nexus, LeSS, SAFe и Scrum@Scale на PSM I не проверяются. Знать их полезно для работы и для честного разговора с руководством, но на экзамене ответ по SAFe там, где спрашивают по Scrum, будет неверным.
• Nexus — минимальная надстройка ради интеграции: Nexus Integration Team, кросс-командное уточнение, общая цель спринта, общий обзор, трёхтактная ретроспектива.
• LeSS — про убирание лишнего и переход к фиче-командам; требует реального мандата на изменение оргструктуры.
• SAFe — полноценная операционная модель для сотен людей; даёт общий язык и ритм, но расходится со Scrum по самоуправлению, горизонту планирования и роли PO.
• Настоящий рычаг — не фреймворк, а границы команд. Сначала спросите, можно ли убрать зависимость. Часто это дешевле любого внедрения.
• Проверка на честность: если интегрированный инкремент не собирается минимум раз за спринт, у вас не масштабированный Scrum, а параллельный водопад с общим календарём.

Источники

• The Scrum Guide 2020 — раздел Scrum Team, требования к нескольким командам и Definition of Done.
• The Nexus Guide — официальное описание фреймворка от Scrum.org.
• LeSS: Large-Scale Scrum — сайт Крэга Лармана и Баса Водде; там же формулировки законов Лармана.
• Craig Larman, Bas Vodde. Large-Scale Scrum: More with LeSS (Addison-Wesley, 2016).
• SAFe Framework — официальная справка по конфигурациям, ART и PI Planning.
• Scrum@Scale Guide — описание рекурсивной модели Сазерленда.
• Ron Jeffries. SAFe — Good But Not Good Enough — аргументированная критика.
• Matthew Skelton, Manuel Pais. Team Topologies (IT Revolution, 2019) — про границы команд и когнитивную нагрузку, teamtopologies.com.
• Масштабирование процессов: SAFe, LeSS, Spotify-модель и их критика — расширенный разбор с математикой зависимостей и WSJF.

Что дальше

Теория закончилась — осталось сдать. В следующей статье разбираем сам экзамен: формат, тайминг, стратегию подготовки, открытые ассессменты Scrum.org и типичные категории вопросов с ловушками.

Экзамен PSM I: формат, подготовка, разбор типичных вопросов