Safe что это

SAFe или Scaled Agile Framework

Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.

Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?

Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.
Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Есть попытки использовать SCRUM на уровне управления SCRUM командами (так советует делать Jeff Sutherland — один из авторов Agile manifesto), есть Large Scale Scrum, есть Disciplined Agile Delivery, есть много еще что, но еще есть SAFe — Scaled Agile Framework.

SAFe — это фреймворк для управления компанией в которой требуется координация работы над некоторым проектом или связанными проектами для 5 или более SCRUM командами. Т.е. это некая надстройка над SCRUM позволяющая управлять коллективами из 100 и более человек

Выгода?

В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами. На эту тему неплохо высказался Dave Thomas (еще один из авторов Agile manifesto) На GOTO 2015 в своей презентации Agile is Dead

Во-вторую очередь отделы управления программами. Те, кто раньше занимался управлением проектами, получали PMP сертификации, рисовали диаграммы Гантта и реализовывали концепцию твердо-мягкого управления (мягкой стороной к руководству и твердой к исполнителям). Дело в том, что в типичном SCRUM для них нет функции, в SAFe — есть. То же самое относится к разного рода архитекторам. В SCRUM для них нет функции в SAFe — есть карьерный путь.

Далее — это может быть выгодно тем владельцам бизнеса, где управляющие работают над большими, пожирающими огромное количество человеко-часов проектами и не могут (иногда по объективным причинам) сделать эти проекты независимыми.

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

В целом индустрии. Т.к. количество разработчиков удваивается каждые 5 лет (см. uncle bob’s future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.

Суть

SAFe — это слоеный пирог из различных методик Agile. На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. Хотя есть одно ключевое отличие. Команда перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. Т.е. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).

На следующем уровне у нас поезда — так называемые Agile Release Train. Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.

Над уровнем поездов у нас координация между отделами, директорами, и клиентом. Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Здесь проводится анализ экономической целесообразности изменений. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Для компаний менее миллиарда долларов — это может быть самый последний этаж. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.)

Над уровнем больших систем идет управление портфолио. Распределяются средства на различные направления в бизнесе. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Здесь принимаются решения о покупке или слиянии с другими компаниями. Создание новых направлений бизнеса, закрытие старых. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.

Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.

Плюсы

1. Значительно количество весьма неплохих инструментов (WSJF, Kanban, Gemba, etc)
2. Формализируются и прописываются шаги для SDLC начиная от написания кода (предписывается TDD) заканчивая выполнения статического сканирования и CI/CD и feature toggle. Хороша каждая из практик или нет — другой вопрос, но по крайней мере есть план и все ему следуют.
3. Процесс можно понять, объяснить и внедрить.
4. Каждый человек в рамках этого процесса, получает достаточно строго определенную функцию.
5. Повышается прозрачность компании для тех, кто в ней работает.

Недостатки

1. Достаточно длительное время реагирование на несоответствие реальности ожиданиям
2. Огромное количество средств и денег тратится на коммуникацию и собрания
3. Часто рекомендуемые решения в рамках фреймворка уже устарели

Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.

Фреймворк Scaled Agile Framework (SAFe)

Scaled Agile Framework / SAFe – это agile-фреймворк для работы с больших командой от 50 человек.

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

История SAFe

В 2011 году структура SAFe получила признание в мире продуктов. Ветеран индустрии программного обеспечения Дин Леффингвелл, автор книги «Требования к гибкому программному обеспечению», первоначально называл фреймворк SAFe «общей картиной гибкого предприятия». «Общая картина» описывает, как использовать существующие гибкие структуры, такие как Lean, Kanban, Scrum и XP, и применять их в команде, программе и портфолио.

Сегодня весь каталог знаний и примеров успеха SAFe доступен бесплатно. SAFe остается одним из самых популярных гибких фреймворков.

Каковы принципы гибкой разработки SAFe?

Прежде всего, SAFe основывается на таких основополагающих принципах:

Управление проектами SAFe

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

У небольших команд есть определенные цели и зоны ответственности. Поэтому они выпускают итерации после каждого спринта. Более того, Скрам-мастер обычно возглавляет обвинение. Единственное существенное изменение состоит в том, что теперь эти небольшие команды объединяются в программы.

