Когда в разработке участвуют десятки и сотни человек, классического Scrum недостаточно: нужно синхронизировать цели, требования и поставку множества команд. Масштабируемые Agile-фреймворки SAFe (Scaled Agile Framework) и LeSS (Large Scale Scrum) решают эту задачу по-разному, опираясь на базовые практики из 05.02 Scrum и Kanban (аналитик в Agile). В обоих фреймворках аналитик связывает стратегические цели с работой команд — но набор артефактов, ритм планирования и глубина формализации различаются. Статья отвечает на вопрос: где живут требования на каждом уровне масштаба и что конкретно делает аналитик между PI Planning, Program Board и Overall PBR.

1. Суть темы

Масштабирование Agile — не «Scrum для больших команд», а координация нескольких команд над одним продуктом или решением с сохранением обратной связи и сквозной прослеживаемости. Два подхода, которые чаще всего встречаются на enterprise-проектах:

  • SAFe — иерархия уровней (Portfolio → Large Solution → Program → Team), ритм Program Increment (PI) (8–12 недель), формальные артефакты Epic → Capability → Feature → Story.
  • LeSS — минимализм: один Product Owner, единый Product Backlog, общий спринт; в LeSS Huge — области требований (Requirement Areas) с Area Product Owners (APO) при сохранении одного бэклога.

Помимо них в ландшафте есть Scrum Nexus (несколько команд, один продукт — ближе к LeSS по минимализму) и Spotify-модель (Tribes/Squads — организационный паттерн, не фреймворк с фиксированными ритуалами). SAFe и LeSS выбраны здесь как наиболее формализованные и часто внедряемые; выбор между ними — не вопрос «лучше/хуже», а соответствия контексту: регуляторика и множество стейкхолдеров тянут к SAFe, сильный PO и зрелые команды — к LeSS.

Essential SAFe (уровни Program + Team) — наиболее частая конфигурация: Epic Owner, Portfolio Kanban и Lean Business Case аналитику не встречаются, пока организация не подняла портфельный уровень. Full SAFe добавляет Large Solution и Portfolio — там появляются Capabilities и сквозная трассировка «эпик → capability → feature → story».

2. Ключевые понятия

2.1. Уровни и поток требований в SAFe

SAFe структурирует команды в Agile Release Train (ART) — долгоживущую группу из 5–12 команд, синхронно поставляющих ценность в ритме PI.

flowchart TD
    P(Portfolio: Epics, Strategic Themes) --> LS(Large Solution: Capabilities)
    LS --> PG(Program: Features, Enablers)
    PG --> T(Team: Stories)
    T --> INC(Increment)
    PG -.->|PI Planning| SYNC(Синхронизация команд)

Поток требований в Full SAFe. Essential SAFe охватывает только Program → Team.

Kanban-команды в ART. Большинство ART работает в Scrum-ритме. Kanban-команды участвуют в PI Planning и фиксации зависимостей на Program Board, но уточняют бэклог непрерывно — как в потоковом refinement из 05.02 Scrum и Kanban (аналитик в Agile), а не «пакетами» к итерации. Отличие от «обычного» Kanban-аналитика: жёсткая синхронизация с PI-целями и зависимостями между командами поезда, даже если собственный поток не привязан к спринтам.

2.2. Артефакты SAFe и связанные роли

