scaled agile framework что это
SAFe или Scaled Agile Framework
Что такое SAFe?
Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.
Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?
Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.
Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Есть попытки использовать 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 — есть карьерный путь.
Далее — это может быть выгодно тем владельцам бизнеса, где управляющие работают над большими, пожирающими огромное количество человеко-часов проектами и не могут (иногда по объективным причинам) сделать эти проекты независимыми.
Множеству разработчиков с квалификацией ниже среднего, т.к. часто для того, чтобы что-то сделать их нужно экспоненциально больше чем тех самых опытных и замотивированных профессионалов.
В целом индустрии. Т.к. количество разработчиков удваивается каждые 5 лет (см. uncle bob’s future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.
SAFe — это слоеный пирог из различных методик Agile. На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. Хотя есть одно ключевое отличие. Команда перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. Т.е. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).
На следующем уровне у нас поезда — так называемые Agile Release Train. Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.
Над уровнем поездов у нас координация между отделами, директорами, и клиентом. Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Здесь проводится анализ экономической целесообразности изменений. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Для компаний менее миллиарда долларов — это может быть самый последний этаж. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.)
Над уровнем больших систем идет управление портфолио. Распределяются средства на различные направления в бизнесе. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Здесь принимаются решения о покупке или слиянии с другими компаниями. Создание новых направлений бизнеса, закрытие старых. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.
Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.
Плюсы
Недостатки
Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.
Как мы “примеряли” SAFe
Привет, меня зовут Василий Юзов, и я Chief Product Owner в небольшой, но очень гордой IT-компании. У нас 12 продуктовых команд, которые разрабатывают различные решения для автоматизации и цифровой трансформации бизнеса и государства.
Вообще, мы обычная команда полного цикла разработки. Работали в командах, использовали Agile, Scrum, где-то взлетало, где-то не очень… В какой-то момент все начало разваливаться. Вроде все делаем как всегда: много работаем, делаем дофига и чуть больше, команда растет… Но техдолг тоже растет, и недовольство клиентов растет. И все чаще ребята стали приходить в состоянии “я так больше не могу, пристрелите меня”.
Мы честно пытались что-то “починить”, взять новых крутых senior’ов, мотивировать и стращать ребят деньгами и всякими материальными и не очень плюшками и фишками. Но в какой-то момент поняли, что менять нужно все и кардинально. Надо все сломать и просто заново выстроить процесс разработки. И решили попробовать фреймворк SAFe®.
Если вы знаете, что такое SAFe®, то просто проскрольте эту часть. Если же нет, то перед тем, как продолжить рассказ, сделаю небольшой экскурс в предмет.
Что такое SAFe® и как оно работает
Подробно про фреймворк можно почитать на официальном сайте.
Чтобы что?
А вторая: возможно, это покажется кому-то смешным, но ключевой внутренний заказчик (так сказать, “Бизнес”, который отвечает за доходы) не совсем понимал, что происходит в производстве. Были случаи, когда “продавали” одно, а когда Клиент уже согласился и подписал контракт, выяснялось, что это невозможно. Поэтому потребовалось сделать цикл и процесс разработки понятным и прозрачным для всех.
Третья причина. Заглядывая немного вперед, хочется прийти к кросс-функциональным командам, которые будут гибко переключаться между разными направлениями, в зависимости от приоритетов.
Очевидно, что мы не первые, кто столкнулся с такими сложностями, мы решили не изобретать велосипед, а посмотреть мировую практику. В результате все свелось к выбору между LeSS (Large Scaled Scrum) и SAFe®. Выбрали мы SAFe®, потому что он более:
распространен, а значит, у него большое комьюнити, можно задавать вопросы единомышленникам, перенимать чужой опыт.
Запрягаем коней
Все, мы решились. Давайте внедрять. Открываем “инструкцию”, читаем пункт первый:
“Возьмите ваши Agile-команды…”
Так, стоп, а у нас есть Agile-команды. До этого момента каждая команда “жила” так, как ей нравилось. Да, большая часть использовала так или иначе фреймворк Scrum, но явно требовалась определенная синхронизация и выравнивание даже на уровне понятийного аппарата, чтобы все разговаривали на одном языке.
Поэтому перед тем, как внедрять, мы слегка подготовились. Для начала прошли обучение на Scrum Master в SAFe® (6 человек), SAFe® Product Owner & Product Manager (3 человека) и SAFe® Scaled Agile Engineer. После мы организовали и провели ряд обучающих мероприятий внутри компании, чтобы подготовить плацдарм для изменений.
Примерка
SAFe® мы тоже «примеряли». Правда здесь двумя неделями было не обойтись. По классике стандартный цикл во фреймворке длится 3 месяца, мы решили попробовать спланировать PI на месяц: 2 производственных спринта + IP-итерация на неделю. Конечно, так никто не делает. Просто потому, что само по себе “PI-планирование”, как мероприятие, довольно-таки сложное и дорогое удовольствие. Нужно “вырвать” на 2 дня из производстводственного процесса и собрать в одном месте все команды и заинтересованных представителей “бизнеса” внутри компании. Но мы решили, что это невысокая цена для проверки нашей гипотезы.
Наше первое PI-планирование
Состав
В начале августа 2021 года мы вывезли 80 человек за город, чтобы понять, во что мы ввязываемся. Мы решили, что нам нужны:
представители бизнес-подразделений, которые непосредственно общаются с заказчиками,
продуктовые команды со своими PO и Scrum-мастерами,
UI/UX дизайнер для экспертной оценки возможных интерфейсов, т.к. это может повлиять на бэкенд,
представители сопровождения, которые отвечают за внедрение, тиражирование и поддержку пользователей,
Такой состав нужен, чтобы, с одной стороны, иметь всю необходимую для принятия технических решений экспертизу под рукой, а с другой — ребята, которые будут деплоить и сопровождать разрабатываемые решения, могут сформулировать дополнительные нефункциональные требования, которые нельзя не учитывать.
Регламент и повестка
План
Планирование мы начали с короткого бизнес-контекста, после чего все вместе повторили теорию, и понеслось.
Для соблюдения тайминга каждые 20 минут мы собирали всех Scrum-мастеров и проходили по общему чек-листу. Это был своего рода синхрон, чтобы не допускать отставания команд.
Все хорошо, но надо переделать
Не то, чтобы мы думали, что все пройдет легко и гладко. Скорее наоборот, мы знали и очень ждали каких-то интересных ситуаций. И вот во время ревью целей в одной из команд мы поняли, почему авторы методологии настаивают на проведении PI-планирования в 2 дня. Ребята из “бизнеса” увидели, что критичная для клиента фича не попадает в «поезд» и быстро переиграли приоритеты. Команде пришлось перестроить свой план работ на планируемый период. И все бы ничего, если бы не те самые пресловутые зависимости между командами. Смена приоритетов в работе одной команды нарушила зависимость от другой команды, которой тоже пришлось оперативно перестраивать свои спринты. Нам “повезло”, что мы планировали всего лишь 2 спринта (а не 6), поэтому удалось быстро все переиграть и исправить.
По классике, ревью черновика плана проводится в конце первого дня. Продуктовые команды расходятся по домам, а продуктовый менеджмент и представители бизнеса могут остаться для пересмотра приоритетов, чтобы оставить в «поезде» действительно необходимые фичи. Это носит неформальное название «Ночь торгов». На следующий день команды получают уточненные приоритеты, и у них есть еще один день, чтобы скорректировать свои планы и зависимости друг от друга.
Первый Program Board
В результате PI-планирования мы получили Program Board со всеми запланированными историями и выявленными зависимостями. Существует мнение, что на доску есть смысл выносить только зависимости, но команда решила зафиксировать на доске все истории, которые попали в «поезд». Таким образом мы визуализировали свой план на август:
Наш первый Program Board
Естественно, позже все переехало в Miro:
Program Board в первом PI
Небольшие пояснения по доске. Зеленые стикеры в конце спринта — это цели команды. Грустный смайлик означает, что цель не достигнута. Кстати, многие команды включают в цель спринта несколько пунктов, и мы договорились, что цель считается достигнутой, только если сделаны абсолютно все пункты. Это помогает нам учиться ставить понятные и адекватные цели.
Красные линии и карточки показывают зависимости между задачами. Видно, что красная линия идет от красных стикеров к синим. Это означает, что от команды, в чьем бэклоге есть красный стикер, зависит команда с соответствующим синим стикером.
Выводы и итоги
Важно иметь проработанный до уровня User Story бэклог. При этом у команд не должно быть не решенных до PI-планирования вопросов по самим историям и критериям их приемки.
PI-планирование должно проходить 2 дня.
В каждой команде обязательно должен быть подготовленный Scrum-мастер. При таком количестве обсуждений и споров без грамотной фасилитации не обойтись.
Program Board лучше сразу делать в Miro и выводить ее через проектор на экран.
Что такое SAFe, кому он нужен и где его применять
Scaled Agile Framework® (SAFe) — это онлайн-база знаний, состоящая из доказанных, интегрированных принципов, практик и компетенций внедрения Lean, Agile и DevOps при масштабировании.
Так что это, Scaled Agile Framework или SAFe?
Методология Scaled Agile Framework — это гибкий фреймворк для масштабирования процессов и проектов в организациях, плавающий в айти-вселенной на трех китах: Команда, Программа и Портфель.
Думаете, это выглядит так?
Нет. По сути, SAFe внедряет принципы равенства лишь внутри каждого из китов:
Вся же структура организации выглядит как-то так:
На первом этаже SAFe — Scrum
Это почти что классический скрам: команды по 3-9 человек, спринты по 2-3 недели, скрам-роли, скрам-артефакты и скрам-события. Но только команда теперь не полностью независима. И спринт не полностью самостоятелен.
Для того, чтобы связать между собой работу разных команд над одним продуктом, спринты теперь объединяются в программные инкременты (обычно 5 спринтов = 1 PI). И если в Scrum коррекция производилась по окончанию каждого отдельного спринта, то в SAFe — по окончанию PI. В чем-то это экономит время и упрощает работу в масштабе. С другой стороны, если мы ошиблись вначале, то часто тащим и развиваем этот груз до следующего PI Planning.
На втором этаже SAFe
Ходят Agile Release Trains (по-простому поезда). Здесь же “живут” носители новых ролей: системный архитектор (управляющий архитектурой), продакт-менеджер (старше владельца продукта по званию и полномочиям) и Release Train Engineer (тот же профессионал проектного менеджмента, по-простому PMP в SAFe).
На втором этаже SAFe добавляются некоторые наработки канбана — velocity metrics, scope, способ назначения приоритетов и, конечно же, доска.
Последний из 5 спринтов объявляется организационным. На собрания этого спринта приходят все команды, то есть, 100 и более человек. Здесь анализируется технический долг, производится планирование архитектуры и в целом синхронизируется работа команд.
На третьем этаже SAFe
Происходит координация больших систем и взаимодействия между директорами, отделами и клиентом. На этом этаже анализируются и проверяются гипотезы, а также создаются долгосрочные планы (ура waterfall).
Этот этаж может быть последним, если у компании нет портфеля. А вот если есть…
На четвертом этаже SAFe
Происходит бережливое управление портфелем — Lean Portfolio Management. Здесь выбираются перспективные направления и распределяются средства, принимаются решения о покупке или слиянии организаций, создаются новые направления и закрываются старые. На этом этаже рождается, корректируется и переназначается бюджет. Для оценивания существует ряд метрик, для синхронизации — свои ритуалы.
“Вишенка на торте” — стратегия. Но так глубоко фреймворк SAFe уже не заходит.
Ценности SAFe
Четыре основные ценности SAFe — это ключ и основа для эффективного применения этой методологии.
1. Согласованность
Согласованность необходима, чтобы идти в ногу с быстрыми изменениями, разрушительными силами конкуренции и географически распределенными командами.
Согласованность не подразумевает и не поощряет каскадный менеджмент. Согласование происходит, когда все работают в одном направлении. Оно обеспечивает расширение прав и возможностей, автономию и децентрализованное принятие решений, позволяя тем, кто реализует ценности, принимать более правильные решения на местном уровне.
2. Встроенное качество
Встроенное качество гарантирует, что каждый элемент и инкремент решения отражает стандарты качества на протяжении всего жизненного цикла разработки. Качество — это не то, что «добавляется позже».
Повышение качества является требованием бережливого производства и потока — без него организация, скорее всего, будет работать с большими партиями непроверенной работы. Вероятные результаты — чрезмерная потребность в переделках и снижение скорости.
3. Прозрачность
Без доверия никто не может создать высокопроизводительные команды и программы, а также укрепить (или восстановить) уверенность, необходимую для принятия и выполнения разумных обязательств. Без доверия рабочая среда намного менее увлекательна и меньше мотивирует.
Прозрачность, которую вы обеспечиваете с помощью некоторых практик SAFe, — первый шаг к доверию.
4. Программная реализация
Первые три ценности SAFe не имеют значения, если команды не могут работать и постоянно доставлять ценность. Поэтому SAFe уделяет большое внимание рабочим системам и бизнес-результатам.
Первые три ценности позволяют командам SAFe сосредоточиться на четвертой. И если они будут бороться (а они будут, потому что разработка сложных решений — непростая задача), у них есть краеугольный камень воркшопов по инспекции и адаптации. Таким образом, они замыкают цикл и работают все лучше и лучше во время каждого программного инкремента.
Все эти ценности невозможны без настоящего Lean-Agile лидерства и культуры непрерывного обучения. Только так, создавая постоянную и осмысленную культуру для команд и стейкхолдеров, можно организовать постоянную поставку ценности в потоке.
Принципы SAFe
1. Обосновывайте экономически. Традиционно бюджеты были известны только лицам, принимающим решения. Повседневные решения участников процесса на всех уровнях принимались без понимания экономической составляющей. Это приводило к задержкам, ограниченным возможностям и сниженной эффективности команд на всех уровнях.Экономика должна обосновывать и определять решения на всех уровнях, от портфолио до гибких команд.
2. Мыслите системно. Системное мышление предполагает целостный подход к разработке решений, включающий все аспекты системы и ее среды в ее проектирование, разработку, развертывание и обслуживание.Три аспекта системного мышления:
Понимание этих концепций помогает лидерам и командам ориентироваться в сложности разработки решения, организации и общей картине времени вывода на рынок в целом.
3. Предполагайте изменчивость. Сохраняйте варианты. Человеческая природа стремится к стабильности и устойчивости. Чем меньше изменений, тем нам спокойнее.Изменчивость сама по себе — это ни плохо, ни хорошо. Однако, именно экономика, связанная со сроками и типом изменчивости, определяет результаты. Наша цель в том, чтобы управлять изменчивостью и сохранять варианты. Так у нас будет и контроль, и гибкость, необходимые командам для разработки отличных решений.
4. Разрабатывайте поэтапно (инкрементально) с помощью быстрых интегрированных циклов обучения. Вместо того, чтобы на раннем этапе выбрать один вариант требований и дизайна, мы строим решение постепенно, каждый раз учитывая серию требований и вариантов дизайна.Каждый результат дает инкремент рабочей системы, который можно оценить отдельно. Дальнейшие временные рамки основываются на предыдущих шагах. Так решение развивается поэтапно вплоть до релиза.
5. Основывайте майлстоуны на объективной оценке рабочих систем. Обычно в отрасли применяется последовательный каскадный процесс разработки, где измерение и контроль прогресса происходит через ряд конкретных этапов: открытие идеи, подготовка требований, дизайн, разработку, тестирование и доставку.SAFe советует не привязываться к этим этапам, а определять контрольные точки для инспекции и адаптации исходя из конкретной рабочей системы, над которой работает команда команд. Благодаря этому систему можно будет проверять и улучшать чаще, и делать это будут стейкхолдеры, релевантные конкретному этапу разработки. Коммерческая ценность системы также повысится.
6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей. Ограничьте количество параллельно реализуемых решений. Поработайте над тем, чтобы уменьшить сложность каждого элемента и всей работы целиком.Небольшие задачи позволяют чаще проверять правильность направления и лучше контролировать очередь задач.
7. Применяйте каденции и выполняйте синхронизацию с помощью кросс-доменного планирования. Гибкая разработка лучше всего работает в «зоне безопасности», где достаточная неопределенность обеспечивает свободу для внедрения инноваций и реагирования на события, а также уверенность в работе бизнеса. Основное средство достижения этого баланса — объективное знание текущего состояния. Эти знания приобретаются путем применения каденции, синхронизации и периодического междоменного планирования.Каденция — это ритмичный паттерн событий, обеспечивающий устойчивое сердцебиение процесса развития. Он делает рутинным все, что может быть рутинным, поэтому разработчики могут сосредоточиться на управлении переменной частью разработки решения.Синхронизация позволяет одновременно понять, решить и интегрировать несколько точек зрения.В дополнение к общей каденции, периодическое междоменное планирование (пример: PI Planning в SAFe) дает возможность одновременно интегрировать и оценивать различные аспекты решения — деловые и технические.Вcе это позволяет управлять изменчивостью за счет частого пересмотра и обновления плана.
8. Раскройте внутреннюю мотивацию работников умственного труда. С SAFe, работники умственного труда могут больше:
9. Децентрализируйте процесс принятия решений. Централизировать нужно только решения стратегического характера. Они:
Все прочее нужно решать на местах.
10. Организовывайте вокруг ценности. Этот принцип описывает, как освободить предприятие от самоорганизации, оптимизируя доставку ценности. Это получается сделать за счет трех вложенных частей: