Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

Обзор Essential SAFe: про методологию человеческим языком

Всем привет, я Лубчак Алена, CEO & SAFe Program Consultant в компании E5. Я работаю с SAFe (Scaled Agile Framework) на практике с 2014 года. В конце 2015 прошла сертификацию и обучение как SAFe Program Consultant. Сейчас в качестве консультанта помогаю компаниям внедрить Scaled Agile Framework и повысить продуктивность работы.

В этой статье я не ставила перед собой цель предоставить исчерпывающее объяснение SAFe. Для этого существуют специализированные тренинги, книги, вебинары, встречи и т. д. Моя задача — дать минимальный обзор, осветив самые важные, на мой взгляд, аспекты фреймворка. Сосредоточимся на базовой конфигурации Essential SAFe.

Лидер среди других фреймворков

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

12th Annual State of Agile Report от VersionOne.

Scaling Agile Report от cPrime

Scrum Master Trends от Scrum.org

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

Давайте рассмотрим фреймворк в деталях.

Определение

SAFe® is a freely available knowledge base of proven, integrated principles and practices for Lean, Agile, and DevOps.

Другими словами, это бесплатная база знаний из проверенных принципов и практик. Каждая иконка на сайте scaledagileframework.com кликабельна, и по ней открывается целая статья с детальным пояснением роли, церемонии или артефакта и дополнительным списком литературы для углубления в тему. Это не то, что внезапно появилось в 2011 году, а, скорее, результат работы многих людей и собрание воедино лучших идей. Человек, который это все оформил в фреймворк, — Dean Leffingwell. Он является творцом этой базы знаний и главным методологистом SAFe. Конечно же, ему помогали и помогают многие люди. С их вкладом и ролями, а также с внушительным списком литературы, на которой все базируется, вы можете ознакомиться тут.

Сам фреймворк достаточно обширен и напоминает конструктор, где вы выбираете нужную себе конфигурацию. На сегодня есть 4 доступных варианта фреймворка (Essential, Portfolio, Large Solution, Full Configuration), которые покрывают компании и проекты от 50 до 20 000 человек. Эти цифры являются ориентировочными, поэтому если у вас меньше 50 или больше 20 000 человек, это не повод отказываться от SAFe :) Я начинаю смотреть в сторону этого фреймворка при командах от 30 человек.

SAFe Essential — это самая простая конфигурация, которая покроет вам от 50 до 125 человек.

Она состоит из 2 уровней — уровня команды и уровня программы.

Уровень команды

На уровне команды вы выбираете тот фреймворк, который вам подходит больше всего для работы в команде — Scrum, Kanban, XP или что-то на ваш вкус. Главное требование — все команды должны работать в едином ритме с общими точками для синхронизации.

К примеру, если у вас из пяти команд, две работают с 2-недельными спринтами по Scrum, две — с 3-недельными и одна — по Канбан, то у вас разные ритмы. Вместо трех точек для синхронизации в течение 6 недель (начала 2-х недельного спринта) остается только одна. Команды с 3-недельными спринтами успеют одновременно с другими командами начать спринт всего лишь один раз на 6 недель. Это приведет к тому, что если в процессе работы одной команде что-то понадобится от другой, то надо ждать 6 недель, чтобы добавить ей это в спринт, вместо 2 недель.

Также на уровне команды, кроме привычных и хорошо знакомых user story, вводится понятие Enabler. Это технические инвестиции в разработку продукта. Тут могут быть какие-то архитектурные изменения, исследования, spike, инфраструктурные задачи и т. д.

Теперь переходим на уровень выше.

Уровень программы

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

Роли

В Scrum есть три роли: Product Owner, Scrum Master & Development team. В SAFe на уровне программы вводятся аналогичные три роли с соответствующими обязанностями, но с поправкой на масштаб: Product Management, RTE (Release Train Engineer) & System Architect/Engineer.

Product Management — это человек или люди (в больших продуктах зачастую больше чем один менеджер продукта), главная задача которых — ответить на вопрос: что мы делаем с точки зрения продукта, его стратегии, видения и т. д. Взгляд этого человека направлен вовне, на рынок и клиентов. Вот детальный перечень обязанностей.

RTE (Release Train Engineer) — это Scrum Master Scrum Master-ов, или же человек, отвечающий за координацию, фасилитацию и организацию процесса работы программы. Лидер, ментор, коуч. Главный вопрос: как с точки зрения процесса будет все происходить? Именно он/она помогают устранять препятствия на уровне программы, организовывают церемонии уровня программы и т. д. Детальнее тут.

