Огляд 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, вводиться поняття 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) — це довго живе команда команд, які розробляють продукт. Зазвичай це 5-12 команд, 50-125+ чоловік.

Церемонії

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

Події	Scrum	SAFe Program level
Каденція	Sprint 1-4 тижні	PI (Program Increment) 8-12 тижнів
Підготовка до планування	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 говорить релизиться раз в квартал. Тут попрошу відокремлювати процес планування, коли ми высокоуровнево (на рівні фіч) плануємо роботу 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 — цікавих практиках для планування, синхронізації і поліпшення на масштабі.

Опубліковано: 20/02/19 @ 11:00
Розділ Різне

SEO Блог