Что такое SAFe?

Узнайте о платформе 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 model