В данной статье погрузимся в разбор плюсов и минусов Scaled Agile Framework’a (SAFe), немного разберемся в том что это такое и познакомимся с историей.
Око бури
В отдаленном 2005 году правительственные структуры США объявили режим ЧП во Флориде и соседних морских уголках. Им предстояло справиться с потенциально самой разрушительной катастрофой современности — ураганом “Катрина”. Все вокруг было наполнено хаосом: миллионы эвакуировавшихся, обесточенные убежища, и вишенка на торте — прогнозы погоды, кишащие неизвестностью.
Но в этой ситуации были двое, что стремились осуществить невыполнимое. Ведущий корреспондент и ученый из национальной метео службы хотели разгадать ураган. Их цель — снять видео и собрать информацию, оказавшись в “глазу” бури, что казалось непостижимым из-за риска быть в эпицентре стихии. Однако выгоды были крайне ценны, ведь собранные данные служили бы для научных исследований и анализа, помогая более эффективно готовиться к ураганам. Но главная интрига: смогут ли они уцелеть?
По образу и подобию описанного выше сценария, SAFe® (Scaled Agile Framework) — это современный “IT-ураган”, что накрыл индустрию. Когда SAFe появился на свет в 2011 году, не все были готовы принять его, но с введением более узкоспециализированных версий и возможностью его применения на разных уровнях с усилением бизнес-гибкости (в оке бури), множество организаций начали осознавать его пользу.
Основная загадка в данном контексте: сколько из нас увидело око этой бури? Удалось ли нам использовать SAFe для достижения полного потенциала бизнес-гибкости? В данном материале мы обсудим это, а также разберемся в плюсах и минусах применения фреймворка SAFe в вашей организации.
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 маркетплейс или крипто игра, напишите нам.
