Что такое SAFe: как применять фреймворк в Agile

В крупных компаниях процесс разработки в ИТ-проектах замедляется из-за согласований со множеством стейкхолдеров и смежных команд. Координировать участников проекта и сохранять гибкость помогает Scaled Agile Framework. Рассказываем, как работает фреймворк и кому будет полезен.

Что такое Scaled Agile Framework

Scaled Agile Framework (SAFe) — это набор принципов и практик, способных трансформировать управление проектами в больших компаниях. Проверенные подходы из гибких методологий ИТ-разработки масштабируются на всю организацию, чтобы синхронизировать работу десятков и сотен команд, которые применяют Agile и Waterfall.

Цели SAFe:

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

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

SAFe и другие подходы: сходства и различия

Разберем особенности Scaled Agile Framework, сравнив с другими методологиями и практиками, которые широко применяются в управлении проектами.

Таким образом, SAFe помогает объединить многочисленные, по-разному работающие команды на основе общей цели — доставка ценности.

Когда внедрять SAFe

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

Признак 1. «Война команд» и локальная эффективность. Все хорошо работают по отдельности, но усилия не складываются в целостный результат. Каждая команда заинтересована только в быстром выполнении собственной части работы, а не в доставке ценности конечному пользователю.

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

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

Признак 4. Снижение качества. Из-за спешки и отсутствия координации накапливается технический долг, который со временем замедляет разработку. Отсутствие единых стандартов качества негативно влияет на продукт.

Признак 5. Хронические срывы сроков. Команды вовремя завершают свои спринты, но интегрировать результат работы в стабильный релиз не удается месяцами.

Признак 6. Неудовлетворенность сторон. Бизнес-заказчики не получают запланированный функционал вовремя. Обратная связь от пользователей не сразу попадает к разработчикам, которые занимаются соответствующим аспектом продукта.

Внедрять фреймворк стоит постепенно, в зависимости от текущих целей, потребностей и проблем.

Как начать использовать SAFe

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

Конфигурация Essential SAFe

Подходит для первичного внедрения, например, в ИТ-отделе крупной компании. Будет эффективно, если команды уже работают по Agile.

Ключевые элементы Essential SAFe:

• Agile Release Train (ART) — объединение нескольких команд. Они работают синхронно, занимаются разработкой и поддержкой одного и более продуктов. Обычно в ART входит от 5 до 12 команд. В каждой не менее 50 и не более 125 участников. Команды используют Scrum, Kanban или гибридные подходы.
• Release Train Engineer (RTE) — аналог скрам-мастера, только на уровне целого ART.
• Planning Interval (PI) — промежуток времени, за который ART создает ценность. Обычно длится 8–12 недель.
• Iteration — фиксированный отрезок продолжительностью 2–4 недели, аналог спринта в Scrum. Команды, состоящие в одном ART, соблюдают одинаковую длину итераций, чтобы иметь возможность синхронизироваться.
• IP Iteration — особая итерация в конце каждого PI, посвященная инновациям, планированию и обучению.
• SAFe Scrum — практики реализации скрам-методов в рамках фреймворка SAFe для доставки ценности в сжатые сроки. Команды применяют итерации, системы Kanban и события Scrum.
• PI Planning — ключевое двухдневное мероприятие, на котором все команды ART собираются вместе (виртуально или физически), чтобы синхронизировать видение, спланировать следующий PI и выявить риски.
• System Demo — демонстрация стейкхолдерам результатов, достигнутых ART в последней итерации. Здесь важно показать, что новые функции действительно работают, а не просто отчитываться об отдельных фрагментах, выполненных каждой командой.

Фреймворк активно использует понятия и практики из других методологий: Continuous Delivery Pipeline (конвейер непрерывной доставки), Value Stream (поток создания ценности), Design Thinking (дизайн-мышление), Lean UX (бережливый UX), Customer Centricity (клиентоориентированность).

Внедрять в практику проектов фреймворк SAFe можно, даже если команды привыкли работать по совершенно разным методологиям

Конфигурация Large Solution SAFe

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

Элементы, которые добавляются в Large Solution:

• Supplier — организация, которая поставляет важные ресурсы для ART, встроена в общий процесс, но не обязательно работает по гибкой методологии.
• Solution Train — объединение нескольких ART для достижения общей цели. Также участвует Supplier, один или несколько.
• Solution Management — лучшие практики управления деятельностью Solution Train.
• Pre-Plan — крупное планирование на уровне Solution Train, в котором участвуют все ART, поставщики, партнеры. По итогам Pre-Plan каждый ART проводит локальный PI Planning.
• Solution Demo — демонстрация работы системы на основе результатов, которые совместно достигли участники Solution Train.

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

Конфигурация Portfolio SAFe

Необходима, когда требуется централизованно управлять несколькими продуктами или направлениями бизнеса, объединенными в один портфель. Эта конфигурация помогает выстроить работу разных сегментов в соответствии с общей стратегией компании, учесть рыночные условия и эффективно распределить ресурсы. Сюда включают:

• Strategic Theme — направление развития всей компании, которое учитывается при планировании и принятии решений.
• Lean Portfolio Management — набор практик для гибкого управления портфелем проектов. Они направлены на оптимизацию ресурсов и непрерывную доставку ценности.
• Epic Owner — руководитель, ответственный за крупные инициативы (эпики).

Конфигурация Full SAFe

