Нояб. 04

Досвід упровадження SAFe: як організувати процес та який результат

Усім привіт! Мене звуть Андрій, я PM у київському офісі компанії N-iX. У цій статті я поділюся передісторією й особливостями впровадження SAFe на нашому проекті, а також розкажу про отримані результати після запуску фреймворка. Щоб не порушувати політику конфіденційності, назву проекту, імена замовників і подібну інформацію змінено. Проект матиме назву ― Project X, а замовники ― «Корпорація». Поїхали!

Вхідні дані

Історія цього проекту для нас почалася зі взаємодії з клієнтом ― тоді ще невеликим стартапом. Ми працювали з вісьмома іншими крос-функціональними командами з різницею часових поясів до 9 годин (ще дві команди були з нашої компанії і шість ― з інших країн).

До впровадження SAFe всі команди працювали по Scrum в єдиному операційному ритмі: спринти починали й завершували того ж дня; реліз фіч робили раз на два тижні, і це завжди був Release to Production. Щотижня ми проводили міжкомандні синкапи — Scrum of Scrums, PO synchs, гільдії, інженерні tech talks, де ми ділилися думками, генерували ідеї, дискутували й упроваджували ініціативи для поліпшення робочих процесів. Суттєва різниця в часі й робота з представниками різних культур і захоплювала, і накладала свій відтінок «шарму» на щоденну роботу — реліз о 7-й ранку або плановий deploy UAT для клієнтів о 12-й ночі стали для нас звичними.

Уже тоді існував певний прототип каденції і синхронізації, проте це був швидше результат зусиль Scrum-майстрів, ніж усвідомлений крок до реалізації цих практик, а також Continuous Deployment and Release on Demand з боку архітекторів, development-менеджерів, продакт- і бізнес-оунерів.

Ключова мета й організаційні трансформації

Зміни розпочалися після того, як стартап викупила велика «Корпорація», і ми поступово ставали частиною великої бюрократичної організації.

У зв’язку з суттєвою різницею в часі центрів розробки, вартістю й обсягом загальних витрат на розробку, менеджери «Корпорації» ухвалили рішення реструктурувати віддалений центр розробки. Ставку зробили на європейські команди. У віддаленому часовому поясі залишилася тільки команда продакт-оунерів.

Плани про впровадження SAFe вперше почали обговорювати трохи більше як рік тому. Клієнт вірив, що це розв’язало б такі недоліки:

Відсутність прогнозованих точок інспекції інкременту й синхронізації на рівні програми — ефективно побудовані Scrum-церемонії відпрацьовували себе лише на командному рівні, що не давало змоги впевнитися, що загальні результати ітерацій усіх команд можна безболісно інтегрувати.
Недостатня прозорість артефактів — продуктові беклоги були недонаповнені й відображали бачення продукту лише на один спринт уперед. Решта була тільки в головах продакт-оунерів (командні продакт-оунери насправді відігравали роль бізнес- та функціональних з мінімальним правом ухвалення рішень щодо розвитку продукту), які не дуже переймалися генерацією ідей та пришвидшенням features Time-to-Market.
Занедбаний стан архітектури — здоровенний, кількарічний моноліт, який усе більше й більше розростався, і, крім девелоперів, ніхто «з місцевих» архітекторів не був спроможний запропонувати розумні альтернативи оптимізації.
Відсутність реалістичного довгострокового RoadMap — продукт рухався в невизначеному напрямку, класні фічі були заморожені в репозиторіях на стадії UAT, а наявний RoadMap не давав належного розуміння перспектив.

Адаптація Scrum-майстрів і продакт-оунерів до SAFe Mindset відбувалася за підтримки зустрічей з SPC (SAFe Program Consultant). Remote-команди з інших країн розпущено через майбутні невиправдані операційні витрати, пов’язані з логістикою й комунікацією для планування та реалізації програмного інкременту. А тому залишилися тільки наші N-iX-команди й команда продакт-оунерів. Деякий час ми розвивали Project X самостійно, однак подальший розвиток потребував залучення додаткових команд з одного часового поясу й географічної локації (для зменшення операційних і логістичних витрат і зручнішого планування делівері). Тому «Корпорація» ініціювала запуск другого центру розробки для створення й оптимізації єдиного продукту в портфоліо «Корпорації».

Підготовка

Ми активно почали готувати запуск SAFe на Project X:

