Учебное пособие по SAFe (Scaled Agile Framework)
Что такое SAFe (масштабируемая Agile Framework)?
Масштабируемая гибкая структура (SAFe) — это свободно доступная онлайн-база знаний, которая позволяет применять гибкие методы бережливого производства на уровне предприятия. Он обеспечивает простой и легкий опыт разработки программного обеспечения. Это набор организационных структур и шаблонов рабочих процессов, призванных помочь предприятиям в масштабировании бережливых и гибких практик. Он разделен на три сегмента: команда, программа и портфолио.
Сейф структура позволяет команде,
- Внедрение программного обеспечения и систем Lean-Agile на уровне предприятия
- Он основан на принципах Lean и Agile.
- Он дает подробное руководство по работе над портфелем, потоком создания ценности, программой и командой предприятия.
- Он предназначен для удовлетворения потребностей всех заинтересованных сторон внутри организации.
SAFe был впервые разработан в этой области и был разработан в Дин Леффингвеллкниги и блог. Версия 1.0 — первый официальный выпуск в 2011 году. Последняя версия — 4.6 — была выпущена в октябре 2018 года. Она содержит рекомендации по работе на уровнях корпоративного портфеля, потока создания ценности, программы и команды.
Зачем использовать SAFe Agile Framework
Это простая и легкая структура, но она способна удовлетворить потребности крупных потоков создания ценности и разработки сложных систем. Внедрив гибкую структуру SAFe, вы получите следующие преимущества:

- Производительность увеличилась by 20 - 50%
- Качество увеличился более чем 50%
- Пора торговать быстрее чем 30-75%
- Увеличенный вовлечения сотрудников и удовлетворение от работы.
Подробная схема структуры доступна на сайте .. Он показывает все ключевые роли, виды деятельности, результаты и потоки. Он также служит средством навигации по остальной части сайта.
На изображении ниже показано, как работает гибкий процесс. Эпосы — это большой объем произведений, который в свою очередь разбивается на несколько более мелких историй или подэпосов. Эти подэпопеи выделяются команде как история. Затем каждая команда соответственно работает над этими историями или функциями программного обеспечения.

Когда использовать Scaled Agile Framework
- Когда команда заинтересована в последовательном внедрении гибкого подхода в более крупных многокомандных программах и портфелях.
- Когда несколько команд используют свой собственный путь внедрения Agile, но регулярно сталкиваются с препятствиями, задержками и неудачами.
- Когда команды хотят работать независимо.
- Если вы хотите масштабировать Agile по всей организации, но не знаете, какие новые роли могут потребоваться или какие существующие роли (например, руководство) необходимо изменить и как.
- Когда вы пытались масштабировать Agile в своей организации, но изо всех сил пытались достичь единой или последовательной стратегии во всех бизнес-отделах, от портфолио до уровня программы и команды.
- Когда организации необходимо сократить время разработки продукта и она хочет знать, как другим компаниям удалось масштабировать Agile с помощью SAFe.
Насколько отличается от других Agile-практик
Теперь в этом руководстве Scaled Agile Framework давайте посмотрим, чем Scaled Agile Framework отличается от других гибких практик.
- Он общедоступен и бесплатен для использования.
- Доступен в очень доступной и удобной форме.
- Это легкий, практически доказанный результат и специфичный для каждого уровня.
- Он постоянно/регулярно изменяет/поддерживает наиболее часто используемые гибкие практики.
- Предлагает полезные расширения для распространенных гибких практик.
- Обосновывает гибкие практики в контексте предприятия.
- Предоставляет полную картину разработки программного обеспечения.
- Видимость или прозрачность более заметны на всех уровнях.
- Постоянная или регулярная обратная связь по качеству и улучшению.
Foundations Scaled Agile Framework

