Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Що нового у SAFe 6.0. Огляд важливих нововведень

Мене звати Альона Лубчак, я Co-Founder & SAFe Program Consultant в компанії E5. Останні 5 років займаюся Agile трансформаціями та управлінським консалтингом, впровадженням Scrum, Kanban фреймворків та їх адаптацією до бізнес-обмежень компаній.

У цій статті хочу розповісти про головні зміни у новій версії SAFe 6.0, яку Scaled Agile презентували цієї весни. 15 березня 2023 року була офіційно презентована нова версія SAFe. З версії 5.1 фреймворк одразу оновився до версії 6.0.

В цій статті я зупинюся на основних змінах, які відбулись в самому фреймворку в порівнянні з попередніми версіями.

З концептом самого фреймворку я вже знайомила читачів DOU у цій статті, а також розробила безкоштовний курс SAFe 5.1 українською, який допоможе розібратись з самим фреймворком.

Scaled Agile Framework 6.0

Тож, перейдімо до основних змін у новій версії.

1. Запровадження концепту потоків на всіх рівнях

Однією з ключових змін у фреймворку є впровадження поняття потоку (Flow) на всіх рівнях: Team Flow на рівні команди, ART Flow на рівні програми, Solution Train Flow на рівні Large Solution та Portfolio Flow на рівні Portfolio.

SAFe Flow: Team Flow, ART Flow, Solution Train Flow, Portfolio Flow

Team Flow (командний потік) — описує рекомендації для команди, як доставляти цінність кінцевому користувачу (business value). Який би фреймворк не використовувала команда (Scrum, Kanban, FDD, XP etc.) для своєї роботи, ці рекомендації будуть валідними.

ART Flow (потік гнучкого потягу релізу або команд) — описує рекомендації для декількох команд (від 5 до 12), які об’єднані спільною метою й працюють над розробкою спільного продукту. Сумарно в одному ART (потязі) може працювати від 50 до 125+ людей.

Solution Train Flow (потік потягу солюшену) — описує рекомендації для доставки цінності вже декількома потягами й не має обмежень за кількістю людей, залучених в розробці. Ці рекомендації стосуються розробки дійсно великих комплексних систем.

Portfolio Flow (потік портфоліо) — описує рекомендації щодо організації роботи компанії над високорівневими ініціативами (Epics), які потім втілюються в життя командами. Ці рекомендації більше сконцентровані на управлінні життєвим циклом високорівневих ініціатив (з тривалістю від 6 місяців), управлінні бюджетами, формуванні бачення продукту, стратегічних тем тощо.

Також переформульовується принцип SAFe № 6 Make Value Flow without Interruptions (Створюйте потік без переривань), де описуються загальні рекомендації з вибудови потоку на будь-якому рівні.

Щоб потік запрацював на кожному з рівнів, рекомендується відстежувати 3 напрями:

  • Outcomes (результати): рішення, яке ми розробляємо, задовольняє наших клієнтів та бізнес?

Тут можна використовувати як кількісні (метрики) так і якісні (опитування, зворотний зв’язок) показники.
Наприклад, ви можете використати OKR (Objective Key Results), стратегічні теми та KPI (Key Performance Indicators) для опису бажаного результату й потім його прослідкувати.

  • Flow (потік): наскільки ефективно наша організація доставляє цінність нашому користувачу?

Для відповіді на це питання рекомендується дотримуватись 8 рекомендацій:

  1. Візуалізувати та обмежувати роботу, над якою працюєте (WIP).
  2. Прибирати вузькі місця потоку.
  3. Мінімізувати залежності всередині потоку.
  4. Швидко отримувати зворотний зв’язок.
  5. Працювати з невеликими партіями (релізами).
  6. Зменшувати довжину черги.
  7. Оптимізувати час «В Зоні» (час фокусування).
  8. Позбуватись застарілих політик та практик.