Визначили зміну й розподіл ролей у проекті відповідно до SAFe-семантики. Продакт-оунери з боку клієнта дістали роль продакт-менеджерів, а київські продакт-оунери — більше автономії в ухваленні рішень щодо розвитку продукту. Для забезпечення більшої автономії виокремили додаткову роль продакт-менеджера в київському офісі.
Виникла нова ланка архітекторів: у проекті з’явився System, а техліди дістали змогу бути консультантами й частково виконувати обов’язки System Architect, які були їм делеговані.
Сформовано System Team, щоб виконувати пласт операційних завдань для ART (Agile Release Train) і забезпечувати підготовку релізів згідно з розкладом.
Головний продакт-менеджер дістав роль бізнес-оунера й майже повністю перемкнувся на верхньорівневу координацію продакт-менеджерів та оунерів на стратегічне планування програмного RoadMap для продукту на декілька PIs (program increment planning) уперед.
Продакт-менеджери нарешті сконцентрувалися на підготовці й оптимізації програмного RoadMap на найближчі 6-9 місяців, який за результатами цих зусиль став набагато прозорішим і доступнішим для всіх учасників проекту — візія продукту набула чітко окресленого напрямку.
Продакт-оунери, техліди й системні архітектори сфокусувалися на активній підготовці програмного й командного контенту на планування, що значно поліпшило справи командних і програмних беклогів: фічі, енейблери та сторі активно грумилися, оцінювалися й корегувалися заздалегідь перед плануванням програмного інкременту.
Виокремлено роль RTE (Release Train Engineer), головне завдання якої — координація ефективної роботи командного й програмного рівня для виконання обіцяного обсягу PI-цілей у визначений термін (2,5 місяця від початку PI) і з відповідною якістю (Built-in Quality), забезпечення якісної підготовки планування програмного інкременту, фасилітація мітингів програмного рівня — SoS, PO synchs тощо, а також розв’язання й усунення перешкод для delivery-продукту на рівні програми.
Запущено й виокремлено LeanUX-спільноту, яка відповідала за розробку й оптимізацію дизайну для потреб потяга (Agile Release Train).

Запуск пробного потяга

Ми підійшли до етапу запуску першого пробного потяга. Він мав тривати півтора місяця для того, щоб адаптуватися до оптимізованих особливостей роботи й вирівняти свій графік з іншими потягами корпорації. Для цього в усьому проекті запустили відповідні лінійки SAFe-тренінгів:

Leading SAFe — для менеджерів, лідерів, Scrum-майстрів і бізнес-оунерів для поліпшення розуміння специфіки лідерства й ментальної установки фреймворка, його принципів, фундаментів, загального бачення та мети.
SAFe for Teams — для команд, продакт-оунерів і Scrum-майстрів для поглиблення і систематизації знань щодо специфіки роботи командного рівня та завдань у структурі фреймворка.
SAFe PO/PM — для продакт-оунерів і менеджерів для формування бачення розвитку продукту та його оптимізації під час програмних інкрементів.

Перший день тренінгу. Виконання заданих вправ

Тренінги тривали два місяці. Сертифікація була обов’язкова для всіх, і всі учасники проекту успішно пройшли її у визначений термін. Ще два тижні використано для останніх приготувань: фінальні грумінги, перевірка архітекторів, підготовка системи репортингу, планування зустрічей, завершення поточних ітерації, підрахунок capacity на PI тощо.

Після сертифікації і приготувань ми провели перший пробний PI. Він проходив водночас у двох центрах розробки, куди прилетіли продакт- і девелопмент-менеджери з боку замовників. Захід був незвичний: постійні синкапи, крос-командні комунікації, усі переміщувались у трохи метушливому порядку; SPC з шаблонними фразами, що завдання з вищим WSJF мають бути першим, незважаючи на те, що їхній Business value нижчий від інших; SoS і PO synchs що півтори години, розбір і планування залежностей і програмних ризиків тощо. На першому плануванні я працював з двома командами — зі своєю Agile й System Teams. Ми перебували в одному часовому поясі, проте в різних фізичних локаціях, тому координувати таку роботу було нелегко.

Ми розпочали подію о 9-й ранку за київським часом. Я дуже вдячний своїй Agile-команді за їхній професіоналізм, ініціативність і самоорганізацію. Протягом зустрічі я радше консультував їх, адже більшість часу мені потрібно було бути з девопсами. Якщо у вас дві команди в різних локаціях й одна з них нова (у моєму випадку DevOps), то краса опису PI planning буде знівельована реальністю. О 18:00 розпочали загальне рев’ю прототипів планів команд і ROAM-розбір командних ризиків. Учасників команд і продакт-оунерів відпустили — залишилися тільки продакт-менеджери, представники менеджменту (engineering and development менеджери й RTE) і Scrum-майстри, яким треба було будувати процес роботи команд протягом другого дня. Через декілька годин дискусій був вироблений загальний план і стратегія на другий день.

