Всем привет, я Лубчак Алена, 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 или что-то на ваш вкус. Главное требование — все команды должны работать в едином ритме с общими точками для синхронизации.
К примеру, если у вас из пяти команд, две работают с
Также на уровне команды, кроме привычных и хорошо знакомых user story, вводится понятие Enebler. Это технические инвестиции в разработку продукта. Тут могут быть какие-то архитектурные изменения, исследования, 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) — это долго живущая команда команд, которые разрабатывают продукт. Обычно это
Церемонии
Аналогично Scrum, в котором есть планирование, выполнение спринта и его завершение, на уровне программы вводятся свои события.
| События | Scrum | SAFe Program level |
| Каденция | Sprint | PI (Program Increment) |
| Подготовка к планированию | Backlog refinement | Подготовка во время Innovation and Planning Iteration |
| Планирование | Sprint planning | PI (program increment) planning |
| Синхронизация во время выполнения | Daily stand-ups | Scrum of Scrums PO sync ups |
| Завершение | Iteration review Iteration Retro | System Demo Inspect & Adapt |
Артефакты
| Scrum | SAFe Program level |
| Product Backlog | Product Backlog |
| Sprint Backlog | PI Objectives |
| Increment | Solution 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 говорит релизиться раз в квартал. Тут попрошу отделять процесс планирования, когда мы высокоуровнево (на уровне фич) планируем работу
Таким образом, с помощью определенных наборов правил Essential SAFe можно организовать синхронную работу до 125+ человек, которые будут планировать, выполнять и улучшать свои продукты и процессы постоянно.
Внедрять или нет?
Безусловно, ответ на этот вопрос может дать только ваша компания, ибо только вы понимаете ваш контекст, специфику и возможности. Со своей же стороны я хочу поделиться подсказками, которые помогут вам сориентироваться:
- У вас
4-5+ команд, между ними есть зависимости, которые необходимо отслеживать. Они работают над одним продуктом или несколькими взаимосвязанными. У вас есть необходимость в синхронизации работы, много людей, но не понятно, кто чем занимается, и нужно оптимизировать систему в целом. Тогда я однозначно рекомендую обратить внимание на SAFe. - Если у вас
4-12 команд, между ними нет зависимостей, но хочется одинаково высокого уровня качества, единых практик по управлению проектами, тогда вам целесообразнее рассмотреть классический РМО (Project Management Office). - Если у вас
3-4 команды, которые работают над одним продуктом, то, вероятнее всего, обычный Scrum of Scrums уже упростит вам жизнь и решит проблему синхронизации. А какой-то дополнительный фреймворк по масштабируемости будет слишком дорогим с точки зрения усилий/затрат и получаемой выгоды.
Это был краткий обзор базовой конфигурации Essential SAFe. В следующих статьях я расскажу о других уровнях SAFe и более детально пройдусь по PI Planning и Inspect & Adapt workshop — интересных практиках для планирования, синхронизации и улучшения на масштабе.