УровеньАртефакты требованийРоль, связанная с аналитикойДеятельность аналитика
Portfolio (Full SAFe)Эпики (Business/Enabler Epics), Strategic Themes, Lean Business CaseEpic Owner — назначенная роль (часто её занимает [[00.01 Кто такой аналитик (роли BA, SA, FA)бизнес-аналитик]], но это не синоним BA)
Large Solution (Full SAFe, несколько ART)Capabilities, Solution Intent (общий), Solution BacklogSolution Management, Solution ArchitectДекомпозиция эпика в capabilities; трассировка «эпик → capability → feature»; NFR и интеграционные сценарии на стыке ART; Definition of Ready (DoR) для capability до передачи в Program Backlog.
ProgramFeatures, Enabler Features, Program Backlog, Solution IntentProduct Management (PM), System ArchitectПоддержка PM и Architect: формулировки фич, Feature Acceptance Criteria (см. 02.04.02 Критерии приёмки (Acceptance Criteria)), NFR для Solution Intent; DoR для feature; подготовка к PI Planning.
TeamUser Stories, Enabler Stories, Team BacklogProduct Owner (PO)Дробление фич на истории, Story AC, DoR для story; PI Planning, Iteration Planning, непрерывное уточнение.

Solution Intent и enabler-работа. System Architect ведёт Solution Intent — живой репозиторий системных знаний, NFR и архитектурных решений. Аналитик дополняет продуктовые и интеграционные требования; на стыке команд в PI оформляет контракты API, границы сервисов и сквозные интеграционные сценарии — см. 03.01.04 Интерфейсы и интеграционные взаимодействия, 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf). Enabler Features/Stories оформляют PM и Architect; аналитик связывает их с бизнес-целями — см. 02.03.01 Классификация требований (БТ, ФТ, НФТ).

Аналитик в SAFe — полноправный член команды (team member), не «подмножество Developers». На программе или портфеле может работать как BA или SA в составе ART или портфельной группы.

2.3. LeSS и LeSS Huge

LeSS — минималистичное масштабирование Scrum: меньше ролей, артефактов и правил.

  • LeSS (до 8 команд) — один PO, один Product Backlog, один Definition of Done (DoD).
  • LeSS Huge (более 8 команд) — Requirement Areas с APO при одном общем PO и едином Product Backlog.

LeSS (базовая конфигурация):

flowchart TD
    subgraph "LeSS"
        PO["Product Owner"] --> PB["Единый Product Backlog"]
        PB --> T1["Команда 1"]
        PB --> T2["Команда 2"]
        PB --> T3["Команда 3"]
        T1 --> INC["Общий инкремент"]
        T2 --> INC
        T3 --> INC
        PBR["Overall PBR"] --> PB
    end

LeSS Huge:

flowchart TD
    PO["Product Owner\n(единый приоритет)"] --> PB["Единый Product Backlog"]
    PB --> RA1["Requirement Area 1\n(APO 1)"]
    PB --> RA2["Requirement Area 2\n(APO 2)"]
    RA1 --> C1["Команды области 1"]
    RA2 --> C2["Команды области 2"]
    C1 --> INC["Общий инкремент"]
    C2 --> INC
    OPBR["Overall PBR"] --> PB

Области — логическое деление ответственности APO, а не параллельные product backlog'и.

Артефакты LeSS:

  • PBI — единственный тип; обычно User Story. Уровней «эпик/фича» нет: крупные PBI живут в том же бэклоге и дробятся по мере приближения к реализации.
  • Enabler-работа — те же PBI с явной пометкой; приоритизирует PO.
  • DoD — единый для всех команд.
  • DoR для крупного PBI — прозрачность для любой команды, границы, зависимости, AC-черновик; без отдельного «feature layer» формальность ложится на Overall PBR.
  • Формат спецификации — User Story или Use Case по контексту; при нескольких командах на смежном функционале выбор формата — см. 04.03 Use Case vs User Story — выбор подхода.

2.4. Сравнение работы аналитика

АспектSAFeLeSS
Масштаб и структураPortfolio → Large Solution → Program → Team (Essential — Program + Team). PM, Architect, Epic Owner.Один PO, единый бэклог; LeSS Huge — APO по областям.
АртефактыEpic → Capability → Feature → Story; Solution Intent.Единый список PBI; enabler — те же PBI.
ПланированиеPI Planning (8–12 нед.), итерации внутри PI.Общий спринт (~2 нед.), Overall Sprint Planning.
DoR / ACDoR и AC на capability, feature, story.DoR для крупного PBI; AC на story.
Роль аналитикаTeam member в ART; поддержка PM, Architect, Epic Owner, Solution Management.В команде, у PO/APO; координация на Overall PBR.
ЗависимостиPI Planning, Program Board, Scrum of Scrums.Общий бэклог, Overall PBR, «just talk», visiting.
Сквозные фичиFeature как якорь; истории нескольких команд.Крупный PBI на Overall PBR; деление между командами без типа «фича».