System Architect/Engineer — это роль, необходимая для общего технического и архитектурного виденья разработки продукта. Именно эта роль появляется при масштабе, так как в Scrum полнота технических решений отдается на откуп команде. Если у вас 100 человек, то им будет проблематично выделить время и договориться о единых технических решениях. Для этого и вводится элемент централизации — роль, обеспечивающая техническое направление. Главный вопрос: как технически мы это будем реализовывать? Детальнее по ссылке.

Кроме того, вводится понятие Architectural Runway — это технические инвестиции в код, инфраструктуру, архитектуру, необходимые для внедрения ближайших бизнес-фич без значительных технических переделываний. Наполнением такого технического беклога в частности и занимается System Architect/Engineer. Детальнее тут.

Аналогом Development Team на уровне программы будет ART (Agile Release Train) — это долго живущая команда команд, которые разрабатывают продукт. Обычно это 5-12 команд, 50-125+ человек.

Церемонии

Аналогично Scrum, в котором есть планирование, выполнение спринта и его завершение, на уровне программы вводятся свои события.

СобытияScrumSAFe Program level
КаденцияSprint
1-4 недели
PI (Program Increment)
8-12 недель
Подготовка к планированиюBacklog refinementПодготовка во время Innovation and Planning Iteration
ПланированиеSprint planningPI (program increment) planning
Синхронизация во время выполненияDaily stand-upsScrum of Scrums
PO sync ups
ЗавершениеIteration review
Iteration Retro
System Demo
Inspect & Adapt

Артефакты

ScrumSAFe Program level
Product BacklogProduct Backlog
Sprint BacklogPI Objectives
IncrementSolution intent

Причем тут поезд?

Вы наверняка заметили, что SAFe вводит много терминологии, которая так или иначе намекает на поезда: ART (Agile Release Train), RTE (Release Train Engineer), Architectural Runway. И это не случайно. Метафора поезда вводится с тем, что у поезда есть предсказуемое стабильное расписание. Если вы пропустили один поезд — не беда, через известное время будет следующий и вы на него сядете. Аналогично с нашей продакт-командой и фичами: если в текущий PI не влазит какая-то фича, то она обязательно влезет в следующий :)

Еще что-то важное?

Безусловно :) Это все «не заведется» без нескольких важных вещей.

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

Во-вторых, весь процесс создания продукта — это непрерывное следование:

  • Continuous Exploration (исследование рынка, наших пользователей, валидация продуктовых гипотез, нарезание MVP и т. д.);
  • Continuous Integration (постоянная интеграция нового кода в существующий, проверка, поддержания качества на высоком уровне);
  • Continuous Deployment (постоянное доставление функционала на продакшн, без включения неполных фич и т. д.);
  • культуре DevOps.

Без выполнения этих частей вам вряд ли удастся построить хороший продукт, которым активно пользуются ваши клиенты.

Эти вещи достаточно философские, но их внедрение колоссально трансформирует вашу компанию.

В-третьих, Develop on Cadence. Release on Demand. Одним из типичных мифов является утверждение, что SAFe говорит релизиться раз в квартал. Тут попрошу отделять процесс планирования, когда мы высокоуровнево (на уровне фич) планируем работу 5-12 команд на ближайший PI (8-12 недель) и процесс релиза на продакшн, который должен быть, согласно SAFe — по требованию бизнеса. Если ваш бизнес требует релизы по 30 раз на день — пожалуйста, релизьтесь. Другой вопрос, что для этого вам нужны Build-in quality, XP practices, DevOps культура и т. д.

Таким образом, с помощью определенных наборов правил Essential SAFe можно организовать синхронную работу до 125+ человек, которые будут планировать, выполнять и улучшать свои продукты и процессы постоянно.

Внедрять или нет?

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

  • У вас 4-5+ команд, между ними есть зависимости, которые необходимо отслеживать. Они работают над одним продуктом или несколькими взаимосвязанными. У вас есть необходимость в синхронизации работы, много людей, но не понятно, кто чем занимается, и нужно оптимизировать систему в целом. Тогда я однозначно рекомендую обратить внимание на SAFe.
  • Если у вас 4-12 команд, между ними нет зависимостей, но хочется одинаково высокого уровня качества, единых практик по управлению проектами, тогда вам целесообразнее рассмотреть классический РМО (Project Management Office).
  • Если у вас 3-4 команды, которые работают над одним продуктом, то, вероятнее всего, обычный Scrum of Scrums уже упростит вам жизнь и решит проблему синхронизации. А какой-то дополнительный фреймворк по масштабируемости будет слишком дорогим с точки зрения усилий/затрат и получаемой выгоды.

