Учебное пособие по методологии SAFe: что такое масштабируемая гибкая структура

Что такое масштабируемая гибкая структура (SAFe)?

Scaled Agile Framework (SAFe) - это свободно доступная онлайн-база знаний, которая позволяет применять методы Lean- Agile на уровне предприятия. Он обеспечивает простой и легкий опыт разработки программного обеспечения. Это набор организаций и шаблонов рабочих процессов, предназначенных для руководства предприятиями по масштабированию бережливых и гибких практик. Он разделен на три сегмента: команда, программа и портфолио.

Фреймворк SAFe позволяет команде,

• Внедрение программного обеспечения и систем Lean-Agile на уровне предприятия
• Он основан на принципах Lean и Agile.
• В нем дается подробное руководство по работе с корпоративным портфелем, потоком создания ценности, программой и командой.
• Он разработан для удовлетворения потребностей всех заинтересованных сторон в организации.

SAFe был впервые разработан в этой области и подробно описан в книгах и блоге Дина Леффингвелла . Версия 1.0 - это первый официальный выпуск в 2011 году. Последняя версия - 4.6, выпущенная в октябре 2018 года. Она предоставляет руководство по работе на уровне корпоративного портфеля, потока создания ценности, программы и группы.

В этом руководстве по SAFe Agile вы узнаете:

• Что такое Scaled Agile Framework (SAFe)
• Зачем использовать Agile Framework
• Когда использовать масштабируемую гибкую платформу
• Насколько отличается от других Agile-практик
• Основы масштабируемой гибкой структуры
• Agile-манифест
• Различные уровни в SAFE
• Уровень команды
• Уровень программы
• Уровень портфеля
• Уровень потока создания ценности

Зачем использовать Agile Framework

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

• Производительность увеличена на 20-50%.
• Качество увеличилось более чем на 50%
• Время выхода на рынок быстрее, чем на 30-75%
• Повышенная вовлеченность сотрудников и удовлетворенность работой.

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

Изображение ниже объясняет, как работает гибкий процесс. Эпосы - это большой объем работ, который далее разбивается на несколько более мелких рассказов или субэпиков. Эти субэпики выделяются команде как рассказ. Затем каждая команда работает над этими историями или функциями программного обеспечения соответственно.

Когда использовать масштабируемую гибкую платформу

• Когда команда заинтересована в последовательном внедрении гибкого подхода в более крупные, многосторонние программы и портфели.
• Когда несколько команд используют свой собственный путь внедрения Agile, но регулярно сталкиваются с препятствиями, задержками и сбоями.
• Когда команды хотят работать независимо.
• Когда вы хотите масштабировать Agile в организации, но не знаете, какие новые роли могут потребоваться или какие существующие роли (например, руководство) необходимо изменить и как.
• Когда вы пытались масштабировать Agile в своей организации, но изо всех сил пытались согласовать ее для достижения единой или последовательной стратегии для всех бизнес-отделов от портфеля до уровня программы и команды.
• Когда организации необходимо сократить время разработки продукта и узнать, как другим компаниям удалось масштабировать Agile с помощью SAFe.

Насколько отличается от других Agile-практик

Теперь в этом руководстве по Scaled Agile Framework давайте посмотрим, чем Scaled Agile framework отличается от других гибких практик.

• Он общедоступен и бесплатен для использования.
• Доступен в очень доступной и удобной форме.
• Это легкий, проверенный на практике результат и специфичный для каждого уровня.
• Он постоянно / регулярно модифицирует / поддерживает наиболее часто используемые гибкие методы.
• Предлагает полезные расширения для распространенных гибких практик.
• Обосновывает гибкие методы работы с корпоративным контекстом.
• Предлагает полную картину разработки программного обеспечения.
• Видимость или прозрачность больше на всех уровнях.
• Постоянные или регулярные отзывы о качестве и улучшениях.

Основы масштабируемой гибкой структуры

Scaled Agile Framework (SAFe): он стоит на основе своих

1. Принципы Lean-Agile
2. Главные ценности,
3. Lean-Agile лидерство
4. Lean-Agile Mind-установка,
5. Сообщества практиков (группа людей, которые постоянно работают над практиками SAFe)
6. Реализация 1-2-3

