SAFe comparison — RENAR на ART

Mapping RENAR (стандарт требований) на SAFe 6.0 (стандарт scaled agile координации). Документы совместимы, но имеют разный scope: SAFe нормирует как команды координируют работу на масштабе; RENAR нормирует что собой представляет требование и как оно верифицируется. Эта глава — для команд, которые уже работают по SAFe (Andersen Stack — типичный пример) и хотят сохранить SAFe ceremonies, добавив RENAR-артефакты как первичный источник истины о требованиях.

Предпосылки: знакомство с RENAR Core (5 правил, ADAPT, 2 QG) и базовой SAFe 6.0 терминологией (Epic / Capability / Feature / Story, WSJF, PI, ART).

1. Scope: что нормирует RENAR, что — SAFe

RENAR и SAFe пересекаются на уровне артефактов работы (Feature, Story), но решают разные задачи.

Аспект	SAFe 6.0	RENAR
Тип стандарта	Scaled Agile coordination framework	Стандарт инженерии требований
Первичный артефакт	Epic / Capability / Feature / Story	ТЗ → ADAPT → BR → SR → SPEC → TC
Что нормирует	Cadence, roles, ceremonies, flow	Schema, lifecycle, verifiability, drift control
Substrate	Tool-agnostic (Jira / Rally / ADO / др.)	Substrate-agnostic (capabilities V1-V6)
Quality gates	Definition of Done на уровне Feature	QG-0 (готовность к старту) + QG-2 (verified)
AI-нативность	Не нормирует AI workflow	AI как first-class actor (адверсариальная проверка, eval, judge-models)

Ключевой принцип: SAFe и RENAR совместимы. SAFe говорит «как координировать команды на ART», RENAR — «что должно быть истинно про каждое требование, чтобы оно считалось verified». Feature в SAFe ≡ SR в RENAR — это один и тот же артефакт, описанный с разных сторон.

2. Главная таблица соответствия

SAFe artefact	RENAR artefact	Где живёт	Owner	Acceptance criteria
Strategic Theme	(вне scope RENAR — корпоративная стратегия)	стратегические доки	Executive	бизнес-уровень
Portfolio Epic	Группа BR одной системы	`<system>.req/br/` aggregated	Lean Portfolio Mgmt	Все BR в группе со статусом `verified`
Capability	BR подсистемы (если у подсистемы свой stakeholder)	`<subsystem>.req/br/`	Solution Architect	Все BR подсистемы `verified`
Program Epic	Опционально — крупная инициатива внутри ART, aggregated SR	`<system>.req/sr/` aggregated	Product Manager	Заданная outcome metric достигнута
Feature	SR (или связанная группа SR)	`<subsystem>.req/sr/`	Product Owner	TC из `verified-by` зелёные на текущей `requirement-version` (QG-2)
Story	TR (Task Requirement)	`<subsystem>.req/tr/` или KAI / TAUSIK DB	Команда	Все AC выполнены, evidence зафиксирован, code merged
Enabler Epic	SPEC-AI / SPEC-ARCH / SPEC-OPS	`<system>.req/spec/`	Architect	Eval-метрики в пределах thresholds; baseline зафиксирован
Spike	TR с `level: research` + Decision в KAI Decisions	`<subsystem>.req/tr/` + decision log	Команда	Decision записан и связан с originating SR
Defect	TR + ссылка на нарушенный SR через `defect-of`	TAUSIK DB + `linked_defects` в SR	Команда	Negative TC проходит, regression test добавлен

Запрещённые соответствия: INT-SR — устаревший термин (§3.3 Terms), заменён SR с constrained-by: [SPEC-INT-N]. См. §6 ниже.

3. WSJF prioritization для RENAR

SAFe использует WSJF (Weighted Shortest Job First) как приоритизационный framework. RENAR адаптирует его для уровня BR / SR.

3.1 Формула

WSJF = (User-Business Value + Time Criticality + Risk Reduction & Opportunity Enablement) / Job Size

Каждый компонент оценивается по шкале 1-20 (modified Fibonacci); WSJF — относительная метрика, имеет смысл только при сравнении BR/SR внутри одного backlog’а.

3.2 Расширение frontmatter BR

---
id: BR-12
title: "Сократить время регистрации сотрудников до < 2 минут"
status: approved
priority: must
prioritization:
  framework: WSJF
  components:
    user-business-value: 10
    time-criticality: 8
    risk-reduction-opportunity: 6
    job-size: 5
  wsjf-score: 4.8                # auto-calculated: (10+8+6)/5
  prioritized-at: 2026-05-03
  prioritized-by: "@product-owner"
---

Поле prioritization — опциональное в Core RENAR, обязательное на ART, который применяет SAFe.

3.3 Когда применяется