На программном уровне преимущества SAFe начинают проявляться. Именно здесь результаты каждой команды должны объединяться с результатами всех остальных во что-то взаимодополняющее, связное и последовательное.

Под руководством инженера Release Train они объединяются в Agile Release Train. Синхронность обеспечивает работу группы отдельных Scrum-команд. Примерно через пять спринтов потенциально доступный для доставки инкремент проходит полный цикл тестирования. Этот процесс представляет собой отход от более традиционных Scrum и Continuous Delivery. В этом случае код доставляется очень часто.

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

Масштабируемая Agile

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

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

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

Например, все различные приложения Microsoft Office хорошо выполняют свои индивидуальные функции, но еще более успешным пакет делает тот, насколько легко пользователи могут переходить от одной программы к другой с ограниченной кривой обучения благодаря общему UX. Если бы команда Word и команда Excel работали на 100% независимо, не прошло бы много времени, пока каждая из них вела бы себя совершенно по-разному.

Scaled Agile обеспечивает этот уровень управления и координации для создания сложных решений, которые слишком велики и сложны для одной команды Scrum. Это может быть вызвано срочностью вывода решения на рынок или просто тем, что сам продукт слишком велик и сложен.

SAFe® на русском языке

Scaled Agile Framework® (SAFe®) — лидирующий в мире подход обеспечения Business Agility для крупных компаний. В этой статье навигатор в мире SAFe на русском: статьи, видео, термины, кейсы компаний и сообщество практиков. Напишите, если мы что-то забыли добавить в него.

Дорожная карта внедрения SAFe®

SAFe Implementation Roadmap — полностью на русском! ?Нажмите на изображение, чтобы открыть его крупнее. Скачайте дорожную карту внедрения: PDF | PNG.

Общая картина SAFe®

SAFe Big Picture — весь фреймворк как на ладони!

?Нажмите на изображение, чтобы открыть его крупнее.

Скачайте постер: Полный SAFe (PDF | PNG), Портфельный SAFe (PDF | PNG), SAFe Крупного Решения (PDF | PNG), Базовый SAFe (PDF | PNG).

Видеоролики про SAFe®

?Это целый плейлист, кнопка навигации по отдельным видеороликам находится в правом верхнем углу.

Статьи про SAFe®

1. Основы SAFe

• Лидеры Lean-Agile
• Ключевые ценности
• Мышление Lean-Agile
• Обзор принципов SAFe

• Достижение переломного момента
• Обучение агентов изменений
• Обучение руководства, менеджеров и лидеров
• Создание центра экспертизы Lean-Agile
• Определение Value Streams и ARTs
• Создание плана внедрения
• Подготовка к запуску ART
• Обучение команд и запуск ART
• Сопровождение и коучинг ART
• Запуск следующих ARTs и Value Streams
• Расширение до портфеля
• Улучшение и развитие

• Принцип #1. Экономический взгляд
• Принцип #2. Применяйте системное мышление
• Принцип #3. Предполагайте изменчивость, сохраняйте опции
• Принцип #4. Инкрементальные поставки с быстрыми циклами обучения, встроенными в процесс
• Принцип #5. Вехи определяются только объективной оценкой работающих систем
• Принцип #6. Визуализируйте и ограничивайте WIP, уменьшайте размер порций работ и управляйте длиной очередей
• Принцип #7. Применяйте каденции, синхронизируйтесь кросс-доменным планированием
• Принцип #8. Задействуйте внутреннюю мотивацию сотрудников
• Принцип #9. Децентрализуйте принятие решений
• Принцип #10. Организация вокруг ценности

• Agile-команды
• Команда разработки
• Владелец продукта
• Scrum-мастер
• Встроенное качество
• ScrumXP
• История
• Итерации
• Планирование итерации
• Цели итерации
• Выполнение итерации
• Обзор итерации
• Ретроспектива итерации
• Бэклог команды
• Kanban команды