Scaled Agile Framework (SAFe): он опирается на фундамент своей
- Принципы Lean-Agile
- Главные ценности,
- Бережливое и гибкое лидерство
- Бережливое и гибкое мышление,
- Сообщества практиков (группа людей, постоянно работающих над практиками SAFe)
- Реализация 1-2-3
Принципы SAFe Lean-Agile
Эти основные принципы и ценности SAFe Agile необходимо понимать, демонстрировать и продолжать применять, чтобы получить желаемые результаты.
- Взгляните с экономической точки зрения
- Применяйте системное мышление
- Предположим изменчивость; сохранить варианты
- Создавайте постепенно с помощью быстрых интегрированных циклов обучения.
- Основывайте этапы на объективной оценке работающих систем
- Визуализируйте и ограничивайте незавершенное производство, уменьшайте размеры пакетов и управляйте длиной очередей.
- Применяйте каденцию, синхронизируйте с междоменным планированием
- Раскройте внутреннюю мотивацию работников умственного труда
- Децентрализовать принятие решений
Основные ценности SAFe Agile
Методология SAFe Agile основана на этих четырех ценностях.
Выравнивание:
- SAFe поддерживает выравнивание.
- Выравнивание начинается с,
- Стратегические темы в портфолио и
- Переходим вниз к «Видению и дорожной карте невыполненных программ», а затем
- Перемещается в журналы команд.
Встроенное качество:
- Это гарантирует, что каждая дополнительная поставка соответствует стандартам качества.
- Качество не «добавлено позже», оно встроено.
- Встроенное качество является предпосылкой бережливого производства и его обязательным условием.
Прозрачность:
- Прозрачность является фактором доверия.
- SAFe помогает предприятию достичь прозрачности на всех уровнях: руководителей, портфельных менеджеров и других заинтересованных сторон.
- Каждый может просмотреть бэклог портфолио/канбан, бэклог программы/канбан и бэклог команды/канбан.
- На каждом уровне имеется четкое понимание целей PI.
- Программы обучения имеют видимость невыполненных работ команды, а также других невыполненных программ.
- Команды и программы имеют представление о бизнесе и архитектуре Epics. Они видят, что может произойти на их пути.
Выполнение программы:
- SAFe уделяет большое внимание работающим системам и полученным результатам бизнеса.
- SAFe бесполезен, если команды не могут работать и постоянно приносить пользу.
Бережливые и гибкие лидеры
Лидеры Lean-Agile — это ученики и учителя на протяжении всей жизни. Это помогает командам создавать более совершенные системы посредством понимания и применения принципов Lean-Agile SAFe.
Основная ответственность команды как фактора влияния — внедрение, успех и постоянное улучшение разработок Lean-Agile. Для перемен и постоянного совершенствования лидеры должны пройти обучение.
Лидерам необходимо принять новый стиль руководства. Тот, который действительно расширяет возможности и вовлекает отдельных людей и команды в раскрытие своего наивысшего потенциала.
Принципы Lean-Agile-лидеров
- Возглавьте перемены
- Знай Путь; Уделяйте особое внимание непрерывному обучению
- Развивайте людей
- Вдохновляйте и согласовывайтесь с миссией; Минимизировать ограничения
- Децентрализовать принятие решений
- Раскройте внутреннюю мотивацию работников умственного труда
Бережливое и гибкое мышление
Lean-Agile-мышление представлено в двух вещах:
- SAFe Дом бережливого производства
- Agile-манифест
SAFe Дом бережливого производства:
SAFe основан на принципах и методах бережливого производства. Основываясь на этих факторах, SAFe представляет «Дом бережливости SAFe». Он вдохновлен «домом» бережливой Toyota.
Цель бережливого производства непобедима: обеспечить максимальную ценность для клиента в кратчайшие сроки с максимально возможным качеством для клиента.
На рисунке ниже поясняются цель, основные принципы и Foundation «Безопасного дома бережливости».

Agile-манифест
Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. Благодаря этой работе мы пришли к ценности:

Вот почему, несмотря на то, что элементы справа имеют ценность, мы ценим элементы слева больше.
Agile-манифест
- Наивысшим приоритетом является удовлетворение потребностей клиентов посредством непрерывной и своевременной поставки ценного программного обеспечения.
- Принимайте меняющиеся требования даже на поздних стадиях разработки. Процессы методологии Agile SAFe используют изменения на благо клиента.
- Доставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, отдавая предпочтение более коротким срокам.
- Разработчики и бизнесмены должны ежедневно работать вместе на протяжении всего проекта.
- Создавайте проекты вокруг мотивированных людей. Предоставьте им поддержку и среду, в которой они нуждаются, и доверьте им выполнение своей работы.
- Самый эффективный метод общения с командой разработчиков — это личный разговор.
- Работающее программное обеспечение является основным мерилом прогресса.
- Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп в течение неопределенного времени.
- Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
- Простота – искусство максимизировать объем невыполненной работы – имеет важное значение.
- Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
- Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.
Различные уровни в SAFE
Существует два различных типа реализации SAFe:
- Реализация SAFe 4.0
- Реализация SAFe 3.0

