SAFe

SAFe на одному екрані

Спершу — увесь фреймворк. SAFe визначає події на чотирьох рівнях, але потяг працює лише на перших двох: усе, що вище за Agile Release Train, необовʼязкове й зʼявляється пізніше, якщо взагалі зʼявляється. Перша таблиця перелічує кожну подію з її рівнем, ритмом, учасниками й результатом. Друга — хто сидить на кожному рівні і чим володіє.

Одиниця — це потяг

Почнімо з проблеми, яку SAFe намагається розвʼязати. Одна Scrum-команда з восьми осіб працює нормально. Поставте шістдесят людей на один продукт — і щось ламається. Не написання коду, а координація. Команда A завершує те, що команді B було потрібне три тижні тому. Ніхто не знає, хто що вирішив. Інтеграція відбувається наприкінці, і нічого не збігається.

Відповідь SAFe — Agile Release Train, скорочено ART. ART — це довгоживуча група з пʼяти-дванадцяти команд, зазвичай 50–125 осіб, які разом планують, разом беруть зобовʼязання й разом постачають. Верхня межа навмисна: SAFe посилається на число Данбара — приблизну стелю близько 150 робочих стосунків, які людина здатна підтримувати.

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

Ця спільна межа — Planning Interval, або PI. Він триває вісім-дванадцять тижнів — найчастіше чотири двотижневі ітерації розробки й одна ітерація Innovation and Planning — і саме навколо цієї одиниці організовано все у SAFe. До SAFe 6.0 у березні 2023 року він називався program increment, і більшість написаного про SAFe досі вживає цю назву. Перейменування каже про справжнє: PI — це ритм планування, а не дата релізу. SAFe формулює це як «develop on cadence, release on demand»: планувати разом у сталому ритмі, а постачати тоді, коли шматок готовий.

Роль Release Train Engineer варта ближчого погляду, бо її легко прочитати неправильно. RTE — це служачий лідер потяга: він проводить події потяга, ганяється за перешкодами через межі команд і тримає потік видимим. Він не роздає роботу командам і не вирішує, що будувати. RTE, який робить бодай одне з цього, перетворився на програмного менеджера з посадою за SAFe. Поруч із командами стоять дві допоміжні групи: System Team, яка будує й підтримує спільне середовище інтеграції й тестування, від якого залежить System Demo, і Shared Services — фахівці на кшталт архітекторів безпеки чи даних, яких кожна команда потребує час від часу, але жодна — на повний день.

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

Ще одна примітка щодо назв, бо вона свіжа. У червні 2026 року Scaled Agile випустила AI-Native SAFe — другу операційну модель із меншими командами, підсиленими ШІ, коротшими циклами й новою роллю AI value architect. Вона стоїть поруч із наявним фреймворком, який компанія тепер називає Core SAFe, а не замінює його. Усе на цій сторінці — Core SAFe.

Чотири конфігурації — почніть із найменшої

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

• Essential SAFe

  Один Agile Release Train і нічого над ним. Це мінімальний життєздатний SAFe і те, з чого має починатися будь-яке впровадження. Якщо ваша проблема — координація 50–100 осіб на одному продукті, це вся відповідь.

• Large Solution SAFe

  Кілька потягів будують одну дуже велику систему — літаки, оборонні системи, телеком-інфраструктура. Додає Solution Train для координації ART. Поза справді великою інженерією трапляється рідко.

• Portfolio SAFe

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

• Full SAFe

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

Дорожня карта впровадження

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

• 1. Reaching the Tipping Point — досягти переломного моменту
• 2. Train Lean-Agile Change Agents — навчити агентів змін
• 3. Create a Lean-Agile Center of Excellence — створити центр компетенцій
• 4. Train Executives, Managers, and Leaders — навчити керівників
• 5. Lead in the Digital Age — керувати в цифрову епоху
• 6. Organize Around Value — організуватися навколо цінності
• 7. Create the Implementation Plan — скласти план впровадження
• 8. Prepare for ART Launch — підготувати запуск ART
• 9. Train Teams and Launch ART — навчити команди й запустити ART
• 10. Coach ART Execution — коучити роботу ART
• 11. Launch More ARTs and Value Streams — запустити більше ART і потоків цінності
• 12. Enhance the Portfolio — посилити портфель
• 13. Accelerate — прискорити

У цьому списку варто помітити дві речі. Крок 6 вирішує все інше: організуватися навколо цінності означає провести потяг уздовж шляху, яким продукт іде до клієнта, а потяг, проведений навколо наявних відділів, координуватиме їх, нічого не змінюючи. І перший потяг рушає лише на кроці 9. Кроки 2, 4 і 9 — це навчання, а навчання й сертифікація SAFe — ще й бізнес-модель компанії, яка його публікує, і це варто тримати в голові, коли дорожня карта проводить першу половину в класах.

PI Planning, IP-ітерація та Inspect & Adapt

Якщо організація візьме зі SAFe лише одне, це має бути PI Planning. Більшість користі, про яку кажуть команди, походить саме звідси, і це та практика, яку варто запозичити, навіть якщо решту ви ніколи не впровадите. Він триває два повні дні, і присутні всі команди потяга — усі 50–125 осіб, в одному приміщенні або на одному дзвінку. SAFe публікує для нього стандартний порядок денний.

Три терміни з цього порядку денного потребують по реченню. ROAM розкладає кожен ризик рівня потяга в один із чотирьох станів: Resolved — більше не турбує; Owned — хтось його взяв і звітуватиме; Accepted — розвʼязати неможливо, і потяг іде далі, знаючи про нього; Mitigated — є план, що зменшує його вплив. Цінність у тому, що ризик не може лишитися в пʼятому стані — «згадали».

Цілі PI — короткі твердження про те, чого кожна команда має намір досягти за PI, сформульовані мовою бізнесу, а не як список фіч. Кожна з них або committed — команда її обіцяє, — або uncommitted: запланована в спроможність, але не обіцяна, щоб команда мала простір поглинути несподіванки. Business Owners дають кожній цілі бізнес-цінність від 1 до 10, і ці числа повернуться наприкінці PI.

Голосування впевненості — це «кулак пʼяти»: пальці показує кожен, а не лише лідери команд. План із середнім балом три й вище приймають; нижчий — переробляють, а окремі одиниці й двійки розпитують, а не перекривають більшістю.

IP-ітерація

IP-ітерація варта уваги, бо саме її організації скорочують першою, і це помилка. Це ціла ітерація наприкінці PI, у якій немає запланованої роботи над фічами. Команди використовують її для інновацій, навчання, інфраструктури, фінальної інтеграції PI, для Inspect & Adapt і наступного PI Planning — і як буфер, що поглинає все, у чому план PI помилився.

Inspect & Adapt

Inspect & Adapt закриває PI у три частини. PI System Demo показує все, що потяг збудував за PI, в інтегрованому вигляді. Огляд метрик проходить числами, за якими потяг домовився стежити, починаючи з міри передбачуваності з наступного розділу. А воркшоп із розвʼязання проблем бере найважливішу проблему й проходить її за шість кроків: погодити, яку проблему розвʼязувати; розібрати її корені діаграмою «риб’ячий скелет» і «пʼятьма чому»; знайти найбільшу першопричину аналізом Парето; переформулювати проблему; накидати рішення; і перетворити найкращі на покращення для наступного PI Planning.

Як SAFe вимірює себе — і як обходять кожну метрику

SAFe групує свої метрики у три домени: outcomes — чи отримує бізнес те, за що заплатив; flow — наскільки добре цінність рухається системою; і competency — наскільки добре організація практикує фреймворк. Більшу частину роботи роблять чотири інструменти, і кожен має відомий спосіб зіпсуватися.

Міра передбачуваності

На Inspect & Adapt Business Owners оцінюють, що кожна команда справді поставила, проти бізнес-цінності, яку вони дали її цілям на PI Planning. Бал команди — досягнута цінність, поділена на заплановану, а бал потяга — їхня сума. SAFe очікує від 80 до 100 відсотків: достатньо високо, щоб бізнес міг на це планувати, і достатньо низько, щоб команди ще брали на себе певний ризик.

Шість метрик потоку

SAFe 6.0 називає шість метрик потоку. Більшість із них — метрики Kanban під новими назвами, і це варто знати, бо арифметика під ними — закон Літтла, процентилі замість середніх — пояснена на сторінці про Kanban і діє без змін.

WSJF — і що з нього викидає версія SAFe

SAFe упорядковує беклоги за WSJF, Weighted Shortest Job First: вартість затримки, поділена на розмір роботи. Вартість затримки — це скільки коштує ще тиждень очікування, і SAFe оцінює її як суму трьох відносних балів — цінність для користувача й бізнесу, критичність за часом і зменшення ризику чи відкриття можливостей, — кожен за модифікованою шкалою Фібоначчі. Розмір роботи стоїть замість того, скільки вона триває. Першим іде елемент із найбільшим відношенням.