Выбор с позиции аналитика: SAFe даёт явные уровни трассировки и PI-ритм — удобно при регуляторике и многих стейкхолдерах; LeSS оставляет продуктовую автономию PO и меньше формальных артефактов — выше личная ответственность за ясность бэклога.

3. Как применяется в работе аналитика

3.1. Ключевые мероприятия SAFe

PI Planning — двухдневное событие раз в PI. PM представляет фичи; аналитики помогают PO и командам дробить их, выявлять риски и зависимости. Крупные сессии требуют фасилитации — см. 09.02 Проведение эффективных встреч и воркшопов, 02.02.02 Воркшопы, фасилитация и совместные сессии.

Минимальный набор выходов аналитика после PI Planning:

  1. Истории, готовые к итерации — DoR выполнен: понятный объём, AC, нет блокирующих неизвестных; enabler-истории, без которых не стартуют пользовательские.
  2. Зависимости на Program Board — кто от кого ждёт (API, данные, UI-компонент); срок внутри PI; владелец со стороны требований.
  3. Риски по формулировкам — неоднозначные AC, расхождение feature AC и story AC, NFR без метрик; зафиксированы для Inspect & Adapt.

Program Board и cross-team dependencies. На PI Planning команды выстраивают зависимости на Program Board (физическая или цифровая доска PI). Аналитик — не владелец доски (это RTE/Scrum Master), но инициатор и уточняющий записей: формулирует, что именно блокирует (какой контракт, какие данные, какой сценарий), связывает стрелки с конкретными story/feature и ведёт в инструменте трассировку — см. 02.05.01 Управление зависимостями между требованиями. Артефакт живёт в Confluence/Jira/MIRO до конца PI и обновляется на Scrum of Scrums.

Backlog Refinement — непрерывно; аналитик доводит capabilities/features до готовых историй совместно с UX, архитекторами и тестировщиками.

System Demo, Inspect & Adapt — проверка инкремента и ретроспектива программы; аналитик приносит данные о дефектах в требованиях, rework и «откатах» приоритетов — см. 08.01 Метрики и KPI процесса анализа.

3.2. Трассировка и каскад приоритетов в SAFe

SAFe подчёркивает сквозную прослеживаемость: Epic → Capability → Feature → Story → тесты. Аналитик обеспечивает связь в инструменте и матрицу для регулируемых отраслей — 02.03.04 Трассировка требований (концепция), шаблон — 10.01.15 Шаблон матрицы трассировки.

Когда приоритет меняется mid-PI — фича опускается или enabler/story уже в работе — аналитик:

3.3. Роль аналитика в LeSS

LeSS не вводит роль аналитика; проработка требований ложится на команды и PO. Аналитик работает:

  • в команде — истории своей команды;
  • в поддержку PO/APO — декомпозиция крупных PBI, DoR, прозрачность бэклога;
  • на Overall PBR — координация многокомандного refinement без дублирования.

Ключевые мероприятия:

  • Overall Sprint Planning (2 части): в части 1 PO представляет приоритеты, команды выбирают PBI; в части 2 команды планируют автономно — аналитик переключается между командами при сквозных PBI.
  • Overall PBR — доводит сложные PBI до прозрачности для любой команды.
  • Overall Sprint Review / Retrospective — обратная связь стейкхолдеров и проблемы качества требований между командами.

LeSS Huge. Общий PO задаёт приоритеты; APO — за PBI своей области. Аналитик на стыке областей работает на Overall PBR и visiting: согласует сквозные PBI, границы областей, интеграционные договорённости.

