Scaled Agile Framework® (SAFe®)

Scaled Agile Framework^® (SAFe^®) - це набір організаційних шаблонів і шаблонів робочих процесів для реалізації agile-методик у масштабі всієї компанії. Фреймворк являє собою сукупність знань, куди входять структурований посібник із ролей та обов'язків, способи планування роботи та управління нею, а також відповідні цінності.

Офіційний сайт фреймворку https://www.scaledagileframework.com/

SAFe^® застосовують у безлічі agile-команд, забезпечуючи узгодженість, допомагаючи виконувати спільну роботу і постачання. В її основу лягли три основні блоки знань: гнучке (agile) розроблення програмного забезпечення, "ощадливе" (lean) розроблення продукції та системне мислення.

SAFe надає структурований підхід до масштабування agile-методик у міру зростання бізнесу. SAFe має чотири конфігурації, які підходять для різного масштабу застосування: Essential SAFe, Large Solution SAFe, Portfolio SAFe і Full SAFe.

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

Більше 50% позицій Project manager на різних платформах мають вимоги знання або сертифікації, і тому SAFe є однією з найпопулярніших масштабованих agile-фреймворків постачання, а всесвітня спільнота користувачів SAFe продовжує розвивати її.

Основні принципи SAFe

Описують культуру, яку має просувати керівництво, і поведінку людей у цій культурі для ефективного використання цого фреймворка.

Відповідність

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

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

Вбудована якість

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

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

Прозорість

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

Виконання програми

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

Керівництво

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

Основні принципи SAFe

Принципи Scaled Agile Framework передбачають поліпшення компанії загалом завдяки ухваленню гнучких і ощадливих рішень з охопленням усіх функціональних та організаційних одиниць.

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

Принцип № 1. Дивіться з погляду економіки

Згідно з теоріями про процес розроблення продуктів, наведеними в бестселерах Дональда Райнертсена, для досягнення найкоротшого стійкого часу виконання нового замовлення необхідно, щоб кожна людина в ланцюжку ухвалення рішень розуміла економічні наслідки затримок.

Швидкого і частого постачання не завжди достатньо. Згідно з SAFe, по всій організації необхідно розподілити такі завдання: визначення послідовності робіт для отримання максимальної вигоди, розуміння економічних компромісів і роботу в рамках "ощадливих" бюджетів. Багато концепцій та інструментів спираються на теорії Райнертсена про процес розробки продуктів.

Принцип № 2. Застосовуйте системне мислення

Scaled Agile Framework^® створює умови для застосування системного мислення в трьох основних галузях: власне рішення, компанія, яка займається розробкою системи, і потоки створення цінності (VSM). Рішеннями можуть бути продукти, послуги або системи, що постачаються клієнтам, як внутрішнім, так і зовнішнім стосовно підприємства.

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

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

Принцип № 3. Допускайте варіативність; зберігайте варіанти

За замовчуванням проектування систем і програмного забезпечення є заняттям із невизначеним результатом. Цей принцип розв'язує проблему невизначеності шляхом введення концепції варіативного проектування (Set-Based Design), яке вимагає зберігати в циклі розроблення безліч вимог і варіантів розроблення протягом тривалого часу. Варіативне проєктування спирається на емпіричні дані, щоб до остаточного варіанту розроблення можна було переходити на пізніших етапах.

Варіативне проєктування допомагає ухвалювати обґрунтовані рішення в періоди невизначеності шляхом виявлення варіантів та очікуваних кінцевих результатів; це схоже на стратегічну ставку. Важливу роль у варіативному проєктуванні відіграють "контрольні точки навчання", які пов'язані з крайнім терміном ухвалення рішення.

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

Принцип № 4. Виконуйте інкрементальні збірки зі швидкими циклами навчання, інтегрованими в процес

Як і принцип № 3, цей принцип спрямований на усунення ризиків і невизначеності за допомогою контрольних точок навчання. Недостатньо, щоб працездатність довела кожна складова частина системи. Необхідно розглянути систему в цілому, щоб оцінити можливість технічної реалізації поточних варіантів розробки.

Щоб прискорити цикли подальшого навчання, необхідно регулярно планувати послідовності точок інтеграції. Ці точки інтеграції є прикладом циклу Волтера Е. Шухарта плануй - роби - перевіряй - коригуй, що є схемою для постійного поліпшення якості та механізмів контролю варіативності розроблення. SAFe часто використовує роботи Шухарта та інші роботи, натхненні його працями.

Принцип № 5. Контрольні точки повинні ґрунтуватися на об'єктивній оцінці працюючих систем

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

Принцип № 6. Візуалізуйте та обмежуйте незавершені роботи (WIP), зменшуйте обсяг робіт і керуйте довжиною черг

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

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

Цей принцип служить орієнтиром в оптимізації цих завдань для досягнення найкращих результатів.

Принцип № 7. Застосовуйте каденції, виконуйте синхронізацію за допомогою крос-доменного планування

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

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

Принцип № 8. Розкрийте внутрішню мотивацію працівників розумової праці

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

