Підручник SAFe (Scaled Agile Framework).

Сейф структура дозволяє команді для,

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

SAFe вперше був розроблений у цій галузі та розроблений у Дін Леффінгвеллкниги та блог. Версія 1.0 є першим офіційним випуском у 2011 році. Остання версія 4.6 була випущена в жовтні 2018 року. Вона надає вказівки для роботи на рівні корпоративного портфоліо, потоку створення цінностей, програми та команди.

Навіщо використовувати SAFe Agile Framework

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

• Продуктивність зросла by 20 - 50%
• Якість збільшився більш ніж 50%
• Час виходу на ринок швидше ніж 30 -75%
• Підвищений залучення співробітників та задоволення від роботи.

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

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

Коли використовувати масштабовану гнучку структуру

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

Наскільки відрізняється від інших практик Agile

Тепер у цьому підручнику Scaled Agile Framework давайте подивимося, чим Scaled Agile Framework відрізняється від інших гнучких практик,

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

FoundationScaled Agile Framework

Масштабована гнучка структура (SAFe): вона стоїть на основі свого

1. Принципи Lean-Agile
2. Основні цінності,
3. Lean-Agile Лідерство
4. Lean-Agile Mind set,
5. Спільноти практиків (група людей, які постійно працюють над практиками SAFe)
6. Реалізація 1-2-3

Принципи SAFe Lean-Agile

Ці основні принципи та цінності SAFe Agile для SAFe необхідно розуміти, демонструвати та продовжувати, щоб отримати бажані результати.

• Прийміть економічний погляд
• Застосовуйте системне мислення
• Припустити мінливість; зберегти параметри
• Створюйте поступово за допомогою швидких інтегрованих циклів навчання
• Віхи базуються на об’єктивній оцінці працюючих систем
• Візуалізуйте та обмежуйте WIP, зменшуйте розміри пакетів і керуйте довжиною черги
• Застосуйте каденцію, синхронізуйте міждоменне планування
• Розкрийте внутрішню мотивацію інтелектуальних працівників
• Децентралізація прийняття рішень

Основні цінності SAFe Agile

Методологія SAFe Agile базується на цих чотирьох значеннях.

Вирівнювання:

• SAFe підтримує вирівнювання.
• Вирівнювання починається з,
  • Стратегічні теми в Backlog Portfolio і
  • Переходить униз до бачення та дорожньої карти невиконаних програм, а потім
  • Переходить до командних резервів.

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

• Це гарантує, що кожна поетапна поставка відображає стандарти якості.
• Якість не «додається пізніше», вбудована.
• Вбудована якість є обов’язковою умовою Lean

Прозорість:

• Прозорість є запорукою довіри.
• SAFe допомагає підприємству досягти прозорості на всіх рівнях – керівників, портфельних менеджерів та інших зацікавлених сторін.
• Кожен може ознайомитися з портфельними резервами/Kanban, програмними резервами/Kanban і Team Backlog/Kanban.
• Кожен рівень має чітке розуміння цілей PI.
• Програми навчання мають доступ до невиконаних завдань команди, а також інших невиконаних програм
• Команди та програми бачать бізнес і архітектуру Epics. Вони можуть бачити, що може бути на їхньому шляху.

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

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

Lean Agile Лідери

Лідери Lean-Agile навчаються та вчать усе життя. Це допомагає командам створювати кращі системи через розуміння та демонстрацію принципів Lean-Agile SAFe.

Основною відповідальністю для команд є впровадження, успіх і постійне вдосконалення розробок Lean-Agile. Для змін і постійного вдосконалення лідери повинні бути навчені.

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

Принципи цих Lean-Agile лідерів

• Очолюйте зміни
• Знати шлях; Підкресліть навчання впродовж життя
• Розвивайте людей
• Надихайте та виконуйте місію; Мінімізуйте обмеження
• Децентралізація процесу прийняття рішень
• Розкрийте внутрішню мотивацію працівників інформаційних технологій

Lean Agile Mind Set

Настрій Lean-Agile представлений двома речами:

1. SAFe House of Lean
2. Проворний маніфест

SAFe House of Lean:

SAFe є похідним від принципів і практик економічного виробництва. На основі цих факторів SAFe представляє «SAFe House of Lean». Він натхненний «будинком» економної Toyota.

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

На малюнку нижче пояснюється ціль, основи та Foundation «SAFe House of Lean».

Проворний маніфест

Ми відкриваємо кращі способи розробки програмного забезпечення, роблячи це та допомагаючи іншим. Завдяки цій роботі ми оцінили:

