Плюсы и минусы SAFe – Scaled Agile Framework

В данной статье погрузимся в разбор плюсов и минусов Scaled Agile Framework’a (SAFe), немного разберемся в том что это такое и познакомимся с историей.

Око бури

В отдаленном 2005 году правительственные структуры США объявили режим ЧП во Флориде и соседних морских уголках. Им предстояло справиться с потенциально самой разрушительной катастрофой современности — ураганом “Катрина”. Все вокруг было наполнено хаосом: миллионы эвакуировавшихся, обесточенные убежища, и вишенка на торте — прогнозы погоды, кишащие неизвестностью.

Но в этой ситуации были двое, что стремились осуществить невыполнимое. Ведущий корреспондент и ученый из национальной метео службы хотели разгадать ураган. Их цель — снять видео и собрать информацию, оказавшись в “глазу” бури, что казалось непостижимым из-за риска быть в эпицентре стихии. Однако выгоды были крайне ценны, ведь собранные данные служили бы для научных исследований и анализа, помогая более эффективно готовиться к ураганам. Но главная интрига: смогут ли они уцелеть?

По образу и подобию описанного выше сценария, SAFe® (Scaled Agile Framework) — это современный “IT-ураган”, что накрыл индустрию. Когда SAFe появился на свет в 2011 году, не все были готовы принять его, но с введением более узкоспециализированных версий и возможностью его применения на разных уровнях с усилением бизнес-гибкости (в оке бури), множество организаций начали осознавать его пользу.

Основная загадка в данном контексте: сколько из нас увидело око этой бури? Удалось ли нам использовать SAFe для достижения полного потенциала бизнес-гибкости? В данном материале мы обсудим это, а также разберемся в плюсах и минусах применения фреймворка SAFe в вашей организации.

Плюсы и минусы SAFe - Scaled Agile Framework - обложка статьи

UniwexSoft — разрабатываем уникальные сайты, smart-контракты, мобильные приложения в сфере Blockchain, собираем IT-отделы под ключ для реализации вашего проекта, заменим CTO или сильно облегчим ему жизнь.

Если вам нужен сайт, мобильное приложение, NFT маркетплейс или крипто игра, напишите нам.

Определение SAFe / Scaled Agile Framework’a

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

Интересный факт, что SAFe уже прошел множество обновлений со времени своего запуска, и последний на момент написания — SAFe 5.0, представляет собой серьезное обновление подхода. В этой версии выделяются рекомендации по нескольким основным компетенциям, которые в итоге помогут организации стать Lean Enterprise и достигнуть бизнес-гибкости.

В качестве сторонника Agile, я часто сталкиваюсь с вопросами: когда и почему стоит применять SAFe? Реально ли это работает? И т.п. Поэтому в этом материале я попробую осветить некоторые общие плюсы и минусы SAFe, присущие публичному мнению. Фокус статьи — исключительно на SAFe, исключая сравнения с другими методиками масштабирования.

Плюсы и минусы SAFe

Плюсы SAFe

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

Масштабирование на разные уровни

SAFe предлагает вариации от Essential до Full, охватывающие нужды любого уровня организации, желающей применять Agile. В этом контексте, принцип гибкости пронизывает не только разработку, но и уровень топ-менеджмента, готовящегося к волнам неопределенности в бизнесе. Таким образом, SAFe дает топ-менеджерам ценные знания для преодоления любых рисков и неясностей.

Планирование PI и контроль зависимостей

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

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

Магия SAFe? Её здесь нет, разве что в планировании PI

Заявляют создатели этого фреймворка.

Управление командами в крупных структурах

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

Про скрам доски у нас есть отдельная статья, если вам интересно, можете с ней ознакомится после прочтения статьи про плюсы и минусы SAFe. Вот она: Доска задач Scrum: 5 примеров.

Сокращение времени до достижения ценности

“Целое больше, чем сумма его частей”, – гласит мысль Аристотеля. Представим сцену: парад в День Республики, где весь военный комплекс — армия, флот, авиация, их оркестры — маршируют в унисон. Все следуют одному процессу, создавая согласованное сотрудничество.

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

