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

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

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

SAFe предоставляет структурированный подход к масштабированию agile-методик по мере роста бизнеса. SAFe имеет четыре конфигурации, подходящие для различного масштаба применения: Essential SAFe, Large Solution SAFe, Portfolio SAFe и Full SAFe.

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

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

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

В платформе SAFe гибкость никогда не должна достигаться за счет качества. SAFe требует, чтобы команды всех уровней определяли, в чем заключается «готовность» каждой задачи или проекта, и закрепляли качественные методы разработки в каждом соглашении о сотрудничестве. Согласно SAFe, существует пять основных показателей встроенного качества: процесс, качество архитектуры и дизайна, качество кода, качество системы и качество релиза.

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

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

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

Принципы Scaled Agile Framework предусматривают улучшение компании в целом за счет принятия гибких и бережливых решений с охватом всех функциональных и организационных единиц. Эти принципы влияют не только на решения руководителей и менеджеров, но и на решения каждого сотрудника организации; они обуславливают необходимость перехода от традиционного мышления к мышлению, опирающемуся на методы гибкого и бережливого управления, которые применяются, к примеру, в практиках Lean Portfolio Management.

Согласно теориям о процессе разработки продуктов, приводимым в бестселлерах Дональда Райнертсена, для достижения кратчайшего устойчивого времени выполнения нового заказа необходимо, чтобы каждый человек в цепочке принятия решений понимал экономические последствия задержек. Скорой и частой поставки не всегда достаточно. Согласно SAFe, по всей организации необходимо распределить следующие задачи: определение последовательности работ для получения максимальной выгоды, понимание экономических компромиссов и работу в рамках «бережливых» бюджетов. Многие концепции и инструменты опираются на теории Райнертсена о процессе разработки продуктов.

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

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

По умолчанию проектирование систем и программного обеспечения является занятием с неопределенным исходом. Данный принцип решает проблему неопределенности путем введения концепции вариативного проектирования (Set-Based Design), которое требует сохранять в цикле разработки множество требований и вариантов разработки на протяжении длительного времени. Вариативное проектирование опирается на эмпирические данные, чтобы к окончательному варианту разработки можно было переходить на более поздних этапах.

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

Как и принцип № 3, этот принцип направлен на устранение рисков и неопределенности с помощью контрольных точек обучения. Недостаточно, чтобы работоспособность доказала каждая составляющая часть системы. Необходимо рассмотреть систему в целом, чтобы оценить возможность технической реализации текущих вариантов разработки. Чтобы ускорить циклы дальнейшего обучения, необходимо регулярно планировать последовательности точек интеграции. Эти точки интеграции являются примером цикла Уолтера Э. Шухарта планируй — делай — проверяй — корректируй, который является схемой для постоянного улучшения качества и механизмов контроля вариативности разработки. В SAFe часто используются работа Шухарта и другие работы, вдохновленные его трудами.

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

Ограничение объема незавершенной работы помогает заинтересованным сторонам четко увидеть, как идет процесс.

Три элемента этого принципа демонстрируют основные способы максимального увеличения объема и скорости поставки ценности, т. е. реализации «потока». Как говорится, слона лучше есть по кусочкам.

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

Этот принцип служит ориентиром в оптимизации этих задач для достижения наилучших результатов.

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

Этот принцип создан под влиянием идей консультанта по управлению Питера Друкера и автора Дэниела Пинка, и мы его очень любим! Речь идет о раскрытии потенциала команд и замене командно-административного мышления руководства на обучающий и помогающий подход к работе с командами.

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

Компания Scaled Agile, Inc. предоставляет дорожную карту внедрения SAFe, которая содержит подробные инструкции по началу работы и подготовке организации к проведению широкомасштабного применения платформы по всем портфелям. Внедрение SAFe состоит из следующих 12 шагов.

