Что такое масштабируемая Agile Framework (SAFe)?
Scaled Agile Framework SAFe — это свободно доступная онлайновая база знаний, которая позволяет вам применять бережливые методы на уровне предприятия. Это обеспечивает простой и легкий опыт для команды разработчиков программного обеспечения. Вся структура делится на три сегмента: Команда, Программа и Портфолио . Мы увидим это подробно позже. SAFe позволяет команде,
- Внедрение программного обеспечения и систем Lean-Agile на уровне предприятия
- Он основан на принципах Lean и Agile.
- Он содержит подробное руководство по работе с корпоративным портфелем, потоком добавленной стоимости, программой и командой.
- Он предназначен для удовлетворения потребностей всех заинтересованных сторон в организации.
SAFe был впервые разработан в этой области и был разработан в книгах и блоге Дина Леффингвелла . Версия 1.0 является первым официальным выпуском в 2011 году. Последняя версия 4.6 была выпущена в октябре 2018 года. Она содержит руководство по работе на корпоративном уровне портфеля, потока создания ценности, программы и команды.
В этом уроке вы узнаете
- Что такое Scaled Agile Framework (SAFe)
- Зачем использовать Agile Framework
- Когда использовать Scaled Agile Framework
- Насколько отличается от других Agile практик
- Основы Scaled Agile Framework
- Agile Manifesto
- Разные уровни в SAFE
Зачем использовать Agile Framework
Он проще и легче по весу, но расширяется для удовлетворения потребностей больших потоков создания ценности и разработки сложных систем. Внедрив Agile Framework, вы получите следующие преимущества:
- Производительность увеличилась на 20 — 50%
- Качество увеличилось более чем на 50%
- Время выхода на рынок быстрее, чем 30 -75%
- Повышение вовлеченности сотрудников и удовлетворенности работой.
Подробная структурная схема доступна на сайте . Он показывает все ключевые роли, виды деятельности, результаты и потоки. Он также служит навигационной помощью для остальной части сайта.
На изображении ниже показано, как работает гибкий процесс. Эпики — это большая часть работы, которая в свою очередь разбита на несколько небольших историй или подэпопов. Эти подэпопеи выделены команде как история. Затем каждая команда работает над этими историями или программными функциями соответственно.
Когда использовать Scaled Agile Framework
- Когда команда заинтересована в последовательном внедрении гибкого подхода в более крупные, многопрофильные программы и портфели.
- Когда несколько команд используют свой собственный способ гибкой реализации, но регулярно сталкиваются с препятствиями, задержками и сбоями.
- Когда команды хотят работать самостоятельно.
- Если вы хотите масштабировать Agile по всей организации, но не уверены, какие новые роли могут понадобиться или какие существующие роли (например, управление) нужно изменить и как.
- Когда вы пытались масштабировать Agile в своей организации, но пытались добиться согласованности, чтобы достичь единой или согласованной стратегии для бизнес-подразделений от уровня портфеля до уровня программы и команды.
- Когда организации необходимо улучшить сроки разработки своих продуктов и узнать, как другим компаниям удалось масштабировать Agile с помощью SAFe.
Насколько отличается от других Agile практик
Давайте посмотрим, чем Scaled Agile Framework отличается от других Agile практик,
- Это общедоступное и бесплатное использование.
- Доступный в очень доступной и удобной форме.
- Это легкие, практически проверенные результаты и специфичные для уровня.
- Он постоянно / регулярно модифицирует / поддерживает наиболее часто используемые гибкие методы.
- Предлагает полезные дополнения к обычным гибким практикам.
- Основывает гибкие практики в контексте предприятия.
- Предлагает полную картину разработки программного обеспечения.
- Видимость или прозрачность больше на всех уровнях.
- Постоянные или регулярные отзывы о качестве и улучшении.
Основы Scaled Agile Framework
Scaled Agile Framework (SAFe): он стоит на фундаменте своего
- Lean-Agile Принципы
- Главные ценности,
- Lean-Agile Лидерство
- Lean-Agile Mind-set,
- Сообщества практиков (группа людей, которые постоянно работают над практиками SAFe)
- Реализация 1-2-3
- БЕЗОПАСНЫЕ Бережливые принципы
Эти основные принципы и ценности для SAFe должны быть поняты, продемонстрированы и продолжены, чтобы получить желаемые результаты.
- Взять экономический взгляд
- Применить системное мышление
- Предположить изменчивость; сохранить параметры
- Построение постепенно с быстрыми, интегрированными циклами обучения
- Базовые вехи на объективной оценке рабочих систем
- Визуализация и ограничение WIP, уменьшение размеров пакетов и управление длинами очередей
- Применяйте каденцию, синхронизируйте с междоменным планированием
- Разблокировать внутреннюю мотивацию работников умственного труда
- Децентрализовать принятие решений
- SAFe Agile Core Values
SAFe Agile основан на этих четырех значениях.
Выравнивание:
- SAFe поддерживает выравнивание.
- Выравнивание начинается в,
- Стратегические темы в портфеле отставания и
- Переходит вниз к Vision и Roadmap программных журналов, а затем
- Перемещается в бэклоги команды.
Встроенное качество:
- Это гарантирует, что каждая дополнительная поставка отражает стандарты качества.
- Качество не «добавлено позже» встроено.
- Встроенное качество является обязательным условием Lean и его обязательным
Прозрачность:
- Прозрачность является фактором доверия.
- SAFe помогает предприятию достичь прозрачности на всех уровнях — руководителей, менеджеров портфелей и других заинтересованных сторон.
- Каждый может посмотреть в портфель бэклогов / Канбан, программных бэклогов / Канбан и Team Backlog / Kanban.
- Каждый уровень имеет четкое понимание целей PI.
- Программы поездов имеют видимость как в журналах команды, так и в других программах.
- Команды и программы имеют представление о бизнесе и архитектуре эпосов. Они могут видеть, что может быть на их пути.
Выполнение программы:
- SAFe уделяет большое внимание рабочим системам и полученным результатам бизнеса.
- SAFe бесполезен, если команды не могут выполнять и непрерывно приносить пользу.
- Lean Agile Лидеры:
Lean-Agile Лидеры являются учителями и пожизненными учителями. Это помогает командам создавать более совершенные системы посредством понимания и демонстрации принципов Lean-Agile SAFe.
В качестве вспомогательного средства для команд главная ответственность заключается в принятии, успехе и постоянном улучшении разработок Lean-Agile. Для перемен и постоянного улучшения лидеры должны быть обучены.
Лидеры должны принять новый стиль руководства. Тот, который действительно уполномочивает и привлекает отдельных людей и команды для достижения их самого высокого потенциала.
Принципы этих Lean-Agile Лидеров
- Привести изменения
- Знай Путь; Подчеркните непрерывное обучение
- Развивайте людей
- Вдохновлять и согласовываться с миссией; Минимизировать ограничения
- Децентрализовать принятие решений
- Разблокировать внутреннюю мотивацию работников знаний
- Lean Agile Mind-Set:
Lean-Agile образ мышления представлен двумя вещами:
- БЕЗОПАСНЫЙ Дом Бережливого производства
- Agile Manifesto
БЕЗОПАСНЫЙ Дом Бережливого производства :
SAFe основывается на принципах и методах производства Lean. На основании этих факторов SAFe представляет «SAFe House of Lean». Он вдохновлен «домом» постной Toyota.
Цель Lean непобедима: обеспечить максимальную ценность для клиента в кратчайшие сроки и максимально возможное качество для клиента
Ниже на рисунке объясняются цель, столпы и основа «БЕЗОПАСНОГО Дома Бережливого производства».
Agile Manifesto
Мы раскрываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. Благодаря этой работе мы пришли к оценке:
Вот почему, хотя в пунктах справа есть значение, мы оцениваем элементы слева больше.
Agile Manifesto
- Наивысшим приоритетом является удовлетворение клиента путем непрерывной и ранней доставки ценного программного обеспечения.
- Примите меняющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения в интересах клиента.
- Поставляйте работающее программное обеспечение часто, от пары недель до нескольких месяцев, предпочитая более короткие сроки.
- Разработчики и бизнесмены должны ежедневно работать вместе на протяжении всего проекта.
- Создавайте проекты вокруг мотивированных людей. Предоставьте им поддержку и необходимую им среду, и доверьте им выполнение работы.
- Наиболее эффективным способом общения с командой разработчиков является личный разговор.
- Рабочее программное обеспечение является основной мерой прогресса.
- Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
- Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
- Простота — искусство максимизировать количество не выполненной работы — очень важно.
- Лучшие архитектурные решения, требования и проекты возникают из самоорганизующихся команд.
- Через регулярные интервалы команда размышляет о том, как стать более эффективным, затем настраивает и корректирует свое поведение соответствующим образом.
Разные уровни в SAFE
Существует два разных типа реализации SAFe:
- Реализация SAFe 4.0
- Реализация SAFe 3.0
- В реализации SAFe 4.0 у нас есть 4 уровня: Портфолио, Поток создания ценности, Программа и Команда.
- В реализации SAFe 3.0 у нас есть 3 уровня: портфолио, программа и команда
- 3-уровневый SAFe предназначен для небольших реализаций с 100 или менее человек. Программы, которые не требуют значительного сотрудничества.
- 4-уровневый SAFe предназначен для решений, которые, как правило, требуют от сотен практиков разработки и развертывания программного обеспечения.
Уровень команды
| Роли / Команды | Мероприятия | Артефакты | ||
| * Agile Team | * Спринт Планирование | * Команда Отставание | ||
| * Владелец продукта | * Отставание Груминг | * Нефункциональные требования | ||
| * Scrum Master | * Ежедневная стоянка | * Цели команды PI | ||
| * Исполнение | * Итерации | |||
| * Спринт Демо | * Истории (рабочее программное обеспечение) | |||
| * Спринт Ретроспектива | * Спринт Голы | |||
| * IP Sprints | * Встроенное качество | |||
| * Шипы | ||||
| * Команда Канбан |
- Все команды SAFe являются частью того или иного Agile Release Train (ART).
- Команды SAFe — это уполномоченные, самоорганизующиеся, самоуправляемые, многофункциональные команды
- Каждая команда в равной степени отвечает за определение, создание и тестирование историй из своего бэклога команды в итерациях фиксированной длины.
- Команды планируют и выполняют двухнедельные итерированные по времени итерации в соответствии с согласованными целями итерации.
- Команды будут использовать рутину ScrumXP / Team Kanban для предоставления высококачественных систем для создания демонстрации системы каждые две недели.
- Все различные команды в ART (Agile Release Trains) создадут интегрированную и протестированную систему. Заинтересованные стороны оценят и ответят с быстрой обратной связи
- Они применяют встроенные методы контроля качества.
- В каждой команде ScrumXP будет от 5 до 9 членов команды, включая все роли, необходимые для создания качественного добавочного значения в каждой итерации.
- Роли ScrumXP включают в себя:
- Команда (Дев + QA)
- Скрам Мастер
- Владелец продукта. Так далее..
- SAFe делит временную шкалу разработки на набор итераций в PI (Program Increment).
- Продолжительность ИП составляет от 8 до 12 недель.
- Команда будет использовать истории, чтобы донести ценность. Владелец продукта будет обладать правами на контент при создании и принятии историй.
- Истории содержат требования Заказчика.
- Журнал ожидания группы включает истории пользователей и разработчиков, которые определяются во время планирования PI. Когда Управление продуктом представляет план, видение и отставание программы.
- Выявление, разработка, расстановка приоритетов, планирование, внедрение, тестирование и принятие историй являются основными требованиями управленческой работы на уровне команды.
- Каждая итерация обеспечивает:
- Ценный прирост новой функциональности
- Выполнять через постоянно повторяющийся шаблон
- Запланируйте итерацию
- Передайте некоторые функциональные возможности
- Выполните итерацию путем создания и тестирования историй
- Демо новая функциональность
- ретроспективный
- Повторите для следующей итерации
- Команды также поддерживают демонстрацию системы в конце каждой итерации. которая является критической точкой интеграции для АРТ.
- Большие потоки создания ценности будут иметь несколько АРТ.
- Итерации по инновациям и планированию (ИС) дают командам возможность для инноваций и исследований.
Уровень программы
| Роли / Команды | Мероприятия | Артефакты | ||
| * DevOps | * PI (увеличение программы) планирование | * Видение | ||
| * Системная команда | * Системные демонстрации | * Дорожная карта | ||
| * Управление релизами | * Осмотреть и принять семинар | * Метрики | ||
| * Управление продуктом | * Архитектурная взлетно-посадочная полоса | * Вехи | ||
| * UEX Архитектор | * Выпуск в любое время | * Релизы | ||
| * Инженер по выпуску поездов (RTE) | * Agile Release Train | * Эпические программы | ||
| * Системный архитектор / Инженер | * Релиз | * Программа Канбан | ||
| * Владельцы бизнеса | * Журнал программы | |||
| * Бережливые Лидеры | * Нефункциональные требования | |||
| * Сообщества практики | * Взвешенная самая короткая работа в первую очередь (WSJF) | |||
| * Общие службы | * Цели программы PI | |||
| * Клиент | * Характерная черта | |||
| * Enabler | ||||
| * Решение | ||||
| * Координация потока создания ценности |
- На уровне Программы ценность SAFe обеспечивается с помощью долгоживущих поездов Agile Release (ART). Итерация для команды, а поезд для программы.
- Agile Release Trains (ART) является основным средством доставки ценностей на уровне программы. Это обеспечивает поток ценности для организации.
- Продолжительность программы (ИП) составляет от 8 до 12 недель.
- ART состоит из 5-12 Agile команд (~ 50 — 125+ человек), которые включают в себя все роли и инфраструктуру, необходимые для предоставления полностью протестированного, работающего программного обеспечения системного уровня.
- Каждый PI — это временное окно с несколькими итерациями. В течение которого существенный, ценный прирост системы разрабатывается и поставляется.
- На каждом ПИ будут происходить сеансы «демо» и «Проверять и адаптировать», и начинается планирование следующего PSI.
- На уровне Программы SAFe делает акцент на принципе выравнивания. Это связано с тем, что для создания потребительской ценности объединены многочисленные гибкие коллективные усилия.
- Иерархия артефактов SAFe — это Epics-> Features-> User Stories .
- На уровне программы менеджер по продукту / руководитель программы имеет полномочия по содержанию. Он определяет и расставляет приоритеты в программе.
- Отставание программы — это приоритетный список возможностей.
- На уровне программы функции могут быть созданы или основаны на эпосах, определенных на уровне портфолио.
- Функции разлагаются на пользовательские истории и переходят в резервы на уровне команды.
- Менеджер по продукту или инженер по выпуску может быть исполнен менеджером программы / старшим менеджером проекта
- Роль системного архитектора на уровне программы заключается в совместной работе с командами. Это обеспечивает выполнение нефункциональных требований. Кроме того, они работают с корпоративным архитектором на уровне портфеля, чтобы убедиться, что имеется достаточная архитектурная взлетно-посадочная полоса для удовлетворения будущих потребностей пользователей и бизнеса.
- Дизайн интерфейса, рекомендации для пользователей и элементы дизайна для команд предоставляются UX Designers.
- Роль Chief-Scrum Master играет «Инженер по выпуску поездов».
- Различные команды (от маркетинга, разработки, качества, эксплуатации и развертывания) формируют «Команду управления выпусками». Они будут утверждать регулярные выпуски качественных решений для клиентов.
- Развертывание программного обеспечения в клиентских средах и успешная доставка осуществляется командой DevOps.
Уровень портфолио
| Роли / Команды | Мероприятия | Артефакты | ||
| * Архитектор предприятия | * Стратегическое планирование инвестиций | * Стратегические Темы | ||
| * Программный портфель Mgmt | * Канбан Портфолио (Epic) Планирование | * Предприятие | ||
| * Эпические Владельцы | * Портфель Бэклог | |||
| * Портфель Канбан | ||||
| * Нефункциональные требования | ||||
| * Epic и Enabler | ||||
| * Поток создания ценности | ||||
| * Бюджеты (CapEx и OpEx) |
- Наивысший уровень заинтересованности / озабоченности / вовлеченности / в SAFe — это портфолио SAFe
- Портфель предоставляет основные блоки для организации потока стоимости Lean-Agile Enterprise через один или несколько потоков создания ценности.
- Портфель помогает разрабатывать системы и решения, которые описаны в стратегических темах (связывает портфель SAFe с меняющейся бизнес-стратегией предприятия).
- Для достижения стратегических целей уровень портфеля включает эти элементы. Он обеспечивает базовое бюджетирование и другие механизмы управления. Таким образом, это гарантирует, что инвестиции в потоки создания ценности обеспечивают прибыль, необходимую для предприятия.
- Портфель связан с бизнесом в двух направлениях:
- Для того, чтобы направить Портфолио к более меняющимся бизнес-целям, он предлагает стратегические темы.
- Другое направление указывает на постоянный поток значений портфеля.
- Управление портфелем программ действует как заинтересованные стороны, и они несут ответственность за достижение бизнес-результатов.
- Уровень портфеля SAFe содержит сотрудников, процессы и необходимые системы и решения для построения, которые необходимы предприятию для достижения своих стратегических целей.
- Потоки создания ценности являются основными целями в портфолио, с помощью которого финансирование для людей и других ресурсов, необходимых для создания решений.
- Важные ключевые понятия, используемые здесь:
- Подключение к предприятию,
- Управление портфелем программ,
- Управление потоком портфельных эпопей.
Уровень потока создания ценности
| Роли / Команды | Мероприятия | Артефакты | ||
| * DevOps | * Планирование до и после PI (увеличение программы) | * Видение | ||
| * Системная команда | * Демонстрационные решения | * Дорожная карта | ||
| * Управление релизами | * Осмотреть и принять семинар | * Метрики | ||
| * Управление решениями | * Agile Release Train | * Вехи | ||
| * UEX Архитектор | * Релизы | |||
| * Value Stream Engineer (RTE) | * Поток ценности Эпос | |||
| * Архитектор решений / Инженер | * Поток ценности Канбан | |||
| * Общие службы | * Журнал потока создания ценности | |||
| * Клиент | * Нефункциональные требования | |||
| * Поставщик | * Взвешенная самая короткая работа в первую очередь (WSJF) | |||
| * Цели потока создания ценности | ||||
| * Возможность | ||||
| * Enabler | ||||
| * Контекст решения | ||||
| * Координация потока создания ценности | ||||
| * Экономическая структура | ||||
| * Решение намерения | ||||
| * MBSE | ||||
| * Установить на основе | ||||
| * Гибкая архитектура |
- Уровень потока создания ценности необязателен в SAFe.
- Уровень потока создания ценности является новым в SAFe 4.0.
- Уровень потока создания ценности предназначен / предназначен для предприятий / строителей / организаций, которые:
- Большой по размеру
- независимый
- Есть сложные решения
- Их решения обычно требуют нескольких АРТ
- Они имеют вклад поставщиков.
- Они сталкиваются с крупнейшими системными проблемами
- Для кибер-физических систем
- Для программного обеспечения, оборудования, электрики и электроники, оптики, механики, жидкостей и многого другого
- Создание такого рода систем часто требует сотен, даже тысяч практиков, внешних и внутренних поставщиков.
- Если системы имеют решающее значение. Отказ Решения или даже подсистемы имеет неприемлемые экономические и социальные последствия.
- Если Предприятия могут быть построены с несколькими сотнями практикующих, возможно, им не понадобятся конструкции этого уровня. В этом случае они могут использовать « свернутое представление», которое является 3-уровневым SAFe.
- Построение решений потока создания ценности в шаблоне Lean-Agile требует дополнительных артефактов, координации и конструкций. Таким образом, этот уровень содержит экономическую основу для предоставления финансовых границ для потока создания ценности.
- Он поддерживает каденцию и синхронизацию для нескольких ART и поставщиков. Он включает в себя встречи до и после планирования PI и демонстрацию решения.
- Он предоставляет дополнительные роли: Инженер потока создания ценности, Архитектор решений / Проектирование и Управление решениями.
Резюме:
- SAFe — это проверенный в отрасли, ориентированный на ценность метод масштабирования Agile на уровне предприятия.
- Он отвечает на такие вопросы, как «Как мы планируем?», «Как мы планируем бюджет?» И «Как мы становимся кросс-функциональными в архитектуре и DevOps?»
- SAFe помогает крупным организационным группам достигать стратегических целей организации, а не только отдельных целей проекта.
- Структура предлагает возможность поддерживать и создавать централизованную стратегию для обеспечения ценности.
- Модель SAFe имеет три / четыре уровня, которые централизуют стратегические темы организации.
- Централизованная стратегия в сочетании с децентрализованным выполнением гибкой разработки.
Ссылки:
Официальные и текущие сайты для справки:
http://www.scaledagileframework.com
Эта статья предоставлена Джоти Рангараджем