Хабрахабр

SAFe или Scaled Agile Framework

Что такое SAFe?

Еще большее количество людей, причастных к IT используют терминологию. Что такое Agile многие знают. Еще больше тех, кто слышал об Agile.

Но вот не так давно в 2015 году появился еще и SAFe. Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Что это и зачем он нужен?

Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.
Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Есть попытки использовать SCRUM на уровне управления SCRUM командами (так советует делать Jeff Sutherland — один из авторов Agile manifesto), есть Large Scale Scrum, есть Disciplined Agile Delivery, есть много еще что, но еще есть SAFe — Scaled Agile Framework.

Т.е. SAFe — это фреймворк для управления компанией в которой требуется координация работы над некоторым проектом или связанными проектами для 5 или более SCRUM командами. это некая надстройка над SCRUM позволяющая управлять коллективами из 100 и более человек

Выгода?

На эту тему неплохо высказался Dave Thomas (еще один из авторов Agile manifesto) На GOTO 2015 в своей презентации Agile is Dead В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами.

Те, кто раньше занимался управлением проектами, получали PMP сертификации, рисовали диаграммы Гантта и реализовывали концепцию твердо-мягкого управления (мягкой стороной к руководству и твердой к исполнителям). Во-вторую очередь отделы управления программами. То же самое относится к разного рода архитекторам. Дело в том, что в типичном SCRUM для них нет функции, в SAFe — есть. В SCRUM для них нет функции в SAFe — есть карьерный путь.

Далее — это может быть выгодно тем владельцам бизнеса, где управляющие работают над большими, пожирающими огромное количество человеко-часов проектами и не могут (иногда по объективным причинам) сделать эти проекты независимыми.

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

Т.к. В целом индустрии. uncle bob's future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. количество разработчиков удваивается каждые 5 лет (см. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.

Суть

image

На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. SAFe — это слоеный пирог из различных методик Agile. Хотя есть одно ключевое отличие. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Команда перестает быть полнофункциональным независимым модулем. Т.е. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).

Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. На следующем уровне у нас поезда — так называемые Agile Release Train. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.

Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Над уровнем поездов у нас координация между отделами, директорами, и клиентом. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Здесь проводится анализ экономической целесообразности изменений. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.) Для компаний менее миллиарда долларов — это может быть самый последний этаж.

Распределяются средства на различные направления в бизнесе. Над уровнем больших систем идет управление портфолио. Здесь принимаются решения о покупке или слиянии с другими компаниями. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Создание новых направлений бизнеса, закрытие старых. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами. Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним.

То, как она определяется — фреймворк не описывает. Во-главе всего стратегия.

Плюсы

  1. Значительно количество весьма неплохих инструментов (WSJF, Kanban, Gemba, etc)
  2. Формализируются и прописываются шаги для SDLC начиная от написания кода (предписывается TDD) заканчивая выполнения статического сканирования и CI/CD и feature toggle. Хороша каждая из практик или нет — другой вопрос, но по крайней мере есть план и все ему следуют.
  3. Процесс можно понять, объяснить и внедрить.
  4. Каждый человек в рамках этого процесса, получает достаточно строго определенную функцию.
  5. Повышается прозрачность компании для тех, кто в ней работает.

Недостатки

  1. Достаточно длительное время реагирование на несоответствие реальности ожиданиям
  2. Огромное количество средств и денег тратится на коммуникацию и собрания
  3. Часто рекомендуемые решения в рамках фреймворка уже устарели

Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. Внедрять или нет? А если выбора нет и нужно управлять огромным проектом, то вполне можно.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть