Координировать процесс разработки одной небольшой команды бывает очень непросто, а теперь представим, что над одним крупным проектом работает десять разных команд. На кону не только ответственность, но и круглые суммы, поэтому от взаимодействия подразделений зависят сроки, достижение цели и окупаемость. В таком случае на помощь приходит фреймворк SAFe®, который синхронизирует десятки разных команд и помогает им не сбиться с пути.
Что такое SAFe и кому он нужен
SAFe (Scaled Agile Framework® — фреймворк для масштабирования Agile. Его цель — объединить работу команд, которые задействованы в одном большом проекте, но при этом используют разные подходы и практики в управлении проектами, даже негибкие
Общие принципы, роли и практики связывают рабочий процесс с целями бизнеса и описывают, как планировать, принимать решения и проверять результат на уровне команд, их объединений и портфеля проектов.
🏆 Как масштабироваться, если ты новичок, а на дворе кризис
→ Отрываем от сердца руководство к действию от опытных проджектовSAFe объединяет лучшие практики трёх подходов к управлению проектами:
Менеджеры пытаются преодолеть сложности с синхронизацией, зависимостями и расстановкой приоритетов, а топ-менеджеры видят, как из-за этого стратегия не превращается в результат, поставляемый клиенту и бизнесу. Когда мне говорят об этом, я предлагаю попробовать решения SAFe, проверенные временем и другими компаниями
а процессы нет?
работу в Weeek и держать прогресс
перед глазами
Как устроен SAFe: команды, роли и планирование
SAFe начинается с потока поставки ценности — то есть пошагового, предсказуемого, равномерного и непрерывного процесса, который проходит идея или инициатива до того, как стать полезной для потребителя.
Существует два вида потока — операционный и разработки. Первый показывает, как клиент получает ценность. Например, оформляет заказ, оплачивает его и принимает доставку. Второй — как команды улучшают системы, которые это обеспечивают: приложение, платёжный сервис и систему доставки.
Роли
В потоке разработки работают один или несколько ART (Agile Release Train) — устойчивое объединение Agile-команд, которые развивают один продукт и следуют общему направлению. Обычно в одном «поезде» от 5 до 12 кросс-функциональных команд. Количество участников — от 50 до 125 человек, которые обладают компетенциями, необходимыми для разработки, проверки и выпуска конкретного продукта.
Кроме ART, в SAFe есть и другие роли. Собрали список с описанием задач ниже.
| 🤓 Роль | 💪 Задачи |
|---|---|
| RTE — Release Train Engineer | Ключевая фигура в SAFe. Отвечает за синхронизацию команд внутри одного ART, организует общие события, помогает разбирать препятствия в работе и просчитывает риски. Может выступать в роли Agile-коуча |
| Product Management — менеджер продукта | Определяет продуктовое направление работы ART — то есть связывает задачи с бизнесом и рынком. Задаёт стратегию работы и решает, какие потребности пользователей есть сейчас, что включать в дорожную карту и в каком порядке выполнять задачи из бэклога |
| System Architect — системный архитектор | Отвечает за единое архитектурное и техническое видение продукта для всего ART. Следит за тем, чтобы все решения соответствовали бизнес-стратегии. Участвует в развитии инструментов, которые помогут ART быстрее и надёжнее доставлять ценность потребителю. Активно взаимодействует не только с командами ART, но и с другими участниками процесса |
| Business Owners* — представители бизнеса *Не путать с Product Owner — у этой роли похожие задачи, но только внутри одной команды | Представляют бизнес-сторону: объясняют контекст, участвуют в обсуждении планов и оценивают бизнес-ценность целей во время их планирования и помогают определиться, какие из них действительно важны |
Вот так схематично может выглядеть процесс разработки SAFe: от потребности пользователя до конечного результата.
Планирование
Все участники ART перед началом работы встречаются на совместном планировании PI, то есть интервала планирования (Planning Interval или PI), размер которого от 8 до 12 недель.
Планирование PI длится около 2 дней. В это время команды ATR разбираются в контексте бизнеса, приоритетах, определяют риски и технические ограничения, которые могут возникнуть на этапе разработки. Здесь же обсуждают, смогут ли команды потянуть объём работы, — то есть определяют их доступную ёмкость с учётом состава и других обязательств.
Далее согласуют цели на ближайший квартал (примерно 12 недель), определяют зависимости и приоритеты задач, а затем разбивают большую работу на короткие итерации и назначают исполнителей. Результат можно выпускать в течение PI, ждать его завершения ради релиза не требуется.
Цели PI должны нести ценность для пользователя, быть понятными каждому участнику рабочего процесса и отображать конкретный результат, желательно с цифрами.
Цели PI, планы работы команд, зависимости, риски и вехи отображаются на общей доске планирования ART (ART Planning Board), благодаря которой команды могут видеть работу других участников и отслеживать процесс. Доска планирования не похожа на привычную Канбан-доску, потому что у неё другое назначение.
Канбан-доска показывает этапы, через которые проходят задачи, а доска планирования ART — зависимости команд, сроки внутри интервала планирования и контрольные точки. Но использовать Канбан-доску для планирования работ никто не запрещает.
Core SAFe и четыре конфигурации SAFe 6.0
Core SAFe — базовые принципы и практики для объединения команд, а четыре конфигурации SAFe — прикладные решения, которые помогут адаптировать фреймворк под задачи и масштабы координации команд.
| 🔩 Конфигурация | 👉 Когда подходит | 🤌 Какую координацию добавляет |
|---|---|---|
| Essential — фундамент, от которого можно отталкиваться | Нужно согласовать работу команд внутри ART | Базовые роли и события, цели PI, общий план и проверку совместного результата |
| Large Solution | Несколько ART работают над одним сложным проектом | К Essential добавляет Solution Train — согласование нескольких ART, общей архитектуры и интеграции решения |
| Portfolio | Если у компании несколько направлений бизнеса, которые связаны друг с другом, и нужно определиться, в какой проект вкладывать деньги в первую очередь | К Essential добавляет Lean Portfolio Management — инвестиционные приоритеты, финансирование и управление крупными инициативами. Здесь разработка тесно связана с бизнесом |
| Full | Нужны одновременно управление портфелем и координация нескольких ART | Объединяет Essential, Large Solution и Portfolio, связывает инвестиции с работой ART и Solution Trains |
Чем SAFe отличается от Scrum и других подходов
В основе SAFe — Agile-методология, но адаптированная под большую организацию, где над продуктом может работать множество разных команд. Они в свою очередь могут внедрять фреймворки Agile — например Scrum или Kanban-метод.
Scrum описывает, как одна команда работает над сложным продуктом: выбирает цель спринта, создаёт полезный результат, проверяет его и меняет дальнейший план. Kanban-метод отвечает за управление потоком задач, их жизненный цикл и устранение потерь во время рабочего процесса. Фреймворки можно объединять, если считаешь это необходимым.
SAFe смотрит на работу нескольких команд в рамках портфеля: добавляет правила согласования и управления крупными и сложными проектами.
Если в проекте задействована одна команда, то она не может использовать SAFe, даже если работает по гибким методологиям, потому что фреймворк подразумевает совсем другие масштабы.
Как работает SAFe на примере нескольких команд
Над проектом работает множество ИТ-команд: навигация и сенсоры, идентификация товаров, логика, интеграция с корпоративными системами, аналитика и т. п. В рамках SAFe бизнес и ИТ-команды совместно планируют работы на квартал. Сначала согласовывают общую цель, к примеру, реализовать базовые сценарии обхода, позволяющие разгрузить склады на 30%. Затем в связке с целью каждая команда планирует реализацию необходимого функционала. Далее команды согласовывают зависимости между собой и выбирают компромиссы вместе с бизнесом
Внутри квартала работа идёт 2-недельными итерациями. Команды регулярно сверяют промежуточный общий результат и оценивают, насколько они приблизились к желаемому результату квартала — разгрузке склада на 30%. Итерации позволяют быстро корректировать работу. Таким образом, стратегия согласовывается с тактическими планами, а регулярная сверка позволяет быстрее реагировать на изменения и достигать поставленных целей
Как внедрить SAFe: от диагностики до пилота
В официальной дорожной карте внедрения есть пункты о подготовке руководителей и команд, организации вокруг ценности, запуске ART и сопровождении его работы. Ниже — примерный план для первого пилота, который можно взять за основу, но шаги могут различаться в зависимости от масштаба компании.
Во-первых, определить конкретную бизнес-проблему и ожидаемый результат пилота, а не просто поставить цель «внедрить SAFe»
Во-вторых, выбрать поток ценности и состав ART, определить участников, роли, границы ответственности и лидеров изменений
В-третьих, заранее договориться, по каким объективным данным мы поймём, что пилот работает: какие изменения должны произойти в скорости поставки, качестве, производительности и бизнес-результатах
Шаг 1: определить проблему и поток создания ценности
Проанализируй несколько уже завершённых проектов и оцени, как они прошли от решения о разработке до выпуска: кто участвовал, где работа буксовала и почему.
Собери представителей продукта, разработки и эксплуатации и обозначь границы потока. Если причина задержек локальная, сначала попробуй устранить её. Для пилота SAFe нужна проблема, которая требует согласованной работы команд. Мы не собираемся внедрять фреймворк просто так.
Результат шага — карта потока, сформулированная проблема и исходные показатели. Ответственность за диагностику можно закрепить за руководителем продукта или направления — именно ему предстоит оценивать, помогло ли внедрение.
Карта потока — это схема, которая показывает путь предоставления ценности конечному пользователю от концепции до получения прибыли компании. Карта может быть общей или максимально детализированной.
Официальный сайт SAFe приводит пример того, как может выглядеть упрощённая карта потока ценности для компании, которая занимается доставкой.
Отправить посылку (потребность клиента) → оформление доставки → приём или забор посылки (курьером, например) → определение маршрута доставки (пользователю) → передача посылки получателю → сверка взаиморасчётов → прибыль.
Источник: https://scaledagile.com/blog/safe-and-business-architecture
На первых этапах, возможно, придётся подключить коуча, который будет помогать командам осваивать Agile-мышление и понимать основы.
Шаг 2: согласовать поддержку руководства и состав пилотного ART
Выбери направление, где можно протестировать SAFe, и собери команды с необходимыми компетенциями — тех, кто будет разрабатывать, тестировать и выпускать решение. Также определись, с какими внешними участниками процесса предстоит договариваться.
Поддержку руководства нужно перевести в конкретные решения: сколько времени выделено людям, какие приоритеты действуют и кто снимает ограничения за пределами ART. Если участники одновременно заняты другими инициативами, это должно быть отражено в доступной ёмкости.
Результат шага: у тебя на руках чёткий состав ART, границы ответственности и договорённости о ресурсах. За решение о запуске отвечает руководитель — спонсор пилота, за подбор состава вместе с ним — руководители продуктового и технического направлений.
Шаг 3: подготовить роли, приоритеты и первое PI Planning
До планирования обсуди с участниками их полномочия и подготовь их к новым ролям. На PI Planning участники сопоставляют желаемый объём с возможностями и согласуют цели. Результат шага — выполнимый совместный план с зависимостями и рисками. За организацию отвечает RTE, за продуктовые приоритеты — Product Management, за реалистичность командных планов — сами команды.
Пилот можно запланировать в Weeek. Создать рабочее пространство и с помощью режима Доски отслеживать ход работ. Мы решили разделить пилот на три этапа — у каждого из них своя доска с задачами. Вот так это выглядит.
Шаг 4: провести PI, проверить результат и скорректировать процесс
В течение PI регулярно проверяй интегрированный продукт. Не откладывай сборку на последние дни: иначе времени исправить несовместимости может не быть. Если меняются условия, обсуждай их влияние на цели и фиксируй корректировки. Делать это нужно регулярно, чтобы ничего не упустить — для этого задачи на созвоны с командами в таск-менеджере можно сделать повторяющимися и выбрать интервал повторения. Например, ежедневно или каждую пятницу.
В конце PI подведи итоги — обсудите с командой результат, разберите показатели и причины проблем. Из обсуждения должны появиться конкретные улучшения, которые нужно доработать далее. Например, если команды ждали тестовую среду, её подготовку нужно включить в дальнейшую работу.
Результат шага — оценка целей, проверенный продукт и изменения процесса с ответственными. RTE организует разбор, команды и руководство ART определяют улучшения, а спонсор вместе с бизнес-стороной решает, как продолжать пилот и нужно ли его масштабировать.
Как оценить результат и избежать типичных ошибок
Вернись к проблеме, с которой начиналось внедрение. Если выпуск задерживался из-за зависимостей, проверь, сократилось ли время ожидания.
Ниже — примерный набор критериев, которые помогут оценить результаты пилота. Но у тебя могут быть свои, всё зависит от проблемы, которую SAFe должен решить. Периоды сравнения — ориентиры, которые стоит согласовать с командой.
| 📝 Критерий | 🔎 Как оцениваем |
|---|---|
| Время прохождения работы | Измеряй срок от начала работы до конечного результата, который уже доступен пользователям. Данные бери из истории задач и записей о релизах. Сравни среднее значение и наиболее долгие случаи за 8–12 недель до пилота и во время него. Границы измерения должны оставаться одинаковыми |
| Ожидание зависимостей | Фиксируй, когда задача заблокирована, какой результат требуется от другой команды и когда ожидание закончилось. Информацию можно найти в таск-менеджере. Проверяй её еженедельно, а общее время ожидания и долю заблокированных задач сравнивай за период до пилота и каждый PI |
| Качество интеграции | Отслеживай ошибки в коде на стыках сервисов, их серьёзность и время, когда общая сборка не работала. Источники — журнал дефектов и система автоматической сборки и тестирования. Анализируй данные после каждой итерации, сравнивай сопоставимые периоды до и после запуска |
| Достижение целей PI | Для каждой цели заранее запиши критерий приёмки, а в конце интервала — фактический результат и подтверждение бизнес-стороны. Источники — цели PI, демонстрации и результаты проверки. Сравнивай результат с планом каждого PI и отслеживай динамику за два-три интервала. Изменённые и снятые цели отмечай отдельно |
| Затраты на координацию | Учитывай время на встречи, подготовку и согласования по календарям и учёту времени. Часовая встреча двадцати участников — двадцать человеко-часов. Сравни суммарные затраты и их долю в рабочем времени до пилота и в каждом PI, а разовое обучение и запуск выдели отдельно. Учитывай также те встречи, от которых удалось отказаться |
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