А також відстежувати метрики потоку такі як: Flow Distribution, Flow Velocity, Flow Time, Flow Load, Flow Efficiency, Flow Predictability.

  • Competency (компетенція).

Наскільки наша організація професійна в компетенціях, які потрібні для гнучкості бізнесу (business agility)? Тут в пригоді стануть безкоштовні чек-листи та опитувальники, які допоможуть визначити зони покращення вашої компанії.

2. Business Agility Value Stream

У версії 6.0 фреймворку кристалізувався Business Agility Value Stream (Потік цінності гнучкості бізнесу). Для великих корпорацій, де часто реалізація якоїсь ініціативи могла займати 1,5-2 роки, цей концепт дійсно дає гнучкість і шанс зменшити час реалізації до 2-6 місяців.

Зокрема, потрібно виділили основні кроки, які необхідно пройти кожній ідеї в корпорації: від ідентифікації можливості на ринку до релізу MVP та отримання зворотного зв’язку від цього ринку. Детальніше з рекомендаціями можна ознайомитись тут.

3. Agile Business and Technology

Варіантів, яким чином може бути організована співпраця між Бізнесом та Технологічними відділами є велика кількість. Найпопулярніші описані в окремому матеріалі, який доступний в 6 версії.

Зокрема, це може бути й комбінація різних портфоліо в компанії, може бути використання Lean-Agile практик в операційній діяльності бізнесу, може бути комбінація операційних та девелопмент потоків цінностей.

А також організація роботи команди топменеджменту як Agile Executive Team зі своїм беклогом задач, власником продукту та командним коучем.

4. Деталізація рівня Large Solution

Рівень Large Solution був найменше описаний щодо різних церемоній та рекомендацій в попередніх версіях. У версії 6.0 додались рекомендації саме щодо церемоній (нарад) та координації, які необхідно проводити для координації роботи декількох потягів (ART).

Зокрема окрім перепланування та Solution demo, описані різні синхронізації (Solution Train Sync), координації релізів тощо.

5. Оновлення опису ролей та зміна Scrum Master на Scrum Master/ Team Coach

Кожна з ролей в SAFe тепер описана детальніше. Додані обов’язки кожної з ролей у вигляді схеми ключових зон відповідальності. Також описані ключові співпраці певної ролі з необхідними для неї іншими ролями.

Наприклад, System Architect має активно співпрацювати з крос-функціональними командами, іншими архітекторами, спеціалізованими командами, RTE й менеджерами продукту.

Роль Scrum Master наразі називається Scrum Master/ Team Coach, оскільки не всі команди працюють по Scrum й можуть не мати свого Scrum Master.

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

6. Зміни в SAFe implementation roadmap та ролі SPC (SAFe Practice Consultant)

Дорожня карта впровадження SAFe має незначні зміни. Зокрема прибрали попередній крок Waterfall/ Ad Hoc Agile, коли в компанії був якийсь процес, оскільки не всі компанії з нього стартують. Крок Identify ARTs and Value Streams перейменували в Organize Around Value, щоб відобразити 10-й принцип Organize around value та додали воркшоп по ідентифікації ART та Value Streams.

Extend to the Portfolio крок також перейменували в Enhance the Portfolio. Це відображає той факт, що впровадження рівня Portfolio не обов’язково має відбуватись аж наприкінці дорожньої карти впровадження SAFe.

SAFe Practice Consultants (SPCs) роль, яка в попередніх версіях називалась SAFe Program Consultants, значно розширилась.

Зокрема, явно прописуються обов’язки у впровадженні SAFe, керуванні змінами, прискоренні Business Agility, коучингу потоків всіх рівнів та впровадженні Lean-Agile мислення.

В попередніх версіях акцент же був більш на рекомендаціях з виконання кожного кроку SAFe Implementation Roadmap та допомозі організації у провадженні SAFe.

7. Зміни в Lean-Agile мисленні