Обязательно для BR с priority: must в проектах, координируемых через ART.
Рекомендуется для всех BR в backlog’е, который проходит PI Planning.
Не применяется для SR — SR наследует приоритет родительского BR. Перешафливание SR внутри одного BR — задача Product Owner на decomposition, не WSJF.

3.4 Альтернативы

Если команда не использует SAFe / WSJF — RENAR допускает другие frameworks:

MoSCoW (Must / Should / Could / Won’t) — простейший, для маленьких проектов. Уже есть как priority enum в RENAR Core.
RICE (Reach × Impact × Confidence / Effort) — для product-driven команд (типично B2C).

RENAR нормирует поле и его schema; выбор framework — на проекте. См. также reference/02-schemas.md для допустимых значений prioritization.framework.

4. PI Planning интеграция

4.1 Что такое PI

Program Increment (PI) — фиксированный отрезок времени (обычно 8-12 недель) в SAFe, в течение которого ART коммитится на набор Features из общего backlog’а. PI Planning — двух- или трёхдневный event перед каждым PI, где команды совместно фиксируют commitment.

4.2 Где RENAR-артефакты попадают в PI flow

[До PI Planning]                  [PI Planning event]                [Iteration 1..N]                 [System Demo / I&A]
       │                                  │                                  │                                │
       ▼                                  ▼                                  ▼                                ▼
 Backlog: SR со статусом      Команды берут SR              SR → TR в трекере             SR со статусом
 approved, WSJF-               (= Features) на следующий     Реализация Story              verified
 prioritized                   PI                            TC прогон на каждом
       │                       Декомпозиция SR → TR          merge
       │                       Identify cross-team           QG-2 проверка
       │                       dependencies через            на завершении SR
       │                       SPEC-INT
       │                                                                                  RENAR метрики feed
       └──────────────────────────────────────────────────────────────────────────────►  в SAFe Inspect & Adapt

4.3 Артефакты RENAR в каждой ceremony

SAFe ceremony	RENAR input	RENAR output
Backlog refinement	BR / SR со статусом `proposed` или `approved`	Уточнённый ADAPT, обновлённый WSJF
PI Planning	WSJF-sorted SR backlog, ADAPT-доки	Commitment на SR в PI; SPEC-INT для cross-team
Iteration Planning	SR + декомпозированные TR	TR в `in-progress`
System Demo	SR со статусом `verified`	Evidence из TC last-run
Inspect & Adapt	Метрики RDLT, Coverage Velocity, Hallucination Rate	Корректировки backlog / процесса

5. ART координация и роли

5.1 SAFe роли ↔ RENAR ответственности

SAFe role	RENAR ответственность
RTE (Release Train Engineer)	Координация cross-team dependencies через SPEC-INT; владелец PI Objectives ↔ RENAR метрик mapping
Product Manager	Owner портфельных Epic = групп BR на уровне системы
Product Owner	Owner Feature = SR на уровне команды; accountable за QG-0 (готовность к старту) и QG-2 (verified)
System Architect	Owner SPEC-* (особенно SPEC-ARCH, SPEC-INT); consulted при декомпозиции BR → SR
Tech Lead	Accountable за QG-2 на уровне SR; владеет TR backlog’ом команды
Business Owner	Approver BR / ADAPT с бизнес-стороны
Solution Architect	Owner BR на уровне подсистемы (когда подсистема имеет свой stakeholder)
Scrum Master	Owner ceremonies; не владеет RENAR-артефактами напрямую

5.2 Cross-team координация

В типичной SAFe-организации с несколькими командами в одном ART:

Каждая команда владеет своими SR / TR в <subsystem>.req/.
RTE / Solution Architect владеют SPEC-INT в <system>.req/spec/ — общими integration contracts между подсистемами.
Изменение SPEC-INT требует cross-team согласования (QG-0 от всех затронутых команд).

Правило: ART-уровневые роли (RTE) не редактируют SR в подсистемах напрямую. Координация — через SPEC-INT, который явно constrained-by для каждой затронутой SR.

6. Cross-team dependencies через SPEC-INT

Когда Feature в одной подсистеме блокирует / зависит от другой:

6.1 SR с зависимостью

# В <subsystem-a>.req/sr/SR-05.md
---
id: SR-05
parent: BR-12
title: "Регистрация пользователя через корпоративный email"
status: approved
constrained-by:
  - id: SPEC-INT-01
    repo: "system.req"
    file: "spec/SPEC-INT-01-auth-handshake.md"
    version: 1.2
verified-by:
  - TC-23
  - TC-24
---

6.2 SPEC-INT как контракт

# В <system>.req/spec/SPEC-INT-01-auth-handshake.md
---
id: SPEC-INT-01
type: SPEC-INT
title: "Auth handshake между Subsystem A и Subsystem B"
version: 1.2
participants:
  - subsystem: "subsystem-a"
    role: "client"
  - subsystem: "subsystem-b"
    role: "provider"