- В реализации SAFe 4.0 у нас есть 4 уровня: Портфель, поток создания ценности, программа и команда.
- В реализации SAFe 3.0 у нас есть 3 уровня: Портфолио, программа и команда
- 3-уровневый SAFe предназначен для небольших проектов со 100 или менее людьми. Программы, которые не требуют значительного сотрудничества.
- 4-уровневый SAFe предназначен для решений, для разработки развертывания и обслуживания программного обеспечения которых обычно требуются сотни специалистов.
Уровень команды
Роли/Команды | Мероприятия | Артефакты | ||
---|---|---|---|---|
* Гибкая команда | * Sprint Планирование | * Отставание команды | ||
* Владелец продукта | * Уход за отставанием | * Нефункциональные требования | ||
* Скрам-мастер | * Ежедневный стендап | * Цели команды PI | ||
* Исполнение | * Итерации | |||
* Sprint Демо | * Истории (Рабочее программное обеспечение) | |||
* Sprint ретроспективный | * Sprint Цели | |||
* ИП Sprints | * Встроенное качество | |||
* Шипы | ||||
* Команда Канбан |
- Все команды SAFe являются частью того или иного Agile Release Train (ART).
- Команды SAFe — это наделенные полномочиями, самоорганизующиеся, самоуправляемые, многофункциональные команды.
- Каждая команда несет равную ответственность за определение, создание и тестирование историй из своего командного бэклога в рамках итераций фиксированной длины.
- Команды планируют и выполняют двухнедельные итерации с фиксированными временными рамками в соответствии с согласованными целями итерации.
- Команды будут использовать процедуры ScrumXP/Team Kanban для предоставления высококачественных систем и создания демо-версии системы каждые две недели.
- Все различные команды ART (Agile Release Trains) создадут интегрированную и протестированную систему. Заинтересованные стороны оценят и ответят быстрой обратной связью
- Они применяют методы встроенного качества.
- В каждой команде ScrumXP будет 5–9 членов команды, что включает в себя все роли, необходимые для создания дополнительной ценности качества на каждой итерации.
- Роли ScrumXP включают в себя:
- Команда (Разработка+QA)
- Scrum Master
- Владелец продукта. И т. д..
- SAFe делит временную шкалу разработки на набор итераций в рамках PI (инкремента программы).
- Продолжительность ИП составляет от 8 до 12 недель.
- Команда будет использовать истории для повышения ценности. Владелец продукта будет иметь полномочия по созданию и принятию историй.
- Истории содержат требования Заказчика.
- Team Backlog включает истории пользователей и исполнителей, которые определяются во время PI-планирования. Когда руководство продукта представляет дорожную карту, видение и журнал невыполненной программы.
- Выявление, разработка, расстановка приоритетов, планирование, внедрение, тестирование и принятие историй являются основными требованиями управленческой работы на уровне команды.
- Каждая итерация обеспечивает:
- Ценный прирост новой функциональности
- Достигайте с помощью постоянно повторяющегося шаблона
- Спланируйте итерацию
- Примите участие в какой-либо функциональности
- Выполните итерацию, создав и протестировав истории.
- Демонстрация нового функционала
- ретроспективный
- Повторите для следующей итерации
- Команды также поддерживают демонстрацию системы в конце каждой итерации. что является критической точкой интеграции для ART.
- Более крупные потоки создания ценности будут иметь несколько ART.
- Итерации инноваций и планирования (IP) дают командам возможность для инноваций и исследований.
Уровень программы
Роли/Команды | Мероприятия | Артефакты | ||
---|---|---|---|---|
* DevOps | * PI (приращение программы) планирование | * Зрение | ||
* Системная команда | * Демонстрации системы | * Дорожная карта | ||
* Управление релизами | * Осмотрите и примите мастерскую | * Метрики | ||
* Управление продуктом | * Archiтектурная взлетно-посадочная полоса | * Вехи | ||
* УЭК ArchiTECT | * Выпуск в любое время | * Релизы | ||
* Инженер по выпуску поездов (RTE) | * Поезд Agile Release | * Эпосы программы | ||
* Система ArchiТект/Инженер | * Релиз | * Программа Канбан | ||
* Владельцы бизнеса | * Отставание программы | |||
* Бережливые и гибкие лидеры | * Нефункциональные требования | |||
* Сообщества практиков | * Сначала взвешенное самое короткое задание (WSJF) | |||
* Общие услуги | * Цели PI программы | |||
* Клиент | * Характерная черта | |||
* Активатор | ||||
* Решение | ||||
* Координация потока создания ценности |
- На уровне программы ценность SAFe обеспечивается долгосрочными Agile Release Trains (ART). Итерация предназначена для команды, а обучение — для программы.
- Agile Release Trains (ART) является основным средством доставки ценности на уровне программы. Он обеспечивает поток создания ценности для организации.
- Продолжительность программных приращений (PI) составляет от 8 до 12 недель.
- ART состоит из 5–12 Agile-команд (около 50–125+ человек), которые включают в себя все роли и инфраструктуру, необходимые для поставки полностью протестированного, работающего программного обеспечения системного уровня.
- Каждый PI представляет собой временной интервал с несколькими итерациями. В ходе этого процесса разрабатывается и доставляется значительное, ценное дополнение системы.
- В каждом PI пройдут сеансы «демо» и «Проверка и адаптация», и начнется планирование следующего PSI.
- На уровне Программы SAFe уделяет особое внимание принципу согласованности. Это связано с тем, что усилия нескольких гибких команд объединены для создания ценности для клиентов.
- Иерархия артефактов SAFe Эпики->функции->пользовательские истории.
- На уровне программы менеджер по продукту/менеджер программы имеет полномочия в отношении содержания. Он определяет и расставляет приоритеты в отставании по программе.
- Журнал невыполненной программы — это приоритетный список функций.
- На уровне программы функции могут быть созданы или получены из эпиков, определенных на уровне портфолио.
- Функции разбиваются на пользовательские истории и перетекают в резервы на уровне команды.
- Роль менеджера по продукту или инженера по выпуску может выполнять менеджер программы/старший менеджер проекта.
- Система ArchiРоль tect на уровне программы заключается в ежедневном сотрудничестве с командами. Это гарантирует выполнение нефункциональных требований. Кроме того, они работают с архитектором предприятия на уровне портфолио, чтобы убедиться, что есть достаточный архитектурный задел для поддержки будущих потребностей пользователей и бизнеса.
- Дизайн интерфейса, рекомендации по пользовательскому опыту и элементы дизайна для команд предоставляются UX-дизайнерами.
- Роль главного Scrum-мастера выполняет «Инженер по выпуску поездов».
- Различные команды (от маркетинга, разработки, качества, эксплуатации и развертывания) образуют «Группу управления релизами». Они будут утверждать регулярные выпуски качественных решений для клиентов.
- Развертывание программного обеспечения в средах клиентов и успешная доставка осуществляется командой DevOps.
Уровень портфеля
Роли/Команды | Мероприятия | Артефакты | ||
---|---|---|---|---|
* Enterprise Architect | * Стратегическое инвестиционное планирование | * Стратегические темы | ||
* Управление портфелем программ | * Планирование портфолио Канбан (эпическое) | * Предприятие | ||
* Эпические владельцы | * Отставание в портфеле | |||
* Портфолио Канбан | ||||
* Нефункциональные требования | ||||
* Эпик и активатор | ||||
* Поток создания ценности | ||||
* Бюджеты (CapEx и OpEx) |
- Самый высокий уровень интереса/обеспокоенности/участия/ в SAFe Портфолио SAFe
- Портфель предоставляет базовые блоки для организации потока ценности Lean-Agile Enterprise через один или несколько потоков создания ценности.
- Портфолио помогает разрабатывать системы и решения, которые описаны в стратегических темах (связывает портфолио SAFe с меняющейся бизнес-стратегией предприятия).
- Для достижения стратегических целей уровень портфеля объединяет эти элементы. Он обеспечивает базовое бюджетирование и другие механизмы управления. Таким образом, это гарантирует, что инвестиции в потоки создания ценности обеспечат необходимую предприятию прибыль.
- Портфель связан с бизнесом в двух направлениях:
- Чтобы направить портфель к более масштабным меняющимся бизнес-целям, в нем предусмотрены стратегические темы.
- Другое направление указывает на постоянный поток ценностей портфеля.
- Управление портфелем программ выступает в качестве заинтересованных сторон и несет ответственность за достижение бизнес-результатов.
- Уровень портфеля SAFe содержит людей, процессы и необходимые системы сборки и решения, необходимые предприятию для достижения своих стратегических целей.
- Потоки создания ценности — это основные цели в Портфеле, с помощью которых финансируются люди и другие ресурсы, необходимые для создания Решений.
- Важными ключевыми понятиями, используемыми здесь, являются:
- Подключение к предприятию,
- Управление программным портфелем,
- Управление потоком эпических работ в портфолио.
Уровень потока создания ценности
Роли/Команды | Мероприятия | Артефакты | ||
---|---|---|---|---|
* DevOps | * Планирование до и после PI (приращения программы) | * Зрение | ||
* Системная команда | * Демонстрации решений | * Дорожная карта | ||
* Управление релизами | * Осмотрите и примите мастерскую | * Метрики | ||
* Управление решениями | * Поезд Agile Release | * Вехи | ||
* УЭК ArchiTECT | * Релизы | |||
* Инженер потока создания ценности (RTE) | *Эпосы потока создания ценности | |||
* Решение ArchiТект/Инженер | * Канбан потока создания ценности | |||
* Общие услуги | * Отставание потока создания ценности | |||
* Клиент | * Нефункциональные требования | |||
* Поставщик | * Сначала взвешенное самое короткое задание (WSJF) | |||
* Цели PI потока создания ценности | ||||
* Возможность | ||||
* Активатор | ||||
* Контекст решения | ||||
* Координация потока создания ценности | ||||
* Экономическая основа | ||||
* Цель решения | ||||
* МБСЕ | ||||
* На основе набора | ||||
* Гибкий Archiтекстура |
- Уровень потока создания ценности не является обязательным в SAFe.
- Уровень потока создания ценности является новым в SAFe 4.0.
- Уровень потока создания ценности предназначен/разработан для предприятий/строителей/организаций, которые:
- Большой размер
- Независмая платформа
- Иметь сложные решения
- Их решения обычно требуют нескольких ART.
- У них есть вклад поставщиков.
- Они сталкиваются с крупнейшими системными проблемами
- Для киберфизических систем
- Для программного обеспечения, аппаратного обеспечения, электрики и электроники, оптики, механики, струйной техники и многого другого.
- Для создания такого рода систем часто требуются сотни, даже тысячи практиков, внешних и внутренних поставщиков.
- Если системы имеют решающее значение. Неудача Решения или даже подсистемы имеет неприемлемые экономические и социальные последствия.
- Если Предприятия можно построить с помощью нескольких сотен практиков, им могут не понадобиться конструкции этого уровня. В этом случае они могут использовать из 'свернутое представление' это 3-уровневый SAFe.
- Построение решений потока создания ценности по шаблону Lean-Agile требует дополнительных артефактов, координации и конструкций. Таким образом, этот уровень содержит экономическую структуру, определяющую финансовые границы потока создания ценности.
- Он поддерживает частоту кадров и синхронизацию для нескольких ART и поставщиков. Он включает в себя встречи по планированию до и после PI, а также демонстрацию решения.
- Это дает дополнительные роли, а именно: инженер потока создания ценности, решение. Architect/инжиниринг и управление решениями.
Резюме
- SAFe — это проверенный в отрасли и ориентированный на ценность метод масштабирования Agile на уровне предприятия.
- Он отвечает на такие вопросы, как «Как мы планируем?», «Как мы составляем бюджет?» и «Как нам стать кросс-функциональными в архитектуре и DevOps?
- Структура SAFe Agile помогает командам крупных организаций достигать стратегических целей организации, а не только целей отдельных проектов.
- Эта структура предлагает возможность поддерживать и создавать централизованную стратегию для достижения ценности.
- Модель SAFe имеет три/четыре уровня, которые централизуют стратегические темы организации.
- Централизованная стратегия в сочетании с децентрализованной гибкой разработкой.
Ссылки:
SAFe для бережливых предприятий 5.0:
http://www.scaledagileframework.com