С использованием процесса SAFe время достижения ценности сократилось. Если раньше это заняло бы 1,5 года, то с новыми процессами и подходами это займет восемь месяцев

Цитата с сайта Scaledagile

Ориентация на конечного пользователя

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

Более тесное взаимодействие с бизнесом и его целями

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

Таким образом, появляется прекрасная гармония между бизнесом и технологиями, ориентированная на общие цели и видение компании. Связь между этими сторонами происходит через разнообразные встречи, такие как планирование PI и scrum of scrums. Ведь самое страшное для масштабных трансформаций – это отсутствие согласования между бизнес-стратегией и IT-решениями.

Повышение гибкости компании

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

Минусы SAFe

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

Проблема терминологии

В SAFe применяется множество терминов. Например, release trains, Program Increments, runways, guardrails, enablers, spikes и так далее. SAFe создаёт свою адаптацию аджайл терминологии, подгоняя общепринятые термины и процессы под свой “фреймворк”. Например, спринт становится итерацией, story points становятся новыми рекомендациями, а spikes получают оценку.

Потеря гибкости

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

Спринт завершения разработки

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

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

Не для стартапов

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

Противоречит Agile

Основатель аджайл Кен Швабер критически относится к некоторым стратегиям SAFe. Он упоминает продажу лицензий на использование фреймворка и создание специальных партнёрств с инструментами. Некоторые сторонники аджайла считают SAFe слишком “доведённым до ума”, чтобы помочь гибкой культуре компании развиваться, вне зависимости от её размера.

При этом, Scrum, удерживающий истинные ценности и принципы аджайла, остаётся намеренно “недоделанным”, чтобы дать пространство для принятия новых ценностей. В этом смысле SAFe может подорвать важность людей и их взаимодействия.

Выводы из статьи плюсы и минусы SAFe

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

Совет таков: если хотите применить SAFe, делайте это без спешки. Двигайтесь медленно, следуя дорожной карте внедрения SAFe.

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

Следить за ключевыми аспектами и бизнес-показателями, такими как время цикла, частота выпуска, NPS, ключевые показатели бизнеса (например, удержание клиентов) становится критически важным с внедрением SAFe. Помните, что SAFe, словно ураган, может внести свою лепту в текущий отраслевой климат, и они определенно отправят нас в захватывающее путешествие. Главное – быть на чеку и готовыми встретить этот ураган, чтобы получить выгоды и заложить основу для будущего масштабирования гибкости на предприятии.

Статья переведена на русский язык компанией UniwexSoft.

UniwexSoft — разрабатываем уникальные сайты, smart-контракты, мобильные приложения в сфере Blockchain, собираем IT-отделы под ключ для реализации вашего проекта, заменим CTO или сильно облегчим ему жизнь.

Если вам нужен сайт, мобильное приложение, NFT маркетплейс или крипто игра, напишите нам.

Дополнительные материалы по теме плюсы и минусы SAFe

Related Posts

Выбор методологии управления проектами

Выбор методологии управления проектами

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

Agile и Waterfall

Agile и Waterfall

Одно из первых решений, с которым люди сталкиваются при реализации каждого проекта, – “Какую методологию разработки мы должны использовать?”. Эта тема вызывает много дискуссий (и зачастую жаркие…

Методология ITSM

Методология ITSM

ITSM (IT Service Management) — это подход к управлению информационными технологиями. Он фокусируется на предоставлении качественных ИТ-услуг и оптимизации процессов, связанных с ними. В отличие от традиционного…

Основы ITIL

Основы ITIL

ITIL (Information Technology Infrastructure Library) — это набор лучших практик, предназначенных для оптимизации управления ИТ-услугами в организациях. Эти практики направлены на повышение эффективности и качества предоставления ИТ-услуг….

Особенности agile

Особенности agile

Agile-управление проектами – это использование метода Agile для создания программного обеспечения. Компании часто используют эту методологию управления проектами для экономии времени и создания более качественных продуктов. В…

плюсы и минусы Lean - обложка статьи.

Плюсы и минусы Lean, 5 принципов методологи

Прочти о плюсах и минусах Lean. Узнай определение, историю и принципы применения Lean методологии, а так же зачем и где она применима.

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