Ось чому, незважаючи на наявність цінності в елементах праворуч, ми цінуємо елементи ліворуч більше.

Проворний маніфест

1. Найвищим пріоритетом є задоволення клієнта шляхом постійної та ранньої доставки цінного програмного забезпечення.
2. Приймайте мінливі вимоги, навіть на пізній стадії розробки. Методологія Agile SAFe обробляє зміну джгутів на користь клієнта.
3. Доставляйте робоче програмне забезпечення часто, від кількох тижнів до кількох місяців, віддаючи перевагу коротшим часовим рамкам.
4. Розробники та бізнесмени повинні щодня працювати разом протягом усього проекту.
5. Створюйте проекти навколо мотивованих людей. Надайте їм підтримку та середовище, яке їм потрібно, і довірте їм виконання роботи.
6. Найефективнішим способом спілкування з командою розробників є бесіда віч-на-віч.
7. Працююче програмне забезпечення є основним показником прогресу.
8. Гнучкі процеси сприяють сталому розвитку. Спонсори, розробники та користувачі повинні мати можливість підтримувати постійний темп нескінченно довго.
9. Постійна увага до технічної досконалості та гарного дизайну підвищує маневреність.
10. Простота – мистецтво максимізувати кількість невиконаної роботи – є важливою.
11. Найкращі архітектури, вимоги та проекти виходять із самоорганізованих команд.
12. Через регулярні проміжки часу команда розмірковує над тим, як стати більш ефективною, а потім відповідно налаштовує та коригує свою поведінку.

Різні рівні в SAFE

Існує два різних типи реалізації SAFe:

1. Реалізація SAFe 4.0
2. Реалізація SAFe 3.0

• У реалізації SAFe 4.0 ми маємо 4 рівні: Портфоліо, потік створення цінностей, програма та команда.
• У реалізації SAFe 3.0 ми маємо 3 рівні: Портфоліо, програма та команда
• 3-рівневий SAFe призначений для невеликих реалізацій із 100 або менше людей. Програми, які не потребують значної співпраці.
• 4-Level SAFe призначений для рішень, які зазвичай вимагають багато сотень практиків для розробки, розгортання та обслуговування програмного забезпечення.

Командний рівень

Ролі/Команди		Події		Артефакти
* Гнучка команда		* Sprint Планування		* Відставання команди
* Власник продукту		* Відставання від догляду		* Нефункціональні вимоги
* Scrum Master		* Щоденне стояння		* Цілі команди PI
		* Виконання		* Ітерації
		* Sprint Демонстрація		* Історії (робоче програмне забезпечення)
		* Sprint Ретроспектива		* Sprint Цілі
		* IP Sprints		* Вбудована якість
				* Шипи
				* Команда Канбан

• Усі команди SAFe є частиною того чи іншого Agile Release Train (ART).
• Команди SAFe — це наділені повноваженнями, самоорганізовані, самокеровані міжфункціональні команди
• Кожна команда несе однакову відповідальність за визначення, створення та тестування історій зі свого командного беклогу в ітераціях фіксованої довжини
• Команди планують і виконують двотижневі ітерації з обмеженим часом відповідно до узгоджених цілей ітерації.
• Команди використовуватимуть процедуру ScrumXP/Team Kanban, щоб надавати високоякісні системи для створення демонстрації системи кожні два тижні.
• Усі різні команди в ART (Agile Release Trains) створять інтегровану та перевірену систему. Зацікавлені сторони оцінять і швидко дадуть відповідь
• Вони застосовують вбудовані практики якості.
• Кожна команда ScrumXP матиме 5-9 членів команди, які включають усі ролі, необхідні для створення якісної додаткової цінності в кожній ітерації.
• Ролі ScrumXP включають:
  • Команда (розробник+QA)
  • Scrum Master
  • Власник продукту. тощо.
• SAFe ділить часову шкалу розробки на набір ітерацій у межах PI (Program Increment).
• Тривалість ПІ становить 8-12 тижнів.
• Команда використовуватиме історії, щоб донести цінність. Власник продукту матиме повноваження щодо створення та прийняття історій.
• Історії містять вимоги Замовника.
• Team Backlog містить історії користувачів і активаторів, які визначаються під час планування PI. Коли Керівництво продукту представляє дорожню карту, бачення та резервну програму.
• Виявлення, розробка, визначення пріоритетів, планування, впровадження, тестування та прийняття історій є основними вимогами управлінської роботи на рівні команди.
• Кожна ітерація забезпечує:
  • Цінний приріст нової функціональності
  • Виконуйте за шаблоном, що постійно повторюється
  • Сплануйте ітерацію
  • Зробіть певну функціональність
  • Виконайте ітерацію, створюючи та тестуючи історії
  • Демо нову функціональність
  • Ретроспектива
  • Повторіть для наступної ітерації