Принцип № 9. Децентралізуйте прийняття рішень

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

Як працює SAFe?

Організації, готові впровадити SAFe, зазвичай мають підтримку на рівні керівництва, сильний намір змінитися і фундамент у вигляді scrum.

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

1. Досягти переломного моменту.
2. Навчити менеджерів з організаційних змін, які використовуватимуть принципи ощадливості та agile.
3. Навчити керівників, менеджерів і провідних фахівців.
4. Створити центр передових технологій, що дотримується принципів ощадливості та гнучкості.
5. Визначити потоки створення цінності та поїзди agile-релізів (ART).
6. Створити план реалізації.
7. Підготуватися до запуску ART.
8. Навчити команди та запустити ART.
9. Навчитися реалізації ART.
10. Запустити більше ART і потоків створення цінності.
11. Розширити схему до рівня всього портфеля.
12. Підтримувати і покращувати.

Чим SAFe відрізняється від інших масштабованих agile-платформ?

Попри те, що платформа Scaled Agile Framework® (SAFe®) є широко поширеною серед підприємств з великими командами розробників програмного забезпечення, з плином часу набрали популярності й інші масштабовані agile-платформи.

Усі платформи для масштабування agile об'єднують п'ять основних компонентів: натхнення від 12 принципів маніфесту agile-методології, послідовність дій, синхронізація, scrum і методи якісної розробки. Розуміння походження інших платформ, основних відмінностей та умов їхнього успішного застосування допоможе організаціям обрати структуру, яка оптимально відповідає їхнім потребам.

SAFe і Scrum@Scale

У Scrum@Scale (S@S) кожен співробітник є частиною взаємозамінної scrum-команди. Залежно від цілей мережі scrum-команд об'єднуються, утворюючи екосистему. Платформа S@S призначена для створення мережі scrum-команд за допомогою "немасштабованої архітектури", тобто основні ролі та події scrum масштабуються лінійно, без введення в процес нових рушійних сил.

Наприклад, для дуже складного продукту з 25 scrum-командами одного Scrum of Scrum (SoS) може виявитися недостатньо, і тоді знадобиться Scrum of Scrum of Scrums (SoSoS) і Scrum of Scrum of Scrums Master (SoSM).

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

Як і SAFe, платформа S@S пропонує довідкові матеріали, доступні онлайн, зокрема докладний посібник Scrum@Scale, що набирає популярності.

SAFe і Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) застосовує мінімалістичний підхід до ролей, структури та артефактів. Там, де SAFe пропонує чотири конфігурації розміщення дедалі більших команд з дедалі складнішими рішеннями, LeSS пропонує дві: LeSS для організацій з 2-8 командами та LeSS Huge для організацій більш ніж з 8 командами.

Згідно з LeSS, власники продуктів повинні володіти всіма повноваженнями і стратегічним впливом на контент, тоді як SAFe пропонує більш демократичний підхід. У той час як у SAFe багато факторів впливають на стратегію, LeSS спирається на клієнтоорієнтований підхід із фокусом на клієнтах, які оплачують послуги.

Як і S@S, LeSS масштабується на основі подій, артефактів і ролей scrum. І SAFe, і LeSS надають особливого значення системному та ощадливому мисленню, а також схожим керівним принципам. Однак LeSS приділяє велику увагу скороченню відходів у всій організації з метою постійної оптимізації.

SAFe і DA

На відміну від інших описаних платформ, платформа Disciplined Agile (DA) є набором інструментів, який дозволяє організаціям вирішувати, який спосіб роботи підходить їм найкраще.

Вона пропонує спрощене agile-управління на основі scrum і kanban, а також знання, що сприяють трансформації, у таких галузях, як управління персоналом і фінансами, менеджмент, DevOps, управління портфелем і багатьох інших.

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

SAFe і Spotify

"Модель" Spotify - це автономний набір практик з акцентом на людей, який можна застосовувати для координації agile-команд. Вона не задумувалася як модель або платформа, але деякі компанії впровадили її саме в такому варіанті.

Модель Spotify орієнтована на самоорганізовані багатофункціональні команди, розташовані в одному місці; їх називають "загонами" (еквівалент scrum-команд). Для порівняння, у SAFe немає застереження щодо спільного знаходження команд, яке рекомендується для проведення PI-планування.

Загони організовані у більші підрозділи, які називаються "кланами". Проблеми, викликані нечисленними залежностями між загонами, за необхідності вирішуються на основі принципів Scrum of Scrums. Обмін знаннями відбувається через "відділи" та "гільдії"; такі неформальні групи організовуються на основі наборів навичок та інтересів.

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

SAFe 5.0

Основним принципом SAFe є те, що ця платформа продовжує розвиватися спільно зі спільнотою своїх користувачів по всьому світу. Зовсім недавно компанія Scaled Agile, Inc. випустила SAFe версії 5.0.

Основними змінами стали додавання принципу № 10 "Організація відбувається навколо цінності" та зміна кроку 12 з "Підтримуйте та покращуйте" на "Прискорюйте". Насправді змін набагато більше.

Висновок про SAFe

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