House of Lean, присутній в попередніх версіях, прибрали. Замість нього з’явились 5 принципів Lean:

Також в Core Values замість Build-In Quality та Program Execution з’явились Respect for People та Relentless Improvement.

8. AI, BigData, Cloud

SAFe не міг не відобразити в новій версії технології, які суттєво впливають на розробку продуктів сьогодні.

Тому з’явились нові елементи на схемі, які у відповідних статтях описують використання цих технологій компаніями: AI (Artificial Intelligence), Big Data та Cloud.

9. Термінологія

Основні зміни термінології стосуються усунення згадок про рівень програми. Тому замість Program Backlog, Program Execution, Program PI Objectives тощо — тепер використовуються терміни ART Backlog, ART Execution, ART PI Objectives.

Agile Program Management Office (APMO) трансформувався в Value Management Office (VMO). Scrum of Scrums (SoS) став Coach Sync, а DSU (Daily Sync Up) — Team Sync. Терміни, пов’язані з Solution, такі як Solution Board, Solution Epic, Solution PI Objective перейменовані в Solution Train Planning Board, Solution Train Epic, Solution Train PI Objectives відповідно.

Детальне відео релізу SAFe 6.0 ви можете знайти тут, а також текстовий опис тут.

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коли вас 1000 на программу, 10-15 команд з різних контор і т.д. — буває корисно. Теж скептично відносився доки не побачів як працює. Особливо мені подобається, що реліз трейн інженери з компанії, що ставлять процесс в конторі у клієнта можуть пояснити босу замовнику, що пріоритет 10 для усіх задач не можливий, що існують залежності між задачами, що 9 вагітних жінок не народять дитину за 1 місяць і т.д. І тобі не треба через це із замовником лаятись — цим займається спеціаліст, ти тільки йому пояснуюєш (до того ж як программісту) які в тебе задачі, проблеми та залежності на інші команди, дизайнт і и.д. і займаєшся своеє роботою — а не щоденним мітингами на 10 начальників, на яких з’ясовуються чому ще нічого не зроблено і коли буде.Коли фреймверк не працює, тоді як і завжди коли його надають в руки повним профанам які взагалі в виробництві софту не розуміються, там будь який фреймворк не спрацює.

Маю зазначити що певне раціо у всьому тому є. В теорії. На практиці з переходом на це все працювати стало важче, стало більше релігійних ритуалів. А оці спроби напланувати роботу на квартал взагалі викликають бажання лаятися та/або відвідати вино-горілчаний магазин.
У середні віки часті хвороби були не тому що замало молилися, а тому що антисанітарія скрізь.

спроби напланувати роботу на квартал

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

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

SAFe постійно розвивається, й зміна версії зазвичай супроводжується або статтями або невеликим онлайн курсом. Це все безкоштовно. Додаткові відео курси за наявності діючої сертифікації. Багато також вебінарів, статей, як, наприклад, ця :)

А щодо нереалістичних цілей, то це ж питання до команд в ART навіщо давали commitments на такі нереалістичні цілі :)
Й дуже вас підтримую — фреймворк дійсно дивиться на досвід впроваджень й додає нові ідеї. Зокрема більше інструкцій на рівні Large Solution в цій версії саме на основі зворотнього зв’язку.

навіщо давали commitments на такі нереалістичні цілі

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

доречі, в такому випадку нагадаю, що в SAFe є 2 буфери:
1) з точки зору scope — uncommitted objectives (по capacity влазять, але коменди сумніваються)
2) з точки зору часу — Innovation & Planning Iteration — місце, де є в тому числі буфер якщо щось не стигли

Але так, першопричина — це як раз тиск на команди. Тут певно порада RTE в таких кейсах візуалізувати довстрокові наслідки такого тиску. Бо хоч на плануванні й отримується «так» за рахунок тиску, в довгостроковій перспективі все рівно в озвучані терміни не вписуються команди. Тому ні про яке predictable delivery говорити не можемо.

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