• Команди також підтримують демонстрацію системи в кінці кожної ітерації. що є критичною точкою інтеграції для АРТ.
• Більші потоки цінностей матимуть кілька ART.
• Ітерації інновацій та планування (IP) дають командам можливість для інновацій та досліджень.

Рівень програми

Ролі/Команди		Події		Артефакти
* DevOps		* Планування PI (Program Increment).		* Бачення
* Команда системи		* Демонстраційні версії системи		* Дорожня карта
* Управління випусками		* Перевірити та прийняти майстерню		* Метрики
* Менеджмент продукту		* Archiзлітно-посадкова смуга		* Віхи
* UEX ArchiTECT		* Випуск будь-коли		* Релізи
* Випуск інженера поїзда (RTE)		* Agile Release Train		* Програма Epics
* Система Architect/Інженер		* Звільнення		* Програма Канбан
* Власники бізнесу				* Відставання програми
* Lean-Agile Лідери				* Нефункціональні вимоги
* Практичні спільноти				* Зважена найкоротша робота спочатку (WSJF)
* Спільні служби				* Цілі PI програми
* Замовник				* Особливість
				* Активатор
				* Рішення
				* Координація потоку цінностей

• На рівні програми цінність SAFe забезпечується довгостроковими гнучкими релізами (ART). Ітерація призначена для команди, а навчання – для програми.
• Agile Release Trains (ART) є основним засобом надання цінності на рівні програми. Це забезпечує потік цінностей для організації.
• Тривалість збільшення програми (PI) становить від 8 до 12 тижнів.
• ART складається з 5–12 гнучких команд (~50–125+ людей), які включають усі ролі та інфраструктуру, необхідну для надання повністю перевіреного робочого програмного забезпечення системного рівня.
• Кожен PI — це вікно часу з кількома ітераціями. Під час якого розробляється та постачається значне, цінне розширення системи.
• У кожному PI відбудеться «демонстрація» та «Перевірка та адаптація», і починається планування для наступного PSI.
• На рівні програми SAFe акцентує увагу на принципі узгодження. Це пов’язано з тим, що для створення цінності для клієнтів об’єднано зусилля кількох гнучких команд.
• Ієрархія артефактів SAFe є Епоси->функції->історії користувачів.
• На рівні програми менеджер продукту/менеджер програми має повноваження щодо вмісту. Він визначає та розставляє пріоритети програмного відставання.
• Відставання програми – це пріоритетний список функцій.
• На рівні програми функції можуть виникати або випливати з епох, визначених на рівні портфоліо.
• Функції розкладаються на історії користувачів і перетікають у резерви командного рівня.
• Роль менеджера продукту або інженера з підготовки випусків може виконувати менеджер програми/старший менеджер проекту
• SYSTEM ArchiТектова роль на рівні програми полягає у повсякденній співпраці з командами. Він забезпечує виконання нефункціональних вимог. Крім того, вони співпрацюють з архітектором підприємства на рівні портфоліо, щоб переконатися, що є достатня архітектурна смуга для підтримки майбутніх потреб користувачів і бізнесу.
• Дизайн інтерфейсу, інструкції щодо взаємодії з користувачем та елементи дизайну для команд надають UX Designers.
• Роль Chief-Scrum Master виконує «Release Train Engineer».
• Різні групи (від маркетингу, розробки, якості, операцій і розгортання) формують «Команду управління випусками». Вони схвалюватимуть регулярні випуски якісних рішень для клієнтів.
• Команда DevOps піклується про розгортання програмного забезпечення в клієнтських середовищах та успішну доставку.

Рівень портфоліо

Ролі/Команди		Події		Артефакти
* Enterprise Architect		* Стратегічне інвестиційне планування		* Стратегічні теми
* Управління портфоліо програми		* Канбан портфоліо (епічне) планування		* Підприємство
* Епічні власники				* Відставання портфоліо
				* Канбан портфоліо
				* Нефункціональні вимоги
				* Epic і Enabler
				* Потік цінностей
				* Бюджети (CapEx і OpEx)