• Базовый SAFe
• Agile Release Train
• Представители бизнеса
• Продуктовый менеджмент и менеджмент решения
• Release Train Engineer
• Системный архитектор/инжиниринг и архитектор/инжиниринг решения
• Бэклоги программы и решения
• Фичи и возможности
• Enablers
• Нефункциональные требования
• Weighted Shortest Job First
• Инкремент программы
• Итерация инноваций и планирования (IP-итерация)
• Разработка каденциями
• Релиз по потребности
• Архитектурная полоса
• PI-планирование
• PI-цели
• Системная демонстрация
• Инспекция и адаптация
• Kanban программы и решения
• DevOps
• Конвейер непрерывной поставки
• Непрерывное изучение
• Непрерывная интеграция
• Непрерывное развертывание

• Измеряй и развивай
• Искусственный интеллект
• Метрики
• Общие сервисы
• Профессиональные сообщества
• Вехи
• Дорожная карта
• Концепция
• Системная команда
• Lean UX

• Solution Train
• Solution Train Engineer
• Заказчик
• Поставщик
• Экономический фреймворк
• Предварительное и заключительное PI-планирование
• Системная демонстрация
• Контекст решения
• Solution Intent
• Compliance
• Вариативное проектирование

• Портфельный SAFe
• Корпорация
• Value Streams
• Стратегические темы
• Lean-бюджеты
• Инициативное бюджетирование
• Эпик
• Владельцы эпиков
• Корпоративный архитектор
• Lean-управление портфелем
• Концепция портфеля
• Бэклог портфеля
• Kanban портфеля
• Координация Value Streams

• 6 практик SAFe для небольших команд
• Agile HR
• Agile-архитектура в SAFe®
• Agile-контракты
• Agile-подход к Big Data в SAFe®
• Agile-тестирование
• Behavior-Driven Development
• CapEx и OpEx
• SAFe для маркетинга
• SAFe в разработке аппаратного обеспечения
• Spikes
• Баланс двойной операционной системы
• Бизнес-гибкость
• Бизнес и технологии
• Вовлекающее внедрение SAFe
• Как работать по Agile с распределенными командами?
• Коктейль Waterfall и Agile на масштабе: технарский взгляд SAFe®
• Модель требований SAFe
• Обеспечение непрерывного потока ценности
• Применение Kanban в Scaled Agile Framework
• Применение OKR в Scaled Agile Framework
• Проектирование Agile-команд и ARTs: топология команд на масштабе
• Распределенное PI-планирование
• Рефакторинг
• Роль PI-целей
• Сначала тест
• Управление потоком ценности в SAFe®
• Ускорение потока с помощью SAFe®
• Фичи и компоненты
• Эволюция роли менеджера в SAFe®

Статьи без ссылок — это то, что мы еще не успели перевести. Если вы хотите помочь нам, присоединяйтесь к сообществу практиков SAFe.

Термины SAFe®

Глоссарий SAFe®: каждый термин доступен по отдельному URL, поэтому можно отправить ссылку как на глоссарий в целом, так и на отдельный термин. А также можно скачать весь глоссарий в виде брошюры (1.8 Мб, PDF).

Кейсы внедрений SAFe®

?Нажмите на изображение, чтобы открыть его крупнее.

Подробнее про то, сколько экономит SAFe® в России и о результатах внедрений в различных отраслях:

• ?ИТ: iiko, Xsolla, Kaspersky, eLama, ATI.SU.
• ?Банкинг: Deutsche Bank Technology Center in Russia, Ак Барс Банк, Хоум Кредит Банк, Сбер Банк.
• ⚖️Страхование: Ренессанс Жизнь, ВСК, Ингосстрах.
• ?Промышленность и производство: Северсталь, Газпром нефть.
• ?Ритейл: Азбука Вкуса, KFC.
• ?Госсектор: РТЛабс, Smart Consulting.

Сообщество практиков SAFe®

SAFe® Russia — это закрытый Telegram-чат, в который может вступить тот, кто имеет любой действующий сертификат SAFe: прошел тренинг и успешно сдал после этого экзамен. По вопросам вступления в чат напишите ?Сергею Рогачеву.	Enterprise Agile Russia — это открытый Telegram-канал, в котором регулярно выходят полезные публикации про разные подходы гибкого управления на масштабе, в том числе SAFe. Также в нем проходят трансляции ежемесячных бесплатных мероприятий Enterprise Agile Russia SHOW.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

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

Что такое Scaled Agile Framework (SAFe)?

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

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

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