Принципы SAFe Lean-Agile

Эти основные принципы и ценности SAFe Agile для SAFe необходимо понимать, демонстрировать и применять для достижения желаемых результатов.

• Взять экономический взгляд
• Применяйте системное мышление
• Предполагайте изменчивость; сохранить варианты
• Постройте поэтапно с помощью быстрых интегрированных циклов обучения
• Основные этапы объективной оценки рабочих систем
• Визуализируйте и ограничивайте WIP, уменьшайте размеры пакетов и управляйте длиной очереди
• Применяйте каденс, синхронизируйте с междоменным планированием
• Раскройте внутреннюю мотивацию работников умственного труда
• Децентрализовать принятие решений

Основные ценности SAFe Agile

Методология SAFe Agile основана на этих четырех ценностях.

Выравнивание:

• SAFe поддерживает выравнивание.
• Выравнивание начинается в,
  • Стратегические темы в портфолио Backlog и
  • Переходит к Видению и Дорожной карте невыполненных работ по программе, а затем
  • Переходит в бэклоги команды.

Встроенное качество:

• Это гарантирует, что каждая дополнительная поставка соответствует стандартам качества.
• Качество не «добавлено позже» встроено.
• Встроенное качество является предпосылкой Lean и его обязательным условием.

Прозрачность:

• Прозрачность - залог доверия.
• SAFe помогает предприятию достичь прозрачности на всех уровнях - руководителей, менеджеров портфеля и других заинтересованных сторон.
• Каждый может увидеть бэклог портфолио / Канбан, программный бэклог / Канбан и бэклог команды / Канбан.
• На каждом уровне есть четкое понимание целей PI.
• У программ обучения есть видимость невыполненных работ команды, а также других невыполненных работ по программе.
• Команды и программы имеют представление о бизнесе и архитектуре. Они могут видеть, что их ждет.

Выполнение программы:

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

Lean Agile-лидеры:

Lean-Agile-лидеры - постоянные ученики и учителя. Это помогает командам создавать лучшие системы за счет понимания и демонстрации принципов Lean-Agile SAFe.

В качестве инструмента поддержки команд конечная ответственность заключается в принятии, успехе и постоянном улучшении Lean-Agile разработок. Для изменений и постоянного совершенствования лидеров необходимо обучать.

Лидерам необходимо принять новый стиль лидерства. Тот, который действительно расширяет возможности и вовлекает людей и команды в достижение их максимального потенциала.

Принципы Lean-Agile лидеров

• Возглавить изменение
• Знай путь; Сделайте акцент на непрерывном обучении
• Развивайте людей
• Вдохновлять и соответствовать миссии; Минимизировать ограничения
• Децентрализовать процесс принятия решений
• Раскройте внутреннюю мотивацию работников умственного труда

Бережливое и гибкое мышление:

Lean-Agile образ мышления представлен в двух вещах:

1. Дом бережливого производства в SAFe
2. Agile-манифест

SAFe House of Lean :

SAFe основывается на принципах и практиках бережливого производства. Основываясь на этих факторах, SAFe представляет «SAFe House of Lean». Он вдохновлен «домом» тощей Toyota.

Цель бережливого производства непревзойденна: предоставить клиенту максимальную ценность в кратчайшие сроки с максимально возможным качеством для клиента.

На рисунке ниже поясняются цель, столпы и основа «SAFe House of Lean».

Agile-манифест

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

Вот почему, хотя элементы справа имеют ценность, мы ценим элементы слева больше.

Agile-манифест

1. Наивысшим приоритетом является удовлетворение потребностей клиента за счет непрерывной и своевременной поставки ценного программного обеспечения.
2. Примите меняющиеся требования даже на поздних этапах разработки. Изменения в методологии Agile SAFe используются в интересах клиента.
3. Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков.
4. Разработчики и бизнесмены должны ежедневно работать вместе на протяжении всего проекта.
5. Создавайте проекты вокруг мотивированных людей. Окажите им поддержку и необходимую им среду, и доверьте им выполнение работы.
6. Самый эффективный способ общения с командой разработчиков - это личный разговор.
7. Работающее программное обеспечение - это главный показатель прогресса.
8. Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп бесконечно.
9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
10. Простота - искусство максимизировать объем незавершенной работы - очень важна.
11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
12. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Различные уровни в SAFE