• Найвищий рівень інтересу/занепокоєння/залучення/ до SAFe Портфоліо SAFe
• Портфоліо містить основні блоки для організації потоку цінностей Lean-Agile Enterprise через один або більше потоків створення цінностей.
• Портфоліо допомагає розробляти системи та рішення, описані в стратегічних темах (пов’язує портфоліо SAFe із мінливою бізнес-стратегією підприємства).
• Щоб досягти стратегічних цілей, рівень портфеля інкапсулює ці елементи. Він забезпечує основні механізми бюджетування та інші механізми управління. Таким чином, це гарантує, що інвестиції в потоки створення вартості забезпечують віддачу, необхідну для підприємства.
• Портфоліо пов’язане з бізнесом у двох напрямках:
  • Для того, щоб скеровувати портфоліо до більш масштабних мінливих бізнес-цілей, воно містить стратегічні теми.
  • Інший напрямок вказує на постійний потік цінностей портфеля.
• Керівництво програмним портфоліо діє як зацікавлена ​​сторона, яка відповідає за досягнення бізнес-результатів.
• Рівень портфоліо SAFe містить людей, процеси та необхідні системи побудови та рішення, необхідні підприємству для досягнення своїх стратегічних цілей.
• Потоки створення цінностей є основними цілями в Портфоліо, за допомогою яких фінансується персонал та інші ресурси, необхідні для створення Рішень.
• Тут використовуються такі важливі ключові концепції:
  • Підключення до підприємства,
  • Управління портфелем програм,
  • Керування потоком портфоліо Epics.

Рівень потоку цінностей

Ролі/Команди		Події		Артефакти
* DevOps		* До і після планування PI (програмне збільшення).		* Бачення
* Команда системи		* Демонстраційні версії рішень		* Дорожня карта
* Управління випусками		* Перевірити та прийняти майстерню		* Метрики
* Управління рішеннями		* Agile Release Train		* Віхи
* UEX ArchiTECT				* Релізи
* Інженер потоку цінностей (RTE)				*Епопеї потоку цінностей
* Рішення Architect/Інженер				* Канбан потоку цінностей
* Спільні служби				* Відставання потоку створення цінностей
* Замовник				* Нефункціональні вимоги
* Постачальник				* Зважена найкоротша робота спочатку (WSJF)
				* Цілі PI Value Stream
				* Можливість
				* Активатор
				* Контекст рішення
				* Координація потоку цінностей
				* Економічна основа
				* Намір рішення
				* MBSE
				* На основі набору
				* Спритність Archiтектура

• Рівень потоку цінностей є необов’язковим у SAFe.
• Рівень потоку цінностей є новим у SAFe 4.0.
• Рівень потоку цінностей призначений/розроблений для підприємств/будівельників/організацій, які:

1. Великі за розміром
2. Незалежний
3. Мати комплексні рішення
4. Їх рішення зазвичай вимагають кількох ART
5. Вони мають внесок постачальників.
6. Вони стикаються з найбільшими системними проблемами
7. Для кіберфізичних систем
8. Для програмного забезпечення, апаратного забезпечення, електрики та електроніки, оптики, механіки, рідинної техніки тощо.

• Створення такого роду систем часто потребує сотні, навіть тисячі практиків, зовнішніх і внутрішніх постачальників.
• Якщо системи мають вирішальне значення. Відмова Рішення або навіть підсистеми має неприйнятні економічні та соціальні наслідки.
• Якщо Підприємства можна побудувати кількома сотнями практиків, їм можуть не знадобитися конструкції такого рівня. У цьому випадку вони можуть використовувати з 'згорнутий вигляд' який є 3-рівневим SAFe.
• Створення рішень потоку створення цінності за шаблоном Lean-Agile вимагає додаткових артефактів, координації та конструкцій. Таким чином, цей рівень містить економічну структуру, щоб забезпечити фінансові межі для потоку створення цінності
• Він підтримує каденцію та синхронізацію для кількох ART та постачальників. Він включає зустрічі з планування до та після PI та демонстрацію рішення.
• Він надає додаткові ролі, а саме: інженер потоку цінностей, рішення Architect/Engineering і Solution Management.

Підсумки

• SAFe — це перевірений галуззю метод масштабування Agile на корпоративному рівні, орієнтований на вартість.
• Він відповідає на такі запитання, як «Як ми плануємо?», «Як ми складаємо бюджет?» і «Як нам стати міжфункціональними в архітектурі та DevOps?"
• Структура SAFe Agile допомагає великим організаційним командам досягати стратегічних цілей організації, а не лише цілей окремих проектів.
• Фреймворк пропонує можливість підтримувати та створювати централізовану стратегію для досягнення цінності.
• Модель SAFe має три/чотири рівні, які централізують стратегічні теми організації.
• Централізована стратегія в поєднанні з децентралізованою гнучкою розробкою.

Список використаної літератури:

SAFe for Lean Enterprises 5.0:

http://www.scaledagileframework.com