Координация без Program Board. Команды синхронизируются через общий бэклог, Overall Planning/PBR, прямое общение и visiting. Аналитик инициирует стыковки для сквозных историй и фиксирует договорённости лёгкими моделями — 03.01.02 Моделирование контекста системы (Context Diagram).

3.4. Практика, специфичная для масштаба

Базовые практики refinement, AC и planning — в 05.02 Scrum и Kanban (аналитик в Agile); на масштабе добавьте:

  1. Держите несколько уровней одновременно — capability/feature/PBI и story; проверяйте, что AC верхнего уровня не противоречат story AC.
  2. Program Board / visiting — не опция. Сквозная работа без явной фиксации зависимостей разъезжается к середине PI или спринта.
  3. DoR до planning, AC до done — в SAFe отдельно для feature и story; в LeSS — для крупного PBI до Overall Sprint Planning.
  4. Документируйте для сменяемости команд — в LeSS любая команда должна взять PBI с верха бэклога; ADR-подобные решения и карта компетенций — 03.01.03 Декомпозиция системы на подсистемы и модули, 09.05 Наставничество и передача знаний.
  5. Интеграционные контракты до старта параллельной разработки — особенно в SAFe с несколькими ART; черновик OpenAPI/AsyncAPI на PI Planning снимает блокеры Program Board.

Ритм PI не отменяет непрерывную поставку внутри инкремента — мост к 05.04 DevOps и непрерывная поставка — влияние на анализ.

Подробнее: WSJF — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано), User Story — 04.02 Пользовательские истории (User Stories) и Job Stories, Vision — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

4. Типовые ошибки и ограничения

  1. Путать роли PM и аналитика на Program. Детализация Program Backlog и представление фич на PI — зона Product Management; аналитик готовит и уточняет, не подменяет PM.
  2. Считать Epic Owner «ролью аналитика по умолчанию». Epic Owner назначается явно; BA может его поддерживать, но не является им автоматически.
  3. Игнорировать конфигурацию SAFe. В Essential не ждите Portfolio-церемоний; в Full с несколькими ART не пропускайте уровень Capability — иначе разрыв «эпик → feature».
  4. В LeSS полагаться только на самоорганизацию. Без Overall PBR, visiting и лёгких моделей сквозные истории разъезжаются.
  5. Размывать границу требований и архитектуры. Solution Intent и enabler — зона Architect/PM; аналитик связывает, не подменяет архитектурное решение — 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая).
  6. Недооценивать трассировку в регулируемой среде. Матрица и инспекции требований до релиза PI — 08.04 Рецензирование и инспекции (техники Фейгана); отраслевые и регуляторные требования учитываются отдельно при проектировании прослеживаемости.
  7. Забыть про DoR. Истории без DoR на PI Planning или Overall Sprint Planning создают скрытый backlog внутри итерации — rework растёт быстрее, чем в однокомандном Scrum.

Связи с другими разделами базы

Источники и дополнительные материалы

  • Книги и стандарты:
    • Dean Leffingwell. «SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework» — практическое введение; концепции уровней и PI устойчивы в SAFe 5–6.
    • Richard Knaster, Dean Leffingwell. «SAFe 5.0 Reference Guide» — справочник по ролям и артефактам.
    • Craig Larman, Bas Vodde. «Large-Scale Scrum: More with LeSS» — канон LeSS и LeSS Huge.
    • Craig Larman, Bas Vodde. «Practices for Scaling Lean & Agile Development» — системное масштабирование.
  • Официальные ресурсы:
  • Примечание: Scrum Nexus и Spotify Tribes — отдельные подходы к масштабированию; Nexus ближе к LeSS по минимализму. Кейсы John Deere (SAFe) и Ericsson (LeSS) цитируются в материалах scaledagile.com и less.works без единого канонического URL.