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

Узнайте о платформе Scaled Agile Framework (SAFe), ее принципах и отличиях от других Agile-платформ.

Jessica Piikkila Автор: Jessica Piikkila
Просмотр тем

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 требует от руководителей поведения, в котором сочетаются принципы бережливости и гибкости, поскольку только руководители могут изменить систему и создать среду, необходимую для внедрения всех ключевых ценностей.

Принципы SAFe

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

Принцип № 1. Смотрите с точки зрения экономики

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

Принцип № 2. Применяйте системное мышление

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

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

Принцип № 3. Допускайте вариативность; сохраняйте варианты

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

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

Принцип № 4. Выполняйте инкрементальные сборки с быстрыми циклами обучения, интегрированными в процесс

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

Принцип № 5. Контрольные точки должны основываться на объективной оценке работающих систем

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

Принцип № 6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей

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

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

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

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

Принцип № 7. Применяйте каденции, выполняйте синхронизацию с помощью кросс-доменного планирования

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

Принцип № 8. Раскройте внутреннюю мотивацию работников умственного труда

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

Принцип № 9. Децентрализуйте принятие решений

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

Как работает SAFe?

Организации, готовые внедрить платформу 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. Поддерживать и улучшать.

Чем SAFe отличается от других масштабируемых agile-платформ?

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

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

SAFe и Scrum@Scale

В 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 и устранять препятствия в организации.

SAFe и Large-Scale Scrum (LeSS)

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 и DA

В отличие от остальных описанных платформ, платформа Disciplined Agile (DA) представляет собой набор инструментов, который позволяет организациям решать, какой способ работы подходит им лучше всего. Она предлагает упрощенное agile-управление на основе scrum и kanban, а также способствующие трансформации знания в таких областях, как управление персоналом и финансами, менеджмент, DevOps, управление портфелем и многих других. DA предполагает ситуационное использование различных уровней масштабирования для каждого проекта и акцентирует внимание на том, что для определения стратегического направления необходимо создать условия для принятия решений.

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

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

SAFe и Spotify

«Модель» Spotify — это автономный набор практик с акцентом на людей, который можно применять для координации agile-команд. Она не задумывалась как модель или платформа, но некоторые компании внедрили ее именно в таком варианте. Модель Spotify ориентирована на самоорганизующиеся многофункциональные команды, расположенные в одном месте; их называют «отрядами» (эквивалент scrum-команд). Для сравнения, в SAFe нет оговорки по поводу совместного нахождения команд, которое рекомендуется для проведения PI-планирования.

Отряды организованы в более крупные подразделения, называемые «кланами». Проблемы, вызванные немногочисленными зависимостями между отрядами, при необходимости разрешаются на основе принципов Scrum of Scrums. Обмен знаниями происходит через «отделы» и «гильдии»; такие неформальные группы организуются на основе наборов навыков и интересов.

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

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

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

SAFe 5.0

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

Заключение

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

продолжение темы
Модель Spotify