• Принципы Lean-Agile: SAFe основана на принципах Agile Manifesto и Lean-мышления, которые фокусируются на предоставлении ценности клиентам, адаптации к изменениям и постоянном совершенствовании процессов.
• ARTs (Agile Release Trains, Поезда): SAFe рекомендует организовывать agile-команды в поезда, которые представляют собой группы команд, работающих вместе для предоставления ценности клиентам. Поезда следуют последовательности регулярно запланированных встреч по планированию, выполнению и обзору, известных как «итерации» или «спринты».
• Бережливое управление портфелем: SAFe рекомендует использовать Lean Portfolio Management для согласования стратегии, инвестиций и исполнения на уровне портфеля. Это включает в себя постановку четких целей и задач, определение и приоритизацию потоков ценности, а также выравнивание ресурсов для предоставления ценности клиентам.
• Лидеры Lean-Agile: SAFe рекомендует развивать Lean-Agile лидеров на всех уровнях организации, которые отвечают за внедрение принципов и практики Lean-Agile. К таким лидерам относятся руководители, менеджеры и лидеры команд, которые совместно работают над созданием культуры непрерывного совершенствования.

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

Agile Release Train (ART, Поезд)
Agile Release Train или Поезд — это группа agile-команд, которые работают вместе для предоставления ценности клиентам. Поезд следует последовательности регулярно запланированных встреч по планированию, выполнению и обзору, известных как «итерации» или «спринты». Цель Поезда — скоординировать работу нескольких agile-команд и дать им возможность предоставлять ценность клиентам предсказуемым и последовательным образом.

Метафора Поездов являются ключевой особенностью SAFe, и они разработаны для того, чтобы помочь организациям масштабировать agile-практики на большие, сложные проекты. Каждый поезд состоит из нескольких agile-команд, которые работают вместе, чтобы каждую итерацию предоставлять потенциально выпускаемый прирост ценности для клиентов. Поезд также включает в себя ряд вспомогательных функций, таких как Инженер по подготовке релизов (RTE), который отвечает за содействие планированию и выполнению поезда, и менеджер продукта, который отвечает за определение и приоритезацию работ, которые должны быть выполнены в рамках поезда.

Цель концепции Поездов (ART) — дать возможность организациям быстрее и эффективнее предоставлять ценность клиентам за счет согласования стратегии, исполнения и доставки в рамках всей организации.

Бережливое управление портфелем
Бережливое управление портфелем — это метод согласования стратегии, инвестиций и исполнения на уровне портфеля. Оно основано на принципах Lean, которые фокусируются на максимизации ценности и минимизации отходов. В контексте Scaled Agile Framework бережливое управление портфелем включает в себя определение четких целей и задач портфеля, выявление и приоритизацию потоков ценности, а также выравнивание ресурсов для обеспечения ценности для клиентов.

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

Цель Lean Portfolio Management — помочь организациям быстрее и эффективнее доставлять ценность клиентам, согласовывая стратегию, исполнение и доставку в рамках всей организации. Это ключевая особенность SAFe, которая призвана помочь организациям масштабировать гибкую практику на крупные, сложные проекты.

Лидеры Lean-Agile
Лидеры Lean-Agile — это люди, которые отвечают за внедрение принципов и практики Lean-Agile в организации. В контексте Scaled Agile Framework лидеры Lean-Agile отвечают за создание культуры непрерывного совершенствования и позволяют командам быстрее и эффективнее предоставлять ценность клиентам.

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

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

1. Улучшение способности предоставлять ценность клиентам: SAFe помогает организациям быстрее и эффективнее предоставлять ценность клиентам за счет согласования стратегии, исполнения и доставки в рамках всей организации. Это может привести к сокращению времени выхода на рынок и повышению удовлетворенности клиентов.
2. Улучшение координации и сотрудничества: SAFe помогает командам работать вместе более эффективно, обеспечивая основу для координации работы нескольких agile-команд и позволяя им предоставлять ценность предсказуемым и последовательным образом.
3. Повышение гибкости и адаптивности: SAFe разработана для гибкости и адаптивности к изменениям, что помогает организациям быстрее реагировать на изменение рыночных условий и потребностей клиентов.
4. Повышение качества: SAFe способствует концентрации на техническом совершенстве и хорошем дизайне, что может привести к повышению качества программного обеспечения и снижению количества дефектов.