Ідея походить від Дональда Райнертсена, і версія SAFe змінює її двома способами, які варто знати. Райнертсен ділить вартість затримки в грошах на тривалість роботи; SAFe додає три ранги й ділить на оцінку розміру, а додавати ранги — це арифметика над числами, які кажуть лише «більше ніж»: невідомо, що 13 вартує рівно тринадцять одиниць. А розмір — це заміна тривалості, яка ламається саме там, де порядок важить найбільше: мала робота, що мусить чекати на іншу команду, коротка на папері й довга насправді. Як розмова про те, чому один елемент терміновіший за інший, WSJF корисний. Як формула, чий результат закриває суперечку, — це точність, якої немає у вхідних даних. Сторінка Roadmapping ставить його поруч із RICERICEReach, Impact, Confidence, Effort — бал для впорядкування ідейБал пріоритизації від Intercom: охоплення, помножене на вплив і впевненість, поділене на зусилля, тож гучну заяву без доказів знижують. Часу він не враховує — дата з договору й «було б непогано» отримують однаковий бал, — а вхідні числа є здогадами, тож суперечка, яку він змушує провести, цінніша за рейтинг.Докладніше в статті →Усі терміни, KanoKano modelяк задоволення реагує на фічуКласифікація фіч Норіакі Кано 1984 року за тим, як на них реагує задоволення клієнтів: обов’язкові (без похвали, коли є, і гнів, коли немає), лінійні (більше — краще), захопливі (радують, коли є, і за ними не сумують, коли немає), байдужі й зворотні. Вона каже, чого клієнти очікують, а не що будувати першим.Докладніше в статті →Усі терміни й MoSCoWMoSCoWMust have, Should have, Could have, Won’t have this time — must, should, could, won’tПравило пріоритизації з DSDM, що ділить вимоги на Must, Should і Could Have, а також Won’t Have this time, — єдина поширена модель, яка записує відмову. Must Have мають забирати не більше приблизно 60% зусиль, інакше нічим буде поступитися, коли оцінка зсунеться.Докладніше в статті →Усі терміни.

Нормалізовані story points

Для першого PI нового потяга SAFe дає рецепт оцінювання в однакових одиницях для всіх команд: дати команді вісім балів на кожного розробника-тестувальника за двотижневу ітерацію, відняти бал за кожен день відпустки чи свята, а історію, яку можна за пів дня збудувати й за пів дня протестувати, назвати 1. Це розумний спосіб отримати перший план. Але він робить один бал приблизно днем роботи, тож потяг, що зберігає цей рецепт, перетворив story pointsstory pointsвідносний розмір, не годиниОдиниця для оцінки відносного розміру задач беклогу — 8 приблизно вдвічі більше за 5, — навмисно не привʼязана до годин. Корисні для планування однієї команди й більше ні для чого: перетворені на ціль чи порівнювані між командами, вони роздуваються замість вимірювати.Докладніше в статті →Усі терміни назад на людино-дні — а щойно бали стають порівнянними між командами, хтось почне порівнювати за ними команди.

Чотири цінності й десять принципів

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

Ці чотири цінності 2023 року замінили набір SAFe 5 — alignment, built-in quality, transparency і program execution; built-in quality лишилася практикою, але вже не цінністю. Десять Lean-Agile принципів, у власному порядку SAFe:

• 1. Дивитися економічно — рішення є компромісами щодо грошей і затримок, тож робіть економіку явною.
• 2. Мислити системно — оптимізуйте весь потік, а не кожну команду окремо.
• 3. Припускати мінливість, зберігати варіанти — не фіксуйте дизайн у точці найменшого знання.
• 4. Будувати інкрементально швидкими інтегрованими циклами навчання — інтегруйте постійно, а не наприкінці.
• 5. Ставити віхи на обʼєктивній оцінці працюючих систем, а не на завершених документах.
• 6. Забезпечити безперервний потік цінності — прибрати черги й передачі роботи між командами.
• 7. Застосовувати ритм і синхронізацію через міждоменне планування — сталий ритм робить координацію звичкою.
• 8. Розкривати внутрішню мотивацію працівників знань — індивідуальні заохочення ламають співпрацю.
• 9. Децентралізувати ухвалення рішень — централізуйте лише рідкісні, далекосяжні рішення з ефектом масштабу.
• 10. Організовуватися навколо цінності — будуйте команди за тим, що отримує клієнт, а не за технічним компонентом.

