• масштабирование agile от уровня команд на уровень управления компанией.
• Совместная согласованная работа нескольких команд в проектах.

Основа - четыре области знаний: гибкая (agile) разработка ПО, бережливая (lean) разработка продукции, системное мышление и DevOps.

"Стандартные" agile-фреймворки (Scrum, Kanban, XP ...) акцентируются на процессах работы внутри команд. Для стартапов или проектов, над которыми работает одна-две команды, это прекрасно подходит. Но когда речь заходит об управлении разработкой более-менее крупных продуктов и, тем более, продуктовым портфелем, для масштабирования agile-философии нужны дополнительные методики. Ведь когда над продуктом работает несколько команд, необходимо, как минимум, синхронизировать их работу. Это и есть задача "минимум" фреймворка SAFe (и ему подобных). А задача "максимум" - выстроить работу всего предприятия по идеологии lean-agile.

Ядро SAFe, как и любой agile-методологии - это определенный mindset, то есть образ мышления.
Это критически важно.
Без поддержки этого mindset, говорить о том, что на предприятии внедрен SAFе, бессмысленно. Если команда использует kanban-доску просто для перевешивания тикетов - это еще не значит, что она работает по Kanban. Точно так же, если на предприятии есть Agile Release Train (один из артефактов SAFe), но при этом не синхронизируется процесс планирования внутри ART, нет доставки изменений после каждого Program Increment (еще один артефакт SAFe) - это не значит, что на предприятии внедрен SAFe.
Для полноценного внедрения SAFe прежде всего необходимо внедрить культуру мышления. А так как речь идет об управлении предприятием, то в первую очередь эта культура мышления должна быть понята и принята руководством предприятия.

Поэтому перед описанием атрефактов и техник, применяемых во фреймворке, стоит познакомиться с ценностями и принципами SAFe, то есть с его mindset:

Речь идет о согласованности работы всех команд с бизнес-целями предприятия.
Каждый сотрудник понимает текущее состояние бизнеса, цели и направление движения для их достижения.
Регулярная синхронизация людей и действий.
Потоки информации движутся как вниз, так и вверх.

Выравнивание начинается с прозрачного описания Портфеля продуктов, ценностей (values) потоков их создания (value stream), стратегии по каждому продукту из Портфеля, принципов инвестирования.
Это информация абсолютно открыта и доносится до каждого сотрудника организации. Все работы в Backlog-ах формируются и приоритезируются согласно этому описанию. Обеспечивается этот процесс владельцем портфеля, Solution-менеджерами, Product-менеджерами и Product Owner-ами.

Но, что важно, Alignment не поощряет жесткое управление и контроль "сверху вниз". Наоборот, поощряется максимальная автономность и децентрализация принятия решений на тех уровнях, где ценности реализуются.

Собственно, это пересекается с одним из принципов Agile: "Continuous attention to technical excellence and good design enhances agility".

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

Все команды (не только производственные) разделяют принцип встроенного качества.

SAFe определяет пять аспектов встроенного качества:

В SAFe встраивание в поток предполагает обязательно использование подхода "Test-First" и Continuous Delivery Pipeline (конвейера непрерывной доставки, CDP).

Test-First - подход, при котором основная часть тестов выполняются не после реализации функциональности, а на как можно более ранних этапах. Плюс, используется несколько уровней тестирования, которые обеспечиваются следующими техниками: Test-Driven Development (TDD), Behavior-Driven Development (BDD) и Lean-UX.

TDD - это еще из экстремального программирования (XP): создание модульных тестов до написания кода.
BDD - это аналогичная штука, но уже на уровне Story и Feature: приемочные тесты создаются так же на самом раннем этапе. Причем речь идет не только о функциональных требованиях, но и о Nonfunctional Requirements (NFRs).
Разница с традиционным подходом к тестированию показана на рисунке:

При работе в рамках потока, тесты должны выполняться максимально быстро, поэтому:
Во-первых, тесты должны быть автоматизированы
Во-вторых, должна создаваться сбалансированная пирамида тестирования: от большого количества быстрых тестов уровня Story до гораздо меньшего количества крупных и дорогих end-to-end тестов:

Lean UX - отдельная достаточно большая тема.
Вкратце - это один из инструментов Product Manager-а, предоставляющий возможность быстрого тестирования бизнес-гипотез (что является одной из главных задач Product Manager-а).

На рисунке показано, как изменения кода проходят несколько стадий тестирования перед попаданием в Production:

Test double - это всяческие техники ускорения тестов, типа использования подготовленных данных в in-memory db вместо обращения к реальной базе и т.п.
Если тестов много и их прогон занимает продолжительное время, создается промежуточный этап с набором тестов, в который выносятся наиболее критичные проверки. Этот этап (smoke tests) позволяет быстро определить ошибки в критических функциях, прежде чем переходить к другим этапам тестирования.

От качества архитектуры системы зависит, насколько хорошо она сможет поддерживать текущие и будущие потребности бизнеса, насколько просто будет реализовывать требования и тестировать продукт, насколько он будет удовлетворять требованиям NFR.

Для выбора наиболее подходящих архитектурных решений SAFe предлагает использовать Set-Based Design (SBD):
На начальных этапах, как правило, есть дефицит информации о требованиях и знаний, поэтому архитектурные решения принимаются только после того, как будет накоплено необходимое количество знаний и данных. До этого момента поддерживается несколько вариантов дизайна. По мере накопления знаний, эти варианты отсеиваются, пока не останется один.
На рисунке показано сравнение Set-Based Design с Point-Based Desing:

Затраты на поддержку Set-Based Design, конечно, выше, чем на Set-Based Design, но это с лихвой окупается тем, что система имеет более качественный дизайн, который упрощает дальнейшую разработку/тестирование/сопровождение и уменьшает TTM.
Для сравнительной оценки вариантов дизайна можно использовать, например, такой подход:
Выбираются несколько показателей (стоимость разработки, производительность, надежность, стоимость поддержки, технические риски и т.п.), каждому показателю присваивается вес. Варианты оцениваются по этим показателям с учетом весов.

Из инженерных практик: обязательное использование принципов SOLID, моделирование/прототипирование, использование паттернов проектирования.

Статья в процессе, это пока только самое начало...

• Jira Align https://www.atlassian.com/ru/software/jira/align - инструмент для планирования. Поддержка ряда методологий масштабирования agile, в то числе SAFe (https://www.atlassian.com/ru/software/jira/align/safe).
• Плагин для джиры, где реализован в т.ч. этот фреймворк: https://marketplace.atlassian.com/apps/1212259/bigpicture-project-management-ppm?hosting=server&tab=overview
• Другие плагины для джиры для масштабирования agile в рамках компании: https://marketplace.atlassian.com/categories/agile-at-scale