SAFe

Головна ідея: Agile Release Train

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

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

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

Ця спільна межа називається Program Increment, або PI. Він триває вісім-дванадцять тижнів — найчастіше п’ять двотижневих ітерацій — і саме навколо цієї одиниці організовано все у SAFe.

Чотири конфігурації

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

• Essential SAFe

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

• Large Solution SAFe

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

• Portfolio SAFe

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

• Full SAFe

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

Хто існує над командою

Кожна команда потяга зберігає звичні ролі Scrum: Product Owner, Scrum Master, розробники. Далі SAFe додає чотири ролі рівня потяга. Розуміння того, чим володіє кожна, і не дає цьому шару перетворитися на управлінський рівень із новими назвами.

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

PI Planning і є фреймворком

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

PI Planning триває два повні дні. Присутні всі команди потяга — усі 50–125 осіб, в одному приміщенні або на одному дзвінку. Ось приблизно як минають ці два дні.

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

Інші події

PI Planning відкриває інкремент. Ще чотири події підтримують його рух і закривають його.

System Demo — це те, що тримає потяг чесним. Показати власний компонент у відриві може будь-хто. Показувати всю інтегровану систему кожні два тижні значно важче — і саме ця дисципліна не дає інтеграційному боргу накопичуватися до межі PI.

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

Десять Lean-Agile принципів

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

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

Саме за дев’ятим і десятим принципами варто міряти впровадження. Якщо ухвалення рішень не децентралізувалося, а команди досі організовані за технічними компонентами, то встановлене не є SAFe — це стара структура, що проводить події SAFe.

Чесна критика

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

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

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

Як це виявляється в реальній поставці

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

Якщо відповідь — «ми переплановуємо й повідомляємо потяг на найближчому ART Sync», фреймворк працює як задумано. Якщо відповідь — «ми все одно це зробимо, а порушимо питання на Inspect & Adapt», то організація купила десятитижневий waterfall із дводенним стартом — і отримає результати waterfall, описуючи їх словником agile.

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

• Цілі PI трактуються як фіксовані зобов’язання за обсягом, а не як прогноз.
• Впровадження Portfolio чи Full SAFe до того, як хоч один потяг стабільно постачає.
• Немає System Demo справді інтегрованої системи — інтеграційний борг падає на межі PI.
• IP-ітерація, заповнена взятими фічами, — з плану зникає весь запас.
• Потяг, зібраний із команд, що не мають спільного продукту, дає координацію без мети.

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

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

• МенеджментLeSSLeSS (Large-Scale Scrum) зберігає одного Product Owner, один Product Backlog, один спринт і один придатний до поставки інкремент — незалежно від кількості команд. Він масштабується прибиранням організаційної структури, а не додаванням, і тому є найвимогливішим до впровадження та найближчим до справжнього Scrum. На цій сторінці — десять принципів, розшарування «правила — гайди — експерименти», усі події LeSS і обидва варіанти.
• МенеджментNexusNexus — це фреймворк масштабування від Scrum.org для трьох-дев’яти команд на одному продукті. Nexus додає до Scrum рівно одну зону відповідальності — команду інтеграції, відповідальну за єдиний інтегрований інкремент, — виходячи з того, що на цьому масштабі ламається саме інтеграція, а не планування. На цій сторінці — хто входить до цієї команди, три артефакти й усі п’ять подій.
• МенеджментScrum@ScaleScrum@Scale — це фреймворк масштабування Джеффа Сазерленда, побудований на двох пов’язаних циклах — що будується і як, — які повторюються фрактально на кожному рівні. Він модульний, а не конфігурований: ви впроваджуєте лише ті компоненти, яких вимагає ваше вузьке місце, а решти не чіпаєте. На цій сторінці — усі компоненти обох циклів, дві точки їх дотику та ролі й події, які кожен додає.