Подходит очень крупным организациям, в которых тысячи сотрудников работают на сложных проектах. Для управления используются все элементы Essential, Large Solution и Portfolio. К этой конфигурации лучше подходить, когда последовательно внедрены остальные.

Full SAFe позволяет бизнесу:

• планировать на уровне портфеля, выделять стратегическую тему (Strategic Theme), продумывать эпики;
• масштабироваться при необходимости, создавать новые команды, ART и Solution Trains, добавлять поставщиков (Suppliers);
• поддерживать непрерывную доставку ценности на всех уровнях управления разработкой.

Как SAFe помогает управлять рисками, сроками, ресурсами

Мероприятие PI Planning — это основа планирования по методологии SAFe. Команды-участники ART, менеджеры и бизнес-заказчики регулярно собираются, чтобы провести детальное двухдневное планирование на следующий период. В результате получают:

• Согласование плана — все команды знают, что делать, и видят зависимости между разными частями продукта.
• Контроль ресурсов — специалисты закреплены за своими ART и командой, бюджет выделяется на конкретный Value Stream (поток создания ценности).
• Прогнозирование ожиданий — бизнес понимает, что будет сделано в ближайшие месяцы.
• Визуализация рисков — возможные препятствия выносятся на доску и берутся на контроль.

Методология SAFe помогает выявлять риски проактивно на всех этапах разработки проекта. Обычно новое препятствие обнаруживается в ходе PI Planning, ежедневных стендапов команд, отдельного мероприятия Inspect and Adapt. Каждому риску присваивается приоритет и соответствующая маркировка в зависимости от вероятности и силы воздействия: красный, желтый, зеленый цвет. Назначается владелец, создается план по смягчению. Процесс отслеживается на протяжении всего PI.

Управление сроками и ресурсами в SAFe продумано с учетом большого количества команд и сложности создаваемого продукта. Все интервалы работы имеют фиксированную длительность: итерации по 2 недели, PI от 8 до 12 недель. При этом содержание гибкое: если становится ясно, что для достижения всех запланированных целей в срок не уложиться, то владелец продукта и бизнес-заказчики совместно с ART уменьшают объем задач. Например, убирают менее важные фичи, чтобы успеть доделать критичную функциональность.

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

Какие проблемы решает SAFe в крупных компаниях

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

Кейс 1. Представим, в крупном банке команда мобильного приложения планирует выпустить новую функцию «Быстрый платеж». Команда бэкенда разрабатывает серверную логику, настраивает интеграцию с платежными системами, отлаживает механизм мгновенного зачисления средств. Команда ИТ-безопасности обновляет протоколы аутентификации, внедряет биометрию и двухфакторную аутентификацию для подтверждения операций.

До внедрения SAFe. Три команды не обсудили планы и не составили общую дорожную карту. В итоге мобильные разработчики готовы к релизу, но тут может выяснится, что бэкенд не поддерживает нужные API, а новые протоколы безопасности блокируют работу созданной функции.

После внедрения SAFe. Три команды объединяются в ART и встречаются на PI Planning. Менеджер продукта озвучивает общую цель: «Упростить процесс перевода денег для клиентов». ART совместно прорабатывает зависимости: мобильные разработчики создают интерфейс, бэкенд-команда настраивает API, специалисты по ИТ-безопасности проверяют и согласовывают выбранную технологию. Это визуализируется на общей доске планирования. В результате создается целостный план на следующий PI, и все команды в курсе, что и когда будут делать.

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

До внедрения SAFe. Допустим, что обновление продукта происходит дважды в год. Процесс требует согласования со множеством департаментов:

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

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

После внедрения SAFe. Компания использует практики DevOps и CI/CD, масштабированные на всех участников ART. Создаются автоматизированные конвейеры сборки, тестирования и развертывания. Тестирование становится непрерывным процессом, встроенным в процесс разработки. Отменяется один большой релиз раз в полгода. Вместо этого ART каждые несколько недель поставляет небольшие элементы функциональности, несущие ценность для клиентов. Это сокращает цикл обратной связи, повышает управляемость и снижает риски.

Кейс 3. Представим, федеральную страховую компанию, где руководство объявляет новую стратегическую цель: «Стать лидером в области цифрового страхования жизни через запуск персонализированных продуктов с использованием ИИ».

До внедрения SAFe. Допустим, команды разработки заняты преимущественно мелкими исправлениями в легаси-системах: баг с отображением неактуальной информации в справочной системе у службы поддержки, отсутствие фильтрации холодных контактов в CRM-системе, ошибка при генерации определенного типа документа в системе оформления договоров. Задачи в бэклог поступают от руководителей среднего звена, которые не видят общей картины и ориентируются только на KPI своих департаментов. Таким образом, стратегия бизнеса не доходит до исполнителей.

После внедрения SAFe. Создается Strategic Theme (стратегическая тема) «Цифровое лидерство». На ее основе планируются крупные инициативы, или эпики. Например, «Разработать онлайн-платформу для удобного заключения договоров страхования жизни». Эпики попадают в бэклог соответствующего Value Stream (потока создания ценности), который обслуживается одним или несколькими ART. Менеджер продукта в ходе PI Planning доносит цели компании до всех команд в виде конкретных фич, которые нужно реализовать. Теперь разработчики понимают, каким образом каждая локальная задача связывается с общей стратегией компании.

К выводам

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

Планируете внедрить новый подход или использовать практики из разных методологий? Naumen Project Ruler позволит эффективно управлять проектами, продуктами, портфелями, программами.

Что еще интересного