Существует два разных типа реализации SAFe:

1. Реализация SAFe 4.0
2. Реализация SAFe 3.0

• В реализации SAFe 4.0 у нас есть 4 уровня: портфель, поток создания ценности, программа и команда.
• В реализации SAFe 3.0 у нас есть 3 уровня: портфолио, программа и команда.
• Трехуровневый SAFe предназначен для небольших внедрений со 100 и менее людьми. Программы, не требующие значительного сотрудничества.
• 4-уровневая SAFe предназначена для решений, которые обычно требуют многих сотен практиков для разработки, развертывания и сопровождения программного обеспечения.

Уровень команды

Роли / Команды		События		Артефакты
* Гибкая команда		* Планирование спринта		* Бэклог команды
* Владелец продукта		* Обработка бэклога		* Нефункциональные требования
* Скрам Мастер		* Ежедневный стендап		* Цели команды PI
		* Исполнение		* Итерации
		* Демоверсия спринта		* Истории (рабочая программа)
		* Ретроспектива спринта		* Цели спринта
		* IP Sprints		* Встроенное качество
				* Шипы
				* Команда Канбан

• Все команды SAFe являются частью той или иной Agile Release Train (ART).
• Команды SAFe - это наделенные полномочиями, самоорганизующиеся, самоуправляемые, кросс-функциональные команды.
• Каждая команда в равной степени отвечает за определение, построение и тестирование историй из своей бэклога команды в итерациях фиксированной длины.
• Команды планируют и выполняют двухнедельные итерации в соответствии с согласованными Целями итераций.
• Команды будут использовать процедуру ScrumXP / Team Kanban для доставки высококачественных систем для демонстрации системы каждые две недели.
• Все разные команды в ART (Agile Release Trains) создадут интегрированную и протестированную систему. Заинтересованные стороны оценят и ответят быстрой обратной связью
• Они применяют методы встроенного качества.
• Каждая команда ScrumXP будет состоять из 5–9 членов команды, что включает в себя все роли, необходимые для создания добавочной ценности качества в каждой итерации.
• Роли ScrumXP включают:
  • Команда (Dev + QA)
  • Скрам Мастер
  • Владелец продукта. Так далее…
• SAFe делит график разработки на набор итераций внутри PI (Program Increment).
• Продолжительность ИП составляет от 8 до 12 недель.
• Команда будет использовать истории, чтобы донести ценность. Владелец продукта будет иметь право контролировать создание и принятие историй.
• Истории содержат требования Заказчика.
• Бэклог группы включает истории пользователей и участников, которые выявляются во время планирования PI. Когда менеджмент продукта представляет дорожную карту, видение и невыполненную работу программы.
• Выявление, разработка, расстановка приоритетов, планирование, реализация, тестирование и принятие историй являются основными требованиями управленческой работы на уровне команды.
• Каждая итерация обеспечивает:
  • Ценный прирост новой функциональности
  • Достигайте с помощью постоянно повторяющегося шаблона
  • Планируйте итерацию
  • Придерживайтесь некоторой функциональности
  • Выполните итерацию путем создания и тестирования историй.
  • Продемонстрируйте новую функциональность
  • Ретроспектива
  • Повторите для следующей итерации
• Команды также поддерживают демонстрацию системы в конце каждой итерации. что является критической точкой интеграции для ART.
• Более крупные потоки создания ценности будут иметь несколько АРТ.
• Итерации инноваций и планирования (IP) дают командам возможность для инноваций и исследований.

Уровень программы

