Що таке Scaled Agile Framework (SAFe)?
Scaled Agile Framework (SAFe) - це вільно доступна база знань в Інтернеті, яка дозволяє застосовувати щадні гнучкі практики на рівні підприємств. Це забезпечує простий і легкий досвід для розробки програмного забезпечення. Це набір організацій та схем робочого циклу, призначених для керівництва підприємствами щодо масштабування ощадливих та спритних практик. Він розділений на три сегменти - це команда, програма та портфоліо.
Рамка SAFe дозволяє команді,
- Впровадження програмного забезпечення та систем Lean-Agile на рівні підприємств
- Він базується на принципах ощадливості та спритності.
- У ньому даються детальні вказівки щодо роботи в корпоративному портфоліо, ціннісному потоці, програмі та команді.
- Він розроблений для задоволення потреб усіх зацікавлених сторін в організації.
SAFe був вперше розроблений у цій галузі і був детально розроблений у книгах та блогах Діна Леффінгвелла . Версія 1.0 є першим офіційним випуском у 2011 році. Остання версія - 4.6, випущена в жовтні 2018 року. Вона надає вказівки щодо роботи на рівні корпоративного портфоліо, потоку вартості, програми та команди.
У цьому підручнику з SAFe Agile ви дізнаєтесь-
- Що таке Scaled Agile Framework (SAFe)
- Навіщо використовувати Agile Framework
- Коли використовувати масштабований Agile Framework
- Як відрізняються від інших Agile практики
- Основи Scaled Agile Framework
- Спритний маніфест
- Різні рівні в безпеці
- Командний рівень
- Рівень програми
- Рівень портфоліо
- Рівень потоку цінностей
Навіщо використовувати Agile Framework
Це простий і легкий фреймворк, проте він здатний задовольнити потреби великих потоків цінності та складної розробки системи. Впроваджуючи гнучку структуру SAFe, ви отримаєте такі переваги:
- Продуктивність зросла на 20 - 50%
- Якість зросла більш ніж на 50%
- Час виходу на ринок перевищує 30 -75%
- Збільшення залучення працівників та задоволення від роботи.
Детальна структурна схема доступна на веб-сайті. Він показує всі ключові ролі, діяльність, результати та потоки. Він також служить навігаційною допомогою для решти ділянок.
Наведене нижче зображення пояснює, як працює гнучкий процес. Епос - це великий обсяг творів, який далі розбивається на низку менших історій або суб-епосів. Ці суб-епоси виділяються команді як історія. Потім кожна команда опрацьовує ці історії чи особливості програмного забезпечення відповідно.
Коли використовувати масштабований Agile Framework
- Коли команда зацікавлена в послідовному впровадженні гнучкого підходу у великих програмах та портфелях, що складаються з декількох команд.
- Коли кілька команд ведуть свій власний шлях Agile, але регулярно стикаються з перешкодами, затримками та невдачами.
- Коли команди хочуть працювати самостійно.
- Коли ви хочете масштабувати Agile по всій організації, але не впевнені, які нові ролі можуть знадобитися або які існуючі ролі (тобто керівництво) потрібно змінити і як.
- Коли ви намагаєтесь масштабувати Agile у вашій організації, але намагаєтесь досягти єдиної або послідовної стратегії між бізнес-підрозділами від портфеля до рівня програм та команд.
- Коли організація повинна покращити час розробки своїх продуктів і хоче знати, як іншим компаніям вдалося масштабувати Agile за допомогою SAFe.
Як відрізняються від інших Agile практики
Тепер у цьому підручнику Scaled Agile Framework давайте подивимось, чим Scaled Agile framework відрізняється від інших гнучких практик,
- Він є загальнодоступним та безкоштовним у користуванні.
- Доступний у дуже доступній та зручній формі.
- Це легкий, практично доведений результат та специфічний для рівня.
- Він постійно / регулярно модифікує / підтримує найбільш часто використовувані спритні практики.
- Пропонує корисні розширення загальних спритних практик.
- Обґрунтовує гнучкі практики в контексті підприємства.
- Пропонує повне уявлення про розробку програмного забезпечення.
- Видимість чи прозорість більша на всіх рівнях.
- Постійний або регулярний відгук про якість та вдосконалення.
Основи Scaled Agile Framework
Scaled Agile Framework (SAFe): Він стоїть на своїх основах
- Принципи стрункої спритності
- Основні цінності,
- Худеньке рухливе керівництво
- Худий і рухливий розум,
- Практичні спільноти (Група людей, які постійно працюють над практиками SAFe)
- Реалізація 1-2-3
БЕЗПЕЧНІ Принципи чіткої та рухливої діяльності
Ці основні принципи та цінності SAFe Agile повинні бути зрозумілі, виставлені та продовжені, щоб отримати бажані результати.
- Дотримуйтесь економічної точки зору
- Застосовуйте системне мислення
- Припустимо мінливість; зберегти варіанти
- Поступово будуйте за допомогою швидких, інтегрованих циклів навчання
- Основу етапів об’єктивної оцінки робочих систем
- Візуалізуйте та обмежте WIP, зменште розмір партії та керуйте довжиною черги
- Застосовуйте каденцію, синхронізуйте з міждоменним плануванням
- Розкрийте внутрішню мотивацію працівників знань
- Децентралізуйте процес прийняття рішень
Основні цінності SAFe Agile
Методологія SAFe Agile базується на цих чотирьох значеннях.
Вирівнювання:
- SAFe підтримує вирівнювання.
- Вирівнювання починається з,
- Стратегічні теми у відставанні портфоліо та
- Переходить до бачення та дорожньої карти відставань програм, а потім
- Переходить до відставання команд.
Вбудована якість:
- Це гарантує, що кожна додаткова доставка відображає стандарти якості.
- Якість не "додається пізніше".
- Вбудована якість - це обов’язкова умова Lean та його обов’язкова умова
Прозорість:
- Прозорість сприяє довірі.
- SAFe допомагає підприємству досягти прозорості на всіх рівнях - керівники, менеджери портфелів та інші зацікавлені сторони.
- Кожен може бачити відставання портфоліо / Kanban, відставання програм / Kanban та відставання команд / Kanban.
- Кожен рівень чітко розуміє цілі ПІ.
- Програми поїздів мають видимість відставань команди, а також інших програм
- Команди та програми мають доступ до бізнесу та архітектури Epics. Вони можуть бачити, що може рухатися їхнім шляхом.
Виконання програми:
- SAFe приділяє велику увагу робочим системам та результатам бізнесу.
- SAFe не корисний, якщо команди не можуть виконувати та постійно доставляти цінність.
Худенькі спритні лідери:
Спритні та спритні лідери - це люди, які навчаються впродовж усього життя та викладачі. Це допомагає командам будувати кращі системи завдяки розумінню та викладенню принципів безпечної безпечності.
Як стимул для команд, головна відповідальність - це прийняття, успіх та постійне вдосконалення розробок Lean-Agile. Для змін та постійного вдосконалення керівники повинні бути навчені.
Керівникам потрібно прийняти новий стиль керівництва. Той, який справді розширює можливості та залучає людей та команди для досягнення свого найвищого потенціалу.
Принципи цих Спритних-Спритних Лідерів
- Очоліть зміни
- Знай шлях; Наголосіть на навчанні протягом усього життя
- Розвивайте людей
- Надихати та узгоджувати місію; Мінімізуйте обмеження
- Децентралізуйте процес прийняття рішень
- Розкрийте внутрішню мотивацію працівників знань
Худий спритний розум:
Мисле спритне мислення представлене у двох речах:
- SAFe Будинок Пісного
- Спритний маніфест
SAFe Будинок Пісного :
SAFe походить від принципів та практики ощадливого виробництва. Виходячи з цих факторів, SAFe представляє "SAFe Lean House". Він натхненний "будинком" худорлявої Toyota.
Ціль бережливості є неперевершеною: забезпечити максимальну цінність клієнта в найкоротші терміни з максимально можливою якістю для клієнта
Нижче на рисунку пояснюється ціль, основи та фундація "SAFe Lean House".
Спритний маніфест
Ми розкриваємо кращі способи розробки програмного забезпечення, роблячи це та допомагаючи іншим робити це. Завдяки цій роботі ми прийшли до оцінки:
Ось чому, хоча в елементах справа є значення, ми більше цінуємо елементи ліворуч.
Спритний маніфест
- Найвищим пріоритетом є задоволення клієнта шляхом постійної та ранньої доставки цінного програмного забезпечення.
- Прийміть мінливі вимоги, навіть пізно у розробці. Agile SAFe методологія обробляє зміни змін на користь замовника.
- Поставляйте робоче програмне забезпечення часто, від декількох тижнів до кількох місяців, з перевагою щодо коротшого часу.
- Розробники та ділові люди повинні щодня працювати разом протягом усього проекту.
- Будуйте проекти навколо мотивованих людей. Надайте їм підтримку та необхідне середовище та довіртесь їм зробити роботу.
- Найефективнішим методом спілкування з командою розробників є очна розмова.
- Працююче програмне забезпечення є головним показником прогресу.
- Спритні процеси сприяють сталому розвитку. Спонсори, розробники та користувачі повинні мати можливість постійно підтримувати постійний темп.
- Постійна увага до технічної досконалості та гарного дизайну підвищує спритність.
- Простота - мистецтво максимізувати обсяг незавершеної роботи - має важливе значення.
- Найкращі архітектури, вимоги та конструкції виникають у команд, що самоорганізовуються.
- Через рівні проміжки часу команда розмірковує над тим, як стати ефективнішим, а потім налаштовує та регулює свою поведінку відповідно.
Різні рівні в безпеці
Існує два різні типи реалізації SAFe:
- Впровадження SAFe 4.0
- Впровадження SAFe 3.0
- У реалізації SAFe 4.0 ми маємо 4 рівні: портфоліо, ціннісний потік, програма та команда.
- У реалізації SAFe 3.0 ми маємо 3 рівні: портфоліо, програма та команда
- 3-рівневий SAFe призначений для невеликих реалізацій із 100 або менше людей. Програми, які не потребують значної співпраці.
- 4-рівневий SAFe призначений для рішень, які, як правило, вимагають багатьох сотень практиків для розробки розгортання та обслуговування програмного забезпечення.
Командний рівень
| Ролі / Команди | Події | Артефакти | ||
|---|---|---|---|---|
| * Agile Team | * Планування спринту | * Відставання команд | ||
| * Власник продукту | * Догляд за відставанням | * Нефункціональні вимоги | ||
| * Scrum Master | * Щоденна стійка | * Цілі команди PI | ||
| * Виконання | * Ітерації | |||
| * Демонстрація спринту | * Історії (робоче програмне забезпечення) | |||
| * Ретроспектива спринту | * Цілі спринту | |||
| * Спринти IP | * Вбудована якість | |||
| * Шипи | ||||
| * Команда Kanban |
- Усі команди SAFe є частиною того чи іншого потягу швидкого випуску (ART).
- Команди SAFe - це уповноважені, самоорганізуючі, самокеровані, міжфункціональні команди
- Кожна команда однаково відповідальна за визначення, створення та тестування історій зі свого відставання команд у ітераціях фіксованої довжини
- Команди планують та виконують двотижневі ітерації, виконані за часом, відповідно до узгоджених цілей ітерації.
- Команди використовуватимуть програму ScrumXP / Team Kanban для доставки високоякісних систем для створення демонстрації системи кожні два тижні.
- Усі різні команди в ART (Agile Release Trains) створять інтегровану і перевірену систему. Зацікавлені сторони оцінять і дадуть швидкий відгук
- Вони застосовують вбудовану практику якості.
- Кожна команда ScrumXP матиме 5-9 членів команди, що включає всі ролі, необхідні для побудови якісного додаткового значення в кожній ітерації.
- Ролі ScrumXP включають:
- Команда (Dev + QA)
- Scrum Master
- Власник продукту. І т.д.
- SAFe розподіляє часову шкалу розробки на набір ітерацій у межах PI (збільшення програми).
- Тривалість ІП становить від 8 -12 тижнів.
- Команда використовуватиме історії, щоб донести цінність. Власник продукту матиме повноваження щодо вмісту над їх створенням та прийняттям матеріалів.
- Історії містять вимоги замовника.
- Відставання команди включає історії користувачів та активістів, які визначаються під час планування PI. Коли Управління продуктами представляє дорожню карту, бачення та відставання програм.
- Визначення, розробка, встановлення пріоритетів, планування, впровадження, тестування та прийняття матеріалів є основними вимогами управлінської роботи на рівні команди.
- Кожна ітерація забезпечує:
- Цінне збільшення нової функціональності
- Досягти за допомогою постійно повторюваного шаблону
- Сплануйте ітерацію
- Дотримуйтесь певних функціональних можливостей
- Виконайте ітерацію шляхом створення та тестування Stories
- Демонструйте нову функціональність
- Ретроспектива
- Повторіть для наступної ітерації
- Команди також підтримують демонстрацію системи в кінці кожної ітерації. що є критичною точкою інтеграції для АРТ.
- Потоки більшої вартості матимуть кілька ART.
- Іновації інновацій та планування (ІП) використовують команди, що мають можливість для інновацій та досліджень.
Рівень програми
| Ролі / Команди | Події | Артефакти | ||
|---|---|---|---|---|
| * DevOps | * Планування PI (збільшення програми) | * Бачення | ||
| * Системна команда | * Демонстрація системи | * Дорожня карта | ||
| * Управління випусками | * Перевірка та прийняття майстерні | * Метрики | ||
| * Менеджмент продукту | * Архітектурна злітно-посадкова смуга | * Віхи | ||
| * Архітектор UEX | * Відпустіть у будь-який час | * Випуски | ||
| * Випуск інженера поїзда (RTE) | * Швидкий випускний поїзд | * Програма Epics | ||
| * Архітектор системи / Інженер | * Випуск | * Програма Kanban | ||
| * Власники бізнесу | * Відставання програми | |||
| * Худенькі спритні лідери | * Нефункціональні вимоги | |||
| * Практичні спільноти | * Спершу зважена найкоротша робота (WSJF) | |||
| * Спільні послуги | * Цілі програми PI | |||
| * Клієнт | * Особливість | |||
| * Вмикач | ||||
| * Рішення | ||||
| * Координація потоку цінностей |
- На рівні Програми, значення SAFe забезпечується довготривалими гнучкими поїздами випуску (ART). Ітерація призначена для команди, а тренування - для програми.
- Agile Release Trains (ART) є основним засобом доставки вартості на рівні програми. Це забезпечує потік вартості для організації.
- Тривалість збільшення програм (ПІ) становить від 8 до 12 тижнів.
- ART складається з 5-12 команд Agile (~ 50 - 125+ осіб), що включає всі ролі та інфраструктуру, необхідні для забезпечення повністю перевіреного, працюючого програмного забезпечення на системному рівні.
- Кожен PI - це часовий блок із декількома ітераціями. Протягом якого розробляється і доставляється значний, цінний приріст системи.
- У кожному PI відбуватимуться сеанси "демонстрації" та "Перевірка та адаптація", і планування почнеться для наступного PSI.
- На рівні програми SAFe наголошує на принципі узгодження. Це пов’язано з тим, що для створення цінності для споживачів інтегровано багато зусиль команди
- Ієрархія артефактів SAFe - це Epics-> особливості-> історії користувачів .
- На рівні програми менеджер продуктів / менеджер програми має повноваження щодо вмісту. Він визначає та визначає пріоритети відставання програм.
- Відставання програми - це пріоритетний перелік функцій.
- На рівні програми функції можуть бути створені або вони можуть походити від епосів, визначених на рівні портфоліо.
- Функції розкладаються на історії користувачів і перетікають у відставання на рівні команди.
- Роль менеджера по продуктам або випускника навчального інженера може виконувати менеджер програми / старший менеджер проекту
- Роль архітектора системи на рівні програми полягає у співпраці щоденної роботи з командами. Це гарантує, що виконуються нефункціональні вимоги. Крім того, вони працюють з архітектором підприємства на рівні портфоліо, щоб переконатися, що є достатня архітектурна злітно-посадкова смуга для забезпечення майбутніх потреб користувачів та бізнесу.
- Дизайн інтерфейсу, рекомендації щодо користувацького досвіду та елементи дизайну для команд надають UX Designers.
- Роль начальника Scrum Master виконує "Інженер звільнення поїзда".
- Різна команда (від маркетингу, розробки, якості, операцій та розгортання) формує "Команда управління випуском". Вони затвердять звичайні випуски якісних рішень для клієнтів.
- Впровадження програмного забезпечення в середовище клієнтів та успішна доставка забезпечується командою DevOps.
Рівень портфоліо
| Ролі / Команди | Події | Артефакти | ||
|---|---|---|---|---|
| * Архітектор підприємства | * Стратегічне планування інвестицій | * Стратегічні теми | ||
| * Портфоліо програми Mgmt | * Kanban Portfolio (Epic) Planning | * Підприємство | ||
| * Епічні власники | * Відставання портфеля | |||
| * Портфоліо Kanban | ||||
| * Нефункціональні вимоги | ||||
| * Epic і Enabler | ||||
| * Значення потоку | ||||
| * Бюджети (CapEx та OpEx) |
- Найвищий рівень зацікавленості / занепокоєння / залучення / до SAFe - це портфоліо SAFe
- Портфоліо надає основні блоки для організації потоку вартості Lean-Agile Enterprise через один або кілька потоків вартості.
- Портфоліо допомагає розробляти системи та рішення, які описуються у стратегічних темах (пов’язує портфель SAFe зі змінною бізнес-стратегією підприємства).
- Для досягнення стратегічних цілей рівень портфеля містить ці елементи. Він забезпечує базове бюджетування та інші механізми управління. Таким чином він гарантує, що інвестиції в потоки вартості забезпечують прибуток, необхідний підприємству.
- Портфоліо пов’язане з бізнесом у двох напрямках:
- Для того, щоб скерувати портфоліо до більш масштабних цілей бізнесу, що змінюються, він пропонує стратегічні теми.
- Інший напрямок вказує на постійний потік цінностей портфеля.
- Управління портфелем програм виступає в ролі зацікавлених сторін, і вони несуть відповідальність за досягнення результатів бізнесу.
- Рівень портфоліо SAFe містить людей, процеси та необхідні системи побудови та рішення, необхідні підприємству для досягнення своїх стратегічних цілей.
- Ціннісні потоки є головними цілями Портфоліо, за допомогою яких фінансуються люди та інші ресурси, необхідні для побудови Рішень.
- Важливі ключові поняття, що використовуються тут:
- Підключення до Підприємства,
- Управління портфелем програм,
- Управління потоком портфельних епічних творів.
Рівень потоку цінностей
| Ролі / Команди | Події | Артефакти | ||
|---|---|---|---|---|
| * DevOps | * Планування до та після PI (збільшення програм) | * Бачення | ||
| * Системна команда | * Демо-версії рішення | * Дорожня карта | ||
| * Управління випусками | * Перевірка та прийняття майстерні | * Метрики | ||
| * Управління рішеннями | * Швидкий випускний поїзд | * Віхи | ||
| * Архітектор UEX | * Випуски | |||
| * Value Stream Engineer (RTE) | * Value Stream Epics | |||
| * Архітектор рішень / інженер | * Value Stream Kanban | |||
| * Спільні послуги | * Значення відставання потоку | |||
| * Клієнт | * Нефункціональні вимоги | |||
| * Постачальник | * Спершу зважена найкоротша робота (WSJF) | |||
| * Цілі PI Value Stream | ||||
| * Можливість | ||||
| * Вмикач | ||||
| * Контекст рішення | ||||
| * Координація потоку цінностей | ||||
| * Економічні рамки | ||||
| * Намір рішення | ||||
| * MBSE | ||||
| * На основі набору | ||||
| * Спритна архітектура |
- Рівень значення потоку є необов’язковим у SAFe.
- Рівень потоку цінності є новим у SAFe 4.0.
- Рівень потоку вартості призначений / розроблений для підприємств / будівельників / організацій, які:
- Великі за розміром
- Незалежний
- Мають складні рішення
- Їх рішення, як правило, вимагають декількох АРТ
- Вони мають внесок постачальників.
- Вони стикаються з найбільшими системними проблемами
- Для кіберфізичних систем
- Для програмного, апаратного, електричного та електронічного, оптичного, механічного, текучого середовищ тощо.
- Для побудови такого роду систем часто потрібні сотні, навіть тисячі практиків, зовнішніх та внутрішніх постачальників.
- Якщо системи є ключовими для місії. Невдача Рішення або навіть підсистеми має неприйнятні економічні та соціальні наслідки.
- Якщо Підприємства можна створити з кількома сотнями практиків, йому можуть не знадобитися конструкції такого рівня. У цьому випадку вони можуть використовувати з " згорнутого вигляду", який є 3-рівневим SAFe.
- Побудова рішень потоку вартості за схемою Lean-Agile вимагає додаткових артефактів, координації та конструкцій. Отже, цей рівень містить Економічні рамки, що забезпечують фінансові межі для Потоку вартості
- Він підтримує каденцію та синхронізацію для багатьох ART та постачальників. Він включає зустрічі з планування до та після PI та демонстрацію рішення.
- Він надає додаткові ролі, які є: Value Stream Engineer, Solution Architect / Engineering та Solution Management.
Короткий зміст:
- SAFe - це перевірений у галузі, цілеспрямований метод масштабування Agile на рівні підприємства.
- Він відповідає на запитання на зразок "Як ми плануємо?", "Як ми фінансуємо бюджет?" Та "Як ми стаємо міжфункціональними в архітектурі та DevOps?"
- Система SAFe Agile допомагає великим організаційним командам досягти стратегічних цілей організації, а не лише окремих цілей проекту.
- Структура пропонує можливість підтримувати та створювати централізовану стратегію досягнення вартості.
- Модель SAFe має три / чотири рівні, які централізують стратегічні теми організації.
- Централізована стратегія в поєднанні з децентралізованим гнучким виконанням розробок.
Список літератури:
SAFe для ощадливих підприємств 5.0:
http://www.scaledagileframework.com
Цю статтю надав Джоті Рангарадж