Протягом другого дня вдалося розподілити час на дві команди рівномірно. Було вже значно менше мітингів, команди сфокусувалися на деталізації планів і створенні PI objectives з продакт-менеджерами. Так працювали до 16:30. Далі продакт-оунери презентували плани команд і цілі на цей програмний інкремент. Одразу після цього ми провели Program Confidence Vote, де продемонстрували рівень упевненості в успішності доставки загального інкременту в цьому програмному інкременті.

Друга частина першого дня PI планування. Очікуємо бізнес-рев’ю прототипів планів

Хочу зазначити, що досвід роботи конкретно з цією системною командою досить своєрідний, адже команда невелика за кількістю учасників (чотири людини), проте має двох продакт-оунерів. А це вже суперечить логіці підпорядкування речей і визначенню пріоритетів у роботі. Ми довго сперечалися з двома SPC щодо розподілу навантаження і процесу роботи команди, оскільки вона абсолютно операційна, і їй потрібен найгнучкіший фреймворк — Kanban. А ось тут і собака зарита, адже SAFe — а це ж, передусім, фреймворк, Карле! — зазначає, що Kanban-команди повинні працювати синхронно зі Scrum-командами в межах двотижневих ітерацій, прописувати цілі ітерацій і рахувати свою Velocity (швидкість) і Lead Time, щоб не порушувати принцип загальної каденції, commitment points і синхронізації.

Це круто — справді круто, і я тільки погоджуюся і підтримую ідеї постановки цілей на певний період і періодичний підрахунок результатів продуктивності команд, окрім ідеї обмеження Kanban-команд двотижневими межами — така пропозиція, на мою думку, дуже контроверсійна, бо суперечить природі операційних команд. Друге болюче питання — Capacity Allocation — скільки команда має витрачати зусиль, щоб підкидати дров у грубку паротяга, а скільки витрачати на будування містка між розробкою й операційною частиною (DevOps).

Дискутували довго... Домовилися, що 60% зусиль команда витрачатиме на потреби потяга, а 40% — займатиметься операційною роботою. Привіт, гнучкість! Забігаючи наперед, трохи заспокою, що в другому PI SPCs таки переглянули відсоток співвідношення навантажень.

Другий повноцінний PI

Другий PI вже був повноцінний — ми планували роботу на 2,5 місяця. З важливого: він уже був простіший, загальна комунікація виваженіша, планування команд швидше, програмних ризиків і залежностей більше, але вони були легші й зрозуміліші порівняно з першим плануванням. Представників з боку замовників було значно менше. Команди будували свою роботу розмірковано й ефективно. Постійний онлайн-зв’язок підтримували з чотирма локаціями з різних поясів — це було трохи незручно. Планування проводили за київським часом, розпочинаючи, як і попереднє, о 9-й ранку.

Друга частина другого дня PI планування. Загальне голосування щодо впевненості поставки програмного інкременту

Результати

Що приніс і пофіксив SAFe своєю імплементацією в проекті:

Поліпшене загальне бачення стратегії розвитку — усі учасники проекту почали розуміти напрямок руху й завдання програми, заданий вектор став прозорим.
Вирівнювання процесу здачі продукту — ми співіснуємо в єдиному, зрозумілому для всіх ритмі, попри індивідуальні характеристики: швидкість команд і кількість учасників, прогнозованість їхньої роботи тощо, адже це можна й треба корегувати, проте — каденція одна, як і commitments and review points.
Поліпшення архітектури — тепер 15% своєї місткості команда виокремлює на оптимізацію архітектури й планує технічні енейблери в PI, а Innovation days дає змогу витрачати тиждень командам на підготовку, прототипування, хакатони й демонстрацію своїх доробків, які можуть бути взяті в роботу в наступному PI.
Прогнозованість руху потяга — прогрес прозорий, командні й програмна дошки доступні кожному учаснику проекту, а зустрічі з синхронізації та звіти допомагають координувати досягнення результатів.
Виникнення чітких програмних цілей — ми розуміємо, чого хочемо досягти конкретно за ці 2,5 місяця роботи, і на яких пріоритетах сфокусуватися.
Зменшення відтоку працівників у проекті й поліпшена мотивація команд — особливо в Innovation days. Я бачив, як «горять очі» в людей, коли вони проектували й презентували свої прототипи, як сподівалися на оцінки від продакт-менеджерів й архітекторів, які можуть піти в наступний PI як фічі.

Над чим варто задуматися