Это был краткий обзор базовой конфигурации Essential SAFe. В следующих статьях я расскажу о других уровнях SAFe и более детально пройдусь по PI Planning и Inspect & Adapt workshop — интересных практиках для планирования, синхронизации и улучшения на масштабе.

LinkedIn

16 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Я пожалуй согласен с автором статьи svpg.com/revenge-of-the-pmo Для меня SAFe это про менеджерские роли в процессе и роадмапу, совсем не про продукт или технологии.

дуже гарна стаття, дякую

Ждем продолжения, спасибо за статью!

Очень коротко и по сути, спасибо.
И поправьте один Enebler (тот что со ссылкой), чтобы совсем уж красиво все было.

Спасибо за чувство прекрасного :) сейчас напишу редакторам :)

Helen, можете описать наиболее классические проблемные точки внедрения? Вижу как минимум три таких, но хочется сначала услышать мнение опытного человека.

Давайте свои :)
Если под классическими проблемными точками внедрения понимать проблемы при внедрении, то мой список такой:
1) У меня обычно самый-самый большой «challenge» — это поддержка топ-менеджмента. Если С-уровень не вникает в то, что происходит, не поддерживает — внедрение стопорится и скатывается на нет. Возникает когда изменения инициируют и драйвят РМы, а С-level не поддерживает их в нужном обьеме.
2) это позиция «мы прочитали статью, мы уже все знаем». Но она не только с SAFe, но и с любым другим фреймворком или изменением. Как результат очень ограничивают обучение, не разбираются в деталях и нюансах, каждый внедряет то, что у него в голове, а не то, что надо, а потом «фреймворк плохой, нам не подходит». Или же выливается, что у каждой команды свой какой-то процесс, который очень сложно потом вписать в общий процесс планирования/работы всей компании. Т.е. тут 2 вещи: и хорошее обучение и планирование (разобраться в том, ЧТО и КАК собираетесь внедрять) и единство инструментов и практик по командам.
3) настройка уровня протфолио. Обычно на консалтинг приходят со словами: «наведи порядок в девелопменте». Отстраиваем уровень команд и программы и упираемся, что продуктовая стратегия отсуствует. Не все компании это могут признать. И если раньше во всем были виноваты девелоперы, которые не деливерят, то теперь оказывается, что узкое горлышко совсем не там :)

Спасибо. Не уточнил, меня интересовал уровень программы, не выше.
Так вот какие сложности я вижу:
1. Грумминг и планирование уровня проекта/программы (PI planning). На уровне 8 человек и 2-недельного спринта крайне сложно добиться качественного аутпута. То же, но на 5-7 команд да еще на 2-3 месяца вперед выглядит как не реализуемое, а потому бессмысленное.
2. Кто обеспечивает однообразие рабочих процессов? Особенно если необходимо соответствовать каким-то требованиям и стандартам.
3. Неравномерность нагрузки CI ресурсов из-за синхронизации спринтов (при использовании скрама на командном уровне).
4. PI planning при сильно распределенных командах (к примеру: Шанхай-Киев-Сан-Хосе)

Ну и еще вопрос. Почему команды обязаны работать по одним циклам? Если есть несколько продуктовых команд и одна сервисная (предоставляет сервис для этих команд), почему она не может саппортить их по кан-бану если те релизят по скраму?

Тут прокомментирую:
1) мне кажется, вопрос в определении «качественный аутпут». Безусловно, самые точные оценки к той работе, которую команда уже сделала и все там знает. Но мы же помним график влияния усилий по обсуждению требований оценки и ее точности — в какой-то момент обсуждения не увеличивают точность. Из практики на PI planning можно добиться той же точности, что и на спринт пленинге. За счет предварительной подготовки — т.е. во время I&P sprint команда готовится к PI planning и занимается грумингом. Кроме того, у команды есть 2 дня на додумывание. А за счет «домашней работы» продактов и правильного уровня портфолио команда в одном PI делает технические ресерчи, а в другом — по их результатам имплементирует бизнес фичи.
2) Зависит от конкретного процесса. Если я правильно поняла вопрос, то сам процесс обеспечивает RTE (Release Train Engineer). Для контроля технических процессов есть системный архитектор, комьюнити оф пректис и т.д.
3) что тут именно имеется ввиду? если только технический аспект, то мне кажется его можно решить.
4) Это правда вселенская боль :) Честно :) В таких случаях обычно стараются провести все в одной локации, желательно ее ротируя. Свезти всех в одно место безусловно дорого. Тут начинаются оптимизации: а давайте только представителя команд, а давайте всех по видео подключим и т.д. Но чем больше оптимизация костов, тем меньше эффект от PI planning. Нет возможности дотянуться до бизнеса, архитектора прямо на месте, решить в реальном времени зависимости с другими командами и т.д. Но мне кажется все эти проблемы были у таких команд и до внедрения фреймворка.