status: approved
verified-by:
  - TC-INT-01    # contract test
---

6.3 Breaking changes в SPEC-INT

Любое изменение SPEC-INT.version с breaking-семантикой (§3.11 Drift классы) требует:

ADAPT-уровневое обсуждение (зачем меняем).
Согласование от всех participants (QG-0 от каждой команды).
Migration plan для existing implementors (как старые SR останутся valid или будут адаптированы).

RTE обязан проверять SPEC-INT consistency между подсистемами регулярно (обычно раз в спринт) — это часть Inspect & Adapt и feed в conformance self-assessment (§14 Conformance).

7. Definition of Done на каждом уровне иерархии

DoD — формальные условия, проверяемые автоматически (substrate hooks). На каждом уровне иерархии — свой DoD.

Level	RENAR artefact	DoD criterion
Strategic Theme	—	(вне scope RENAR)
Portfolio Epic	Группа BR	Все BR в группе → `verified`, KPI impact подтверждён через outcome metric
Capability	BR подсистемы	Все BR со статусом `verified`; outcome metric измерен
Feature	SR	QG-2 passed: все TC из `verified-by` имеют `last-run.result = pass` на текущей `requirement-version`
Story	TR	Все AC выполнены, evidence зафиксирован, code merged, automated test exists
Enabler	SPEC-AI / SPEC-ARCH / SPEC-OPS	Eval-runs прошли пороги (для SPEC-AI); baseline зафиксирован (для всех)

Ключевое: на уровне Feature DoD в SAFe совпадает с QG-2 в RENAR. Нет двух разных «definition of done» — это один и тот же gate, описанный с разных сторон.

8. Built-in Quality ↔ RENAR mechanisms

SAFe принцип Built-in Quality: качество встроено в процесс, не ad-hoc. RENAR реализует Built-in Quality через нормативные механизмы:

SAFe Built-in Quality practice	RENAR mechanism
Continuous Integration	Substrate hooks + CI на каждый change в требованиях (§14 Conformance); capability V6 (drift detection)
Test-First	TC создаются до реализации; QG-0 требует `verified-by` пустым только при `status: proposed`, не `approved`
Refactoring	Continuous reconciliation hook (§7.5 ADAPT); обнаруживает дрейф между требованиями и кодом
Pairing / Mobbing	AI-генератор + AI-критик (§4.2 Roles) — pair generation/review как нормативная роль
Definition of Done	QG-2 как формальный gate, проверяемый автоматически (§10 Lifecycle и QG)
Version Control	Capability V1 (versioned content addressing) — substrate-agnostic
Automation	Capability V2-V6 — все верификации автоматизируемы

RENAR не предписывает instrument (Jenkins / GitLab CI / GitHub Actions / Tekton) — только что должно проверяться (capability), не как.

9. RACI lifecycle артефакта (с SAFe ролями)

Полный жизненный цикл RENAR-артефакта с распределением ответственности по SAFe ролям.

Активность	Responsible	Accountable	Consulted	Informed
Импорт ТЗ	AI-агент	System Architect	Business Owner	Команда, RTE
Декомпозиция ТЗ → ADAPT	AI-генератор	System Architect	Stakeholder, AI-критик	RTE, Команда
Декомпозиция → BR	AI-генератор	Product Owner	Business Owner, AI-критик	RTE, Команда
WSJF prioritization	Product Manager	Product Owner	RTE, Stakeholder	Команда
Декомпозиция BR → SR	AI-генератор	System Architect	AI-критик	Команда, RTE
Декомпозиция SR → SPEC-*	System Architect	System Architect	AI-критик, Tech Lead	Команда
Генерация TC	AI-агент	Test Architect	—	Команда
QG-0 approval	System Architect	Tech Lead	AI-критик	Business Owner, RTE
Выбор SR на PI	Product Owner	RTE	Команда (capacity)	Stakeholder
Декомпозиция SR → TR	Команда	Product Owner	Tech Lead	RTE
Реализация TR	Разработчик	Tech Lead	—	Команда
Прогон TC (automated)	Substrate hook	—	—	Команда
QG-2 (SR verified)	System Architect	Tech Lead	—	Business Owner, RTE
System Demo	Команда + RTE	Product Owner	Stakeholder	RTE, Executive
Delta-ТЗ approval	System Architect + Stakeholder	Product Owner	AI-impact analysis, RTE	Команда
Spot-check 5 TC (audit)	System Architect	—	—	RTE
Reconciliation MR	AI-агент-reconciler	System Architect	—	Команда

10. PI Objectives ↔ RENAR метрики

PI Objectives — SMART outcomes на квартал. RENAR-метрики (§13 Metrics, reference/02-schemas.md) feed в PI Objectives:

PI Objective (example)	RENAR метрика
«Сократить время от подписания ТЗ до первого commit’а до < 2 дней»	RDLT (Requirement Decomposition Lead Time)
«Достичь Coverage Velocity ≥ 60% в спринт»	Coverage Velocity (% SR с `status: verified` per sprint)
«Снизить Hallucination Rate в новых требованиях до < 2%»	Hallucination Rate (% AI-сгенерированных утверждений, отклонённых на review)
«0 disputed requirements на acceptance в этом PI»	Dispute Rate at Acceptance
«Drift detection — все SR consistent с code в течение 24 часов после merge»	Drift Lag (capability V6)

Это превращает RENAR из «standard for documents» в measurable contribution к ART success. Метрики feed автоматически в Inspect & Adapt; RTE использует их при ретроспективе на завершении PI.

11. Что из SAFe оставить, что заменить

Для команд, переходящих на RENAR с уже работающего SAFe-процесса:

11.1 Оставить как есть

Cadence (PI, Iterations) — RENAR не нормирует время; используйте свой ритм.
Ceremonies (PI Planning, System Demo, I&A, Daily Standup) — RENAR-артефакты прозрачно вписываются в эти events.
WSJF — оставить для приоритизации BR / SR; вписывается в prioritization.framework: WSJF.
ART, RTE, Scrum Master — структура и роли сохраняются.
PI Objectives — оставить; mapping на RENAR-метрики (§10) делает их измеримыми.

11.2 Заменить RENAR-эквивалентом

Feature description в Jira / Rally / ADO → SR со полным frontmatter в <subsystem>.req/sr/. Tracker-запись становится зеркалом RENAR-артефакта, не первичным источником.
Acceptance criteria в Feature → verified-by: [TC-NN] с автоматически проверяемыми TC.
Definition of Done на Feature → QG-2 (нет двух разных DoD — это один gate).
Integration agreements между командами → SPEC-INT (заменяет INT-SR из старых SAFe-имплементаций).
Architecture Decision Records (ADR) → SPEC-ARCH / SPEC-AI / SPEC-OPS (один из 9 типов SPEC, §3.4).

11.3 Добавить (новое в RENAR)

ADAPT — bridge artefact между ТЗ и иерархией требований. В SAFe нет прямого аналога; реализуется как обязательный этап перед декомпозицией в BR.
AI-критик роль — адверсариальная проверка AI-генерации. В SAFe не нормирована, в RENAR Core — обязательна для всех AI-сгенерированных артефактов.
Capability V6 (drift detection) — непрерывная сверка требований с реализацией. В SAFe — manual reconciliation, в RENAR — нормативный механизм.

12. Negative: чего эта глава не утверждает

RENAR — не замена SAFe. RENAR нормирует требования, SAFe — координацию работы. Команда может работать по RENAR без SAFe (маленький проект, одна команда) или с SAFe (Andersen Stack, масштаб ART).
RENAR — не стандарт планирования. Cadence, capacity planning, velocity tracking — все за пределами scope. RENAR говорит «что должно быть истинно про требование», не «когда команда должна его доделать».
RENAR не запрещает другие frameworks. WSJF, MoSCoW, RICE — все совместимы. RENAR фиксирует поле prioritization.framework, не выбор framework’а.
RENAR не нормирует Jira / Rally / ADO workflow. Tracker-уровневая реализация — substrate detail; нормативный источник — <subsystem>.req/.
RENAR не предписывает PI как обязательный. Команда может работать по непрерывному flow без PI; в этом случае разделы 4 и 10 этой главы становятся informative.

13. Open questions

Не закрыты в этой главе и подлежат уточнению:

Estimation: WSJF использует Job Size как relative effort (1-20). Как AI-агент оценивает Job Size? Нужна эвристика на основе количества AC, complexity TC, code surface.
Запрещать ли priority: must без WSJF score (в проектах, формально применяющих SAFe)? Или WSJF опционален?
На каком уровне иерархии останавливается требование = Feature? Иногда крупный SR ≈ Capability, иногда мелкий SR ≈ Story. Нужна эвристика разделения.
PI Objectives как RENAR-артефакт: создавать pi-objectives/ папку в <system>.req/ или это вне scope RENAR?
Inspect & Adapt: метрики RENAR feed автоматически или manual extraction RTE’ом?

См. также research/08-safe-mapping.md — исследовательский draft, на основе которого построена эта глава.

14. Связь с другими главами

00-quickstart — базовый цикл RENAR без SAFe-надстройки.
01-walkthrough — полный example на small-scale проекте (без PI Planning).
reference/01-glossary — точная семантика BR / SR / SPEC / TR / TC.
reference/02-schemas — frontmatter schemas, включая prioritization.
standard/03-terms — нормативные определения; mapping на SAFe закреплён в §3.13.
standard/08-specifications — closed list 9 типов SPEC, включая SPEC-INT.