1. Достичь переломного момента.
2. Обучить менеджеров по организационным изменениям, которые будут использовать принципы бережливости и agile.
3. Обучить руководителей, менеджеров и ведущих специалистов.
4. Создать центр передовых технологий, соблюдающий принципы бережливости и гибкости.
5. Определить потоки создания ценности и поезда agile-релизов (ART).
6. Создать план реализации.
7. Подготовиться к запуску ART.
8. Обучить команды и запустить ART.
9. Научиться реализации ART.
10. Запустить больше ART и потоков создания ценности.
11. Расширить схему до уровня всего портфеля.
12. Поддерживать и улучшать.

Несмотря на то, что платформа Scaled Agile Framework® (SAFe®) широко распространена среди предприятий с большими командами разработчиков программного обеспечения, с течением времени набрали популярность и другие масштабируемые agile-платформы. Все платформы для масштабирования agile объединяют пять основных компонентов: вдохновение от 12 принципов манифеста agile-методологии, последовательность действий, синхронизация, scrum и методы качественной разработки. Понимание происхождения других платформ, основных отличий и условий их успешного применения поможет организациям выбрать структуру, которая оптимально соответствует их потребностям.

Хотите познакомиться с предысторией некоторых основных масштабируемых agile-платформ? Прочтите обзор Agile-подход при любом масштабе на странице тренера по agile.

В Scrum@Scale (S@S) каждый сотрудник является частью взаимозаменяемой scrum-команды. В зависимости от целей сети scrum-команд объединяются, образуя экосистему. Платформа S@S предназначена для создания сети scrum-команд с помощью «немасштабируемой архитектуры», т. е. основные роли и события scrum масштабируются линейно, без введения в процесс новых движущих сил. Например, для очень сложного продукта с 25 scrum-командами одного Scrum of Scrum (SoS) может оказаться недостаточно, и тогда понадобится Scrum of Scrum of Scrums (SoSoS) и Scrum of Scrum of Scrums Master (SoSM).

Несмотря на то что платформа S@S в целом носит менее директивный характер, для определения готовности организации к масштабированию она предлагает ответить на один наводящий вопрос: если в систему добавить больше людей, производительность резко возрастет или ухудшится?

Как и SAFe, платформа S@S предлагает справочные материалы, доступные онлайн, в том числе набирающее популярность подробное руководство Scrum@Scale.

S@S приносит наибольшую пользу, когда:

• используется объектно-ориентированный технологический стек (т. е. поставка вертикальных пользовательских историй может быть осуществлена в течение двух недель);
• функциональные команды организации имеют Т-образные навыки, продукториентированные ценности и минимальный уровень бюрократии;
• инструмент управления agile или Agile Lifecycle Management (ALM) не является обязательным, пока практика прочно не войдет в привычку;
• команда руководителей намерена применять scrum и устранять препятствия в организации.

Large-Scale Scrum (LeSS) применяет минималистический подход к ролям, структуре и артефактам. Там, где SAFe предлагает четыре конфигурации размещения все более крупных команд со все более сложными решениями, LeSS предлагает две: LeSS для организаций с 2–8 командами и LeSS Huge для организаций более чем с 8 командами. Согласно LeSS, владельцы продуктов должны обладать всеми полномочиями и стратегическим влиянием на контент, тогда как SAFe предлагает более демократичный подход. В то время как в SAFe многие факторы влияют на стратегию, LeSS опирается на клиентоориентированный подход с фокусом на клиентах, оплачивающих услуги.

Как и S@S, LeSS масштабируется на основе событий, артефактов и ролей scrum. И SAFe, и LeSS придают особое значение системному и бережливому мышлению, а также схожим руководящим принципам. Однако LeSS уделяет большое внимание сокращению отходов во всей организации с целью постоянной оптимизации.

LeSS приносит наибольшую пользу, когда:

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

Основным принципом SAFe является то, что эта платформа продолжает развиваться совместно с сообществом своих пользователей по всему миру. Совсем недавно компания Scaled Agile, Inc. выпустила SAFe версии 5.0. Основными изменениями стали добавление принципа № 10 «Организация происходит вокруг ценности» и изменение шага 12 с «Поддерживайте и улучшайте» на «Ускоряйте». На самом деле изменений гораздо больше. Хотите узнать подробности? Ознакомьтесь со статьей о том, что появилось и что изменилось в SAFe 5.0, в нашем блоге.

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