Может :) Это спокойно будет хоть скрам, хоть канбан, хоть хр, толь ваш собственный метод. Главное — иметь общие точки для синхронизации между командами. Т.е. если 2 команды работают по скраму, а 3 по канбану, то ограничение только в том, чтобы 2 команды по скраму начинали и заканчивали спринты одновременно — чтобы могли друг другу отдавать задачи в беклог, если между ними есть зависимости.

Все-таки не совсем понимаю, почему не может быть небольшого сдвига в графике спринтов между командами. Условно — одна команда заканчивает спринт, столкнулась с чем-то, где нужна другая команда, и есть время, например пару дней, на подготовку детального описания, согласования работ и т.д.
А тут как раз и вторая закончила свой спринт, и на своем планировании получает уже готовые требования, с минимальным уровнем неопределенности.
Хотя пока писал, понял, что реализованый второй командой функционал попадает с отставанием в 1 спринт в работу первой команды, за счет того, что вторая заканчивает позже первой, как раз на эти пару дней.

1) Может* — это теория ;-) Меня как раз интересует практический аспект. Можно увеличить время на пре-грумминг. Но это не значит, что команда будет использовать это время качественно. Как на практике достигнуть приемлимой точности планирования с горизонтом 3 мес так, чтобы не оказалось что сделано только 50% или наоборот, чтобы в планах не было 50% риск-буферов? С учетом того, что груммингом фич команды занимаются крайне неохотно и что подготовка PoC для некоторых решений может занимать недели.
2) Одного RTE точно не хватит. У него все время будет занято устранением препятствий для команд. Я не нашел в структуре обязанностей системного архитектора этой ответственности. Да и правильно, его работа — архитектура продукта и никак не связана с процессами разработки, тестирования и т.д. Кто такие коммьюнити оф прэктис? Где их найти на схеме?
3) Да, чисто технический аспект. Есть билд-сервера, есть тест-сервера. После ченджа(коммита) делается билд и на нем запускаются тесты, чтобы убедиться, что чендж ничего не поломает. Если 5 команд одновременно начинают спринт, то с большой вероятностью в первые несколько дней изменений будет мало и нагрузка будет небольшой. Зато под конец спринта она возрастет во много раз. Имеем проблему (особенно, если нет возможности использовать глобальные клауд-сервера). Зачем синхронизировать спринты команд, которые друг от друга не зависят?
4) Да, но именно PI планнинг это та основная фича, которая отличает SAFe от LeSS, например. И если она не работает как положено то возникает вопрос, а почему SAFe..
5) Как выглядит точка синхронизации для команды, работающей по канбану? Там же все управление идет через установку приоритетов.

1) Моя практика (а это 5+ лет работы в разных командах и компаниях по SAFe) показывает, что точность планирования приемлема за счет пре-груммингов во время IP спринта и 2 буферов (IP спринт и Stretch Objectives). Кроме того, если фича сырая, то в первом PI берется Enabler для PoC и всевозможных ресерчей, а по результатам этих ресерчей в следующий PI добавляется уже готовая к работе команды фича.
2) Все иконки на схеме кликабельны. Обязаности систем архитектора тут: www.scaledagileframework.com/...​on-architect-engineering
Описание СоР тут www.scaledagileframework.com/communities-of-practice
Сама иконка сбоку во всех версиях кроме Essential.
3) Из моей практики нагрузка в конце спринта возрастает, но не так, чтобы сервера легли. Стори нарезаются небольшими, поэтому нагрузка распределяется более равномерно чем все в последний день. Но это опять же таки и в обычном скраме будет.
4) Рекомендация SAFe — по возможности всех собрать в одном месте. Если это не возможно — то хотя бы представителей команд. Если это не возможно — тогда делают все по видео связи. Если пересечений всего 1 час рабоего времени — да, вам не подойдет SAFe.
5) для Канбан команд берутся точки синхронизации от команд, которые работают по скраму — к примеру, раз в 2 недели. Результаты синхронизации добавляются в беклог с соответвующим приоритетом.

Мы будем делать в марте откртую встречу — расказывать один из кейсов внедрения. Приходите, можем продолжить дискуссию вживую. Детали будут немного позже — пока определяемся с дотой и локацией.

Здорово, было интересно, спасибо!

Отличная статья. И, действительно, человеческим языком.

Спасибо большое :)

Подписаться на комментарии