Принцип 5 найрізкіше відділяє SAFe від Waterfall: віха — це працююча система, яку хтось бачив, а не підписаний документ. А за девʼятим і десятим принципами варто міряти впровадження. Якщо ухвалення рішень не децентралізувалося, а команди досі організовані за технічними компонентами, то встановлене не є SAFe — це стара структура, що проводить події SAFe.

Що показують дані — і аргументи проти

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

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

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

Де він вироджується

Ось діагностичне питання до будь-якого впровадження SAFe. На четвертому тижні команда виявляє, що одна з її цілей PI просто хибна: припущення під нею виявилося неправдивим. Що відбувається далі?

Якщо відповідь — «ми переплановуємо й повідомляємо потяг на найближчому ART Sync», фреймворк працює як задумано. Якщо відповідь — «ми все одно це зробимо, а порушимо питання на Inspect & Adapt», то організація купила десятитижневий waterfall із дводенним стартом — і отримає результати waterfall, описуючи їх словником agile. Посібник Defense Innovation Board США 2018 року «Detecting Agile BS» питає те саме різкіше: чи доходить працююче ПЗ бодай до частини справжніх користувачів щоітерації і чи змінює їхній відгук план?

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

• Цілі PI трактуються як фіксовані зобовʼязання за обсягом, а не як прогноз.
• Впровадження Portfolio чи Full SAFe до того, як хоч один потяг стабільно постачає.
• Потяг, проведений навколо наявних відділів, а не навколо потоку цінності, дає координацію без мети.
• Немає System Demo справді інтегрованої системи — інтеграційний борг падає на межі PI.
• IP-ітерація, заповнена взятими фічами, — з плану зникає весь запас.
• Передбачуваність звітують сумою потяга, тож команда з 60 відсотками й команда, що занижує план, із 125 усереднюються.
• Нормалізовані story points використовують для порівняння команд — оцінки роздуваються, доки порівняння не втратить сенс.
• RTE, який роздає роботу й вирішує обсяг, — програмний менеджер із новою посадою.
• Inspect & Adapt як звіт про статус — без воркшопу з розвʼязання проблем і без покращень у наступному плані.
• Сертифікати, пораховані як впровадження: навчили всіх, а в тому, хто вирішує, не змінилося нічого.

Коли це застосовувати

Пов’язані сторінки

• МенеджментLeSSLeSS (Large-Scale Scrum) — фреймворк, що масштабує Scrum, ведучи багато команд як одну: один Product Owner, один беклог, один спринт, один продукт. Він масштабується прибиранням організаційної структури, а не додаванням, і тому найвимогливіший до впровадження та найближчий до самого Scrum. Сторінка починається з усіх правил і всіх подій на одному екрані; далі — розмасштабування й визначення продукту, фіче-команди й те, що LeSS прибирає, десять принципів, кожна подія, LeSS Huge і його Requirement Areas, що показують чотири впровадження з датами і де все це вироджується.
• МенеджментNexusNexus — фреймворк від Scrum.org для 3–9 Scrum-команд, що будують один продукт, і він додає до Scrum рівно одну зону відповідальності: Nexus Integration Team. Його передумова: на цьому масштабі першою ламається інтеграція, а не планування. Сторінка починається з усіх елементів Nexus на одному екрані — кожна подія і що вона робить зі своїм відповідником у Scrum, і три артефакти з їхніми зобовʼязаннями; далі — чому доповнення лише одне, хто насправді входить до команди інтеграції, кожна подія за гайдом 2021 року і що змінилося з 2018-го, як знаходити й прибирати залежності, як Nexus співвідноситься з LeSS, SAFe і Scrum@Scale, що показують дані і де все це вироджується.
• МенеджментScrum@ScaleScrum@Scale — фреймворк Джеффа Сазерленда для масштабування Scrum на всю організацію: дванадцять компонентів на двох повʼязаних циклах — що будувати і як. Команди обʼєднуються по чотири-пʼять у Scrum of Scrums, той самий патерн повторюється на кожному рівні, а нагорі дві групи керівників працюють як Scrum-команди. Сторінка починається з усіх дванадцяти компонентів на одному екрані — для чого кожен, хто його несе і як виглядає організація, де його не несе ніхто; далі — масштабовані ролі й події, кожен цикл, де цикли зустрічаються, як упроваджувати фреймворк у порядку, якого вимагають ваші проблеми, як він співвідноситься з Nexus, LeSS і SAFe, що показують дані і де все це вироджується.