SAFe, или Scaled Agile Framework, представляет собой фреймворк разработки программного обеспечения, которая позволяет организациям эффективно работать над крупными проектами, объединяя команды разработчиков в единую систему. В нашем банке внедрение SAFe привело к значительным улучшениям в процессах разработки и качестве продукта.
Первоначально переход к SAFe начался с обучения сотрудников основам фреймворка. Это включало в себя обучающие курсы, тренинги и практические занятия, чтобы сотрудники по каждой роли полностью понимали философию и принципы SAFe. Это создало общее понимание среди сотрудников и помогло сформировать единую методологическую культуру в организации.
Незамедлительно сразу после обучения в августе 2023 года были запущены первые 4 ART-а (Agile Release Train). На данный момент в банке запущены в работу 7 ART, в которых участвуют 47 команд.
Одним из ключевых преимуществ SAFe является его способность синхронизировать работу множества команд разработчиков, работающих над различными частями продукта. Внедрение SAFe позволило нам эффективно управлять зависимостями между командами, синхронизировать релизы и минимизировать конфликты при интеграции кода.
Еще одним важным аспектом SAFe является его фокус на непрерывной интеграции, доставке и развертывании (CI/CD). Благодаря SAFe мы успешно внедряем автоматизированные процессы CI/CD, что позволило нам значительно сократить время от разработки функционала до его поставки на продуктивное окружение.
Кроме того, SAFe способствует повышению прозрачности и обратной связи в процессе разработки. Благодаря регулярным инспекциям и адаптациям (PI Planning, Inspect and Adapt), мы быстро выявляем проблемы и находим оптимальные решения, что помогает нам быстрее достигать целей проекта и удовлетворять потребности заказчика.
В целом, внедрение методологии SAFe в нашей организации оказалось успешным и приносит заметные выгоды. Мы улучшили сотрудничество между командами, увеличили прозрачность процессов и ускорили время до поставки продукта на рынок. Это позволяет нам эффективно конкурировать и достигать успеха в быстро меняющейся индустрии программного обеспечения.
Далее в статье мы тезисно изложим что такое SAFE.
Scaled Agile Framework, также известный как SAFe, предоставляет собой гибкий фреймворк для масштабирования процессов и проектов в организациях, плавающий в IT-вселенной на трех китах: Команда, Программа и Портфель.
Фреймворк был создан Дином Леффингуэллом в компании Scaled Agile.
В эру цифровых технологий каждый бизнес — это бизнес программного обеспечения
Одним из ключевых принципов SAFe является Lean-Agile Мышление, которое служит краеугольным камнем для применения нового способа работы и формирования новой корпоративной культуры. Именно Lean-Agile Мышление закладывает фундамент для развития гибкости бизнеса. Это мышление позволяет лидерам и агентам изменений успешно проводить трансформацию к SAFe, обеспечивая достижение целей как работниками, так и предприятием в целом.
Приверженность основным ценностям SAFe является еще одним ключевым аспектом. Эти ценности включают в себя выравнивание (со-направленность), прозрачность, уважение к людям и неустанные улучшения
Эти основополагающие убеждения являются ключевыми факторами для эффективности SAFe. Приверженность ценностям помогает направлять поведение и действия всех, кто участвует в портфеле SAFe.
Применение Lean-Agile принципов SAFe - SAFe основан на десяти фундаментальных концепциях, которые сформировались из принципов и методов Agile, бережливой разработки продуктов, системного мышления и наблюдения за успешными предприятиями. Кроме того, принципы глубоко интегрированы по всему фреймворку. Более подробно можно почитать тут
Структура SAFe включает три уровня: уровень портфеля, уровень координации и уровень команды. На уровне портфеля определяются бизнес-стратегии и приоритеты. Уровень координации обеспечивает выравнивание работы между командами и управление зависимостями. Уровень команды включает в себя кросс-функциональные группы, работающие над разработкой, тестированием и развертыванием инкрементов продукта.
| Роли участвующие на каждом уровне | ||
| Уровень портфеля | Уровень координации | Уровень команды |
|---|---|---|
| Владельцы бизнеса Владельцы решения | Менеджер продуктов (продуктовый офис) Архитектор Машинист (RTE) | Скрам-мастер Владелец продукта Разработчики (Специалисты) |
Владельцы Бизнеса — это небольшая группа заинтересованных лиц, которые несут основную бизнес и техническую ответственность за управление, соответствие требованиям и окупаемость инвестиций (ROI) для Решения, разработанного
Релизным Поездом (Agile Release Train, ART). Они являются ключевыми стейкхолдерами в Аgile Release Тrain, которые должны оценивать пригодность продукта/решения для использования и активно участвовать в определенных мероприятиях
Релизного Поезда Аgile.
Продуктовый Менеджмент отвечает за содержание, владея Беклогом Поезда(беклогом Фич) и определяя, что и когда идет в работу на основе исследований рынка и потребностей клиентов.
Команда Архитекторов определяет общую архитектуру для системы и оказывает техническую поддержку командам поезда, отвечает за согласованность между технологиями и продуктовым содержанием.
Release Train Engineer способствует эффективной доставке ценности, оптимизируя поток ценности, проходящий через поезд. RTE отвечает за должную механику внутренней работы поезда в части Lean-Agile принципов и практик,
фасилитирует процессы и мероприятия уровня поезда, отслеживает и помогает в устранении организационных препятствий на пути повышения его эффективности.
Владелец Продукта (ProductOwner, PO) – отвечает за содержание беклога команды, а также за определение историй и расстановку приоритетов в беклоге.
Agile/ScrumКоманды (Agile/ScrumTeams) – это кросс-функциональные группы из 5-11 человек, которые могут определять, разрабатывать, тестировать и развертывать инкремент ценности за короткий промежуток времени. Каждый Agile Release Train состоит из 5 до 12 Agile
команд (примерно 50-125 человек) и включает в себя роли и инфраструктуру, необходимые для доставки полностью работающих и протестированных бизнес-решений.
Scrum Master/Team Coach – является лидером-слугой и коучем agile-команды. Скрам Мастер помогает команде устранять препятствия, фасилитирует командные мероприятия и способствует созданию среды для высокоэффективных команд.
| менеджер продукта | Владелец продукта |
|---|---|
| Владеет бэклогом программы | Владеет бэклогом команды |
| Определяет фичи, релизы | Определяет итерации и истории |
| Владеет видением. дорожной картой, ценоопределением, лицензированием и возвратом от инвестиций (ROI) | Фокусируется и поддерживает установленное виденье, дорожную карту, ROI |
| Взаимодействует с архитекторами в контексте технических решений | Принимает инкремент итерации |
| Фокусируется на том чтобы построить правильный продукт | Фокусируется на балансировании между построить правильный продукт и построить продукт правильно |
Планирование инкремента продукта (Pi planning) — это регулярное мероприятие, призванное синхронизировать все команды, работающие над одним продуктом, и помочь им придерживаться общей миссии и видения. Обычно представляет собой двухдневную
рабочую сессию. В ходе PI Планирования определяются эпики, фичи и пользовательские истории, которые будут включены в работу.
Эпики – это значительные инициативы предприятия по разработке решений. Бизнес-Эпики ориентированы на клиентов.
Энейблер-Эпикисоздают технические возможности для реализации бизнес-задач.
**(Бизнес) Фича ** — это функциональность решения, которая доставляет бизнес ценность и удовлетворяет потребности заинтересованных лиц.
**Фича-Энейблер ** — это технические возможности для реализации функциональности решения.
Пользовательские Истории — это краткие описания небольшой части желаемой функциональности, написанной на языке пользователя.
Истории-Энейблеры создают основу для будущих пользовательских историй.
<ac:image ac:height="250"><ri:attachment ri:filename="Снимок экрана 2024-02-28 164857.jpg"></ri:attachment></ac:image>
Инспект-Адапт (Inspect and Adapt, I&A) — значимое событие, происходящее в конце каждого Инкремента Программы (PI), где поездом (ART) демонстрируется и оценивается текущее состояние Решения. После этого команды обсуждают и идентифицируют элементы бэклога улучшений в рамках структурированной Мастерской Решения Проблем (Problem Solving Workshop).
Демонстрация Системы (System Demo) — представляет собой важное событие, которое позволяет увидеть новые интегрированные Фичи по результатам последней Итерации всех команд, находящихся в Релизном Поезде Agile (ART). Каждая демонстрация позволяет заинтересованным лицам (stakeholders) ART объективно измерить прогресс во время Инкремента Программы (PI).