Роли / Команды		События		Артефакты
* DevOps		* Планирование PI (увеличение программы)		* Зрение
* Системная команда		* Демонстрации системы		* Дорожная карта
* Управление релизами		* Осмотреть и принять мастерскую		* Метрики
* Управление продуктом		* Архитектурная взлетно-посадочная полоса		* Вехи
* Архитектор UEX		* Выпустить в любое время		* Релизы
* Инженер по выпуску программ (RTE)		* Agile Release Train		* Программные эпосы
* Системный архитектор / инженер		* Релиз		* Программа Канбан
* Владельцы бизнеса				* Бэклог программы
* Lean-Agile лидеры				* Нефункциональные требования
* Сообщества практиков				* Сначала самое короткое взвешенное задание (WSJF)
* Общие службы				* Цели программы PI
* Покупатель				* Особенность
				* Активатор
				* Решение
				* Координация потока создания ценности

• На уровне программы ценность SAFe обеспечивается долгоживущими Agile Release Trains (ART). Итерация предназначена для команды, а тренировка - для программы.
• Agile Release Trains (ART) - это основное средство доставки ценности на программном уровне. Он обеспечивает организацию потоком создания ценности.
• Продолжительность инкрементов программы (ИП) составляет от 8 до 12 недель.
• ART состоит из 5–12 Agile-команд (~ 50–125+ человек), которые включают в себя все роли и инфраструктуру, необходимые для предоставления полностью протестированного, работающего программного обеспечения системного уровня.
• Каждый PI представляет собой временную рамку с несколькими итерациями. Во время которого разрабатывается и доставляется значительный, ценный прирост системы.
• В каждом PI будут проходить сеансы «демонстрации» и «проверки и адаптации», и начнется планирование для следующего PSI.
• На уровне Программы SAFe делает упор на принцип согласованности. Это связано с тем, что усилия нескольких гибких команд объединены для создания ценности для клиентов.
• Иерархия артефактов SAFe: Эпики-> особенности-> пользовательские истории .
• На уровне программы менеджер по продукту / менеджер программы имеет полномочия на контент. Он определяет и расставляет приоритеты для невыполненной работы программы.
• Бэклог программы - это список функций с приоритетом.
• На уровне программы функции могут быть созданы, или они могут быть производными от эпиков, определенных на уровне портфолио.
• Функции разлагаются на пользовательские истории и переходят в бэклоги на уровне команды.
• Роль менеджера по продукту или инженера по подготовке релизов может выполняться менеджером программы / старшим менеджером проекта.
• Роль системного архитектора на уровне программы заключается в ежедневной совместной работе с командами. Это гарантирует выполнение нефункциональных требований. Кроме того, они работают с архитектором предприятия на уровне портфолио, чтобы убедиться, что существует достаточная архитектурная площадка для поддержки будущих потребностей пользователей и бизнеса.
• Дизайн интерфейса, рекомендации по взаимодействию с пользователем и элементы дизайна для команд предоставляются дизайнерами UX.
• Роль шеф-скрам-мастера исполняет «Инженер по выпуску».
• Различная команда (от маркетинга, разработки, качества, операций и развертывания) формирует «команду управления релизами». Они будут утверждать регулярные выпуски качественных решений для клиентов.
• Развертывание программного обеспечения в клиентских средах и успешная доставка осуществляется командой DevOps.

Уровень портфеля

Роли / Команды		События		Артефакты
* Корпоративный архитектор		* Стратегическое инвестиционное планирование		* Стратегические темы
* Управление портфелем программ		* Канбан-портфолио (эпическое) планирование		* Предприятие
* Эпические владельцы				* Бэклог портфолио
				* Портфолио Канбан
				* Нефункциональные требования
				* Эпический и активатор
				* Поток создания ценности
				* Бюджеты (CapEx и OpEx)

• Наивысший уровень интереса / беспокойства / вовлеченности / в SAFe - это SAFe Portfolio
• Портфель предоставляет базовые блоки для организации потока ценности Lean-Agile Enterprise через один или несколько потоков создания ценности.
• Портфель помогает разрабатывать системы и решения, описанные в стратегических темах (связывает портфель SAFe с изменяющейся бизнес-стратегией предприятия).
• Для достижения стратегических целей эти элементы инкапсулируются на уровне портфеля. Он обеспечивает базовое бюджетирование и другие механизмы управления. Таким образом, он гарантирует, что инвестиции в потоки создания ценности обеспечат прибыль, необходимую предприятию.
• Портфель связан с бизнесом двунаправленно:
  • Чтобы направить Портфолио к более крупным меняющимся бизнес-целям, в нем представлены стратегические темы.
  • Другое направление указывает на постоянный поток ценностей портфеля.