SAFe дуже своєрідно вбудовує Kanban у командний рівень — Kanban-команди (DevOps у нашому випадку) повинні працювати за двотижневими ітераціями, що спричинює загальне незадоволення учасників, перевантаження й неефективність роботи згаданої команди конкретно в цьому проекті.

Значення SPC під час трансформації і в процесі розвитку проекту — у нас їх було два — один основний, а другий консультативний. У них була вся «повнота влади», але існувала велика небезпека, що наша робота могла перетворитися на двомісячний Fixed Scope Project — кожне завдання, додане або витягнуте зі спринта розглядали як «державну зраду». Побуду кепом і розвінчаю міф про фіксований Scope беклога спринта/ітерації, скоуп якого живе й еволюціонує зі спринтом/ітерацією, але за двох умовах:

Цілі спринта/ітерації та обсяг завдань, підібраний під них, непорушні й можуть бути досягнуті після завершення спринта/ітерації.
Пов’язані взаємні залежності й ризики мають бути знівельовані або усунуті перш ніж стирати або додавати скоуп робіт у спринт/ітерацію, бо саме це завдання розв’язують на PI planning — ось тільки це й лишається незмінним.

Найпростіший приклад: коли нове завдання не має залежностей на інші команди й збігається з цілями спринта або це незалежний Support defect / Exploration Enabler (Spike). Як наслідок подібні ситуації слід детально обґрунтувати, адже вони можуть перешкоджати «цілісності» програми! Якщо ситуації повторювалися, Scrum-майстер команди визнавався «зрадником» великих ідей :) й отримував корегувальний one-to-one з RTE.

Значення системних архітекторів і їхні основні завдання в проекті — іноді виникають неконструктивні конфронтації між техлідами й системними архітекторами щодо розвитку ініціатив архітектури. Це стає причиною демотивації техлідів. Ситуація ускладнюється тим, що техлідам слід делегувати більше повноважень згідно з домовленостями, проте їхню думку, попри набутий болісний і набагато глибший досвід роботи конкретно з цим проектом, часто ігнорують. Такі ситуації додають роботи з урегулювання питань взаємодії, ключових завдань і зон відповідальності між ними й архітекторами.

Інтеграція RTE в проект — людину призначено на цю роль нещодавно, тому певні аспекти роботи ще варто поліпшувати. Наприклад:

на загальних ART-зустрічах під час дискусій взаємних залежностей і ризиків окремих команд витрачають час усіх учасників замість того, щоб зробити це окремою зустріччю з обмеженим, проте цільовим, оточенням;
невизначеність формату репортингу — досі незрозуміло, на які звіти сподівається центральний APMO і про що саме звітувати;
порядку денного й тривалості загальних зустрічей часто не дотримуються;
мету майбутніх поліпшень радше продиктовано SPCs, ніж критично усвідомлено й аргументовано Scrum-майстром програмного рівня (RTE).

Певен, що ситуацію поліпшуватимуть.

Висновки

Як говорив класик: «Ітоги подвєдьом...» SAFe — це не панацея від усіх неприємностей, пов’язаних з керуванням масштабними Agile-проектами, проте — це корисний інструмент у разі ефективного застосування. У нас у проекті була мета, яку SAFe, як інструментарій, мав виконати. Якщо говорити загалом — цей інструментарій ліпше використовувати за таких умов:

Менеджмент проекту або C-Level компанії чітко усвідомлює потребу в процесних змінах — використовувані методи або не приносять сподіваного результату — цінності, або некоректно імплементовані, або не дають змоги масштабуватися, або не приводять до досягнення стратегічних цілей.
У проекті працює від 40 людей — SAFe радить діапазон від 50-125, проте можна стартувати навіть з 35-40 людьми.
Це економічно рентабельно — SAFe — задоволення не з дешевих, його імплементація обійдеться в кругленьку суму.
Поточний процес не виправдовує себе — напрацювання, ліпші практики або їхній мікс, адаптованих під конкретні завдання, більше не приносить результату й не виправдовує операційних витрат на оптимізацію.
Ви працюєте на західного замовника або компанія орієнтована на західний ринок — технологічні й процесні інновації завжди починаються звідти. Тим паче, що у вітчизняний комерційний сектор SAFe повноцінно ввірветься лише в найближчі років п’ять, а в державний — через 20 за сприятливих умов (особистий прогноз).
Проект масштабується — компанія планує розширюватися, і координація програмно-портфельного рівня є невіддільною частиною стратегії розвитку.

Якщо зазначені основні передумови схиляють, а масштаб проекту дає змогу впровадити фреймворк — варто спробувати й експериментувати, будувати свій шлях використання найліпших світових практик, адаптованих під специфічні умови середовища вашого проекту.