• Управление портфелем программ действует как заинтересованные стороны, и они несут ответственность за достижение бизнес-результатов.
• Уровень портфеля SAFe содержит людей, процессы и необходимые системы сборки и решения, необходимые предприятию для достижения своих стратегических целей.
• Потоки создания ценности - это основные цели Портфеля, с помощью которых можно финансировать людей и другие ресурсы, необходимые для создания Решения.
• Здесь используются следующие важные ключевые концепции:
  • Подключение к предприятию,
  • Управление портфелем программ,
  • Управление потоком эпиков портфолио.

Уровень потока создания ценности

Роли / Команды		События		Артефакты
* DevOps		* Предварительное и последующее планирование PI (увеличение программы)		* Зрение
* Системная команда		* Демонстрации решений		* Дорожная карта
* Управление релизами		* Осмотреть и принять мастерскую		* Метрики
* Управление решениями		* Agile Release Train		* Вехи
* Архитектор UEX				* Релизы
* Инженер потока создания ценности (RTE)				* Эпические произведения о потоке создания ценности
* Архитектор решений / инженер				* Канбан потока создания ценности
* Общие службы				* Бэклог потока создания ценности
* Покупатель				* Нефункциональные требования
* Поставщик				* Сначала самое короткое взвешенное задание (WSJF)
				* Цели PI потока создания ценности
				* Возможность
				* Активатор
				* Контекст решения
				* Координация потока создания ценности
				* Экономическая основа
				* Намерение решения
				* MBSE
				* На основе набора
				* Гибкая архитектура

• Уровень потока создания ценности не является обязательным в SAFe.
• Уровень потока создания ценности является новым в SAFe 4.0.
• Уровень потока создания ценности предназначен / разработан для предприятий / строителей / организаций, которые:

1. Большой размер
2. Независимый
3. Имеют комплексные решения
4. Их решения обычно требуют нескольких АРТ.
5. У них есть вклад Поставщиков.
6. Они сталкиваются с самыми большими системными проблемами
7. Для киберфизических систем
8. Для программного обеспечения, оборудования, электрики и электроники, оптики, механики, гидравлики и многого другого.

• Для создания таких систем часто требуются сотни, даже тысячи специалистов-практиков, внешних и внутренних поставщиков.
• Если системы имеют решающее значение. Отказ Решения или даже подсистемы имеет неприемлемые экономические и социальные последствия.
• Если предприятие может быть построено с несколькими сотнями практиков, ему могут не понадобиться конструкции этого уровня. В этом случае они могут использовать « свернутый вид», то есть трехуровневый SAFe.
• Построение решений потока создания ценности по модели Lean-Agile требует дополнительных артефактов, координации и конструкций. Таким образом, этот уровень содержит экономическую основу для определения финансовых границ потока создания ценности.
• Он поддерживает каденцию и синхронизацию для нескольких АРТ и поставщиков. Он включает встречи до и после планирования PI и демонстрацию решения.
• Он дает дополнительные роли, а именно: инженер по потоку создания ценности, архитектор / проектировщик решений и управление решениями.

Резюме:

• SAFe - это проверенный в отрасли, ориентированный на ценность метод масштабирования Agile на уровне предприятия.
• Он отвечает на такие вопросы, как «Как мы планируем?», «Как мы составляем бюджет?» И «Как мы можем стать кросс-функциональными в архитектуре и DevOps?»
• Фреймворк SAFe Agile помогает большим группам организаций достигать стратегических целей организации, а не только целей отдельных проектов.
• Эта структура предлагает возможность поддерживать и создавать централизованную стратегию предоставления ценности.
• Модель SAFe имеет три / четыре уровня, которые централизуют стратегические темы организации.
• Централизованная стратегия в сочетании с децентрализованной гибкой разработкой.

Рекомендации:

SAFe для бережливых предприятий 5.0:

http://www.scaledagileframework.com

Эта статья предоставлена Джьоти Рангараджем