Меню

Підручник з SAFe Agile: Що таке Scaled Agile Framework

safe agile tutorial what is scaled agile framework

Спробуйте Наш Інструмент Для Усунення Проблем

яке найкраще видалення вірусів -

Навчальний посібник із масштабованої Agile Framework SAFe:

В останньому підручнику ми познайомили вас з поняттям Три принципи аміго що виявилося дуже корисним для швидшого надання правильного рішення із сильними петлями зворотного зв'язку.

Якщо ви ще цього не пройшли, перегляньте підручник оскільки це потрібно прочитати всім, щоб потрапити в Швидкий Простір.

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

безпечний_ масштабований гнучкий фреймворк

Оскільки більша частина організації рухається до спритності, стало дуже важливим масштаб і підтримка конкурентних переваг. Ось тоді з’являється враження Scaled Agile Frameworks.

У цьому підручнику з SAFe ми будемо детально обговорювати Scaled Agile Framework. Ми також зробимо акцент на необхідності введення SAFe, як у розумінні загальної постановки проблеми, і нарешті ми побачимо, як привести SAFe в рух.

Почнемо з того, що котиться м'яч ...

SAFe означає Scaled Agile Frameworks. SAFe забезпечує компанія Scaled Agile. Він був створений в 2011 році, його творцем та співзасновником був Дін Леффінгвелл.

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

Що ви дізнаєтесь:

До SAFe

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

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

Що таке SAFe?

Scaled Agile Framework - це структура, яка забезпечує чотири різні рівні спритного усиновлення.

Найнижчий рівень називається РІВНИЧНИМ, коли кілька команд працюють на скруті, Канбані чи будь-якій іншій спритній методології, використовуючи основи програмування XP, забезпечуючи цінність на рівні команди.

Другий рівень, який просувається зверху вниз - це ПРОГРАМА, він стосується команд, які працюють разом під керівництвом команди управління програмою та забезпечують цінність у концепції Agile release train.

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

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

Сейф підтримує менш масштабні рішення, в яких працює 50–125 практиків, а також складні системи, які потребують тисяч людей.

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

Сейф

Чому масштабований Agile Framework?

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

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

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

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

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

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

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

Деякі загальні проблеми, з якими ми стикаємось при розробці програмного забезпечення у моделі водоспаду, проілюстровані на зображенні нижче:

проблеми у моделі водоспаду

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

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

Формування SAFe

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

Тепер розробіть концептуальне середовище, в якому ми маємо кілька команд, які працюють в однакових умовах для досягнення тієї самої мети. Нам пора рухатися вперед і подивитися, як працює Agile Scaled Framework, така як Scaled Scrum, у цьому просторі.

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

Епічний

  • Виходячи з пріоритетів, ці епопеї підбирають менеджери продуктів / менеджери з доставки. Вони створюють чітко визначену Дорожню карту та Документ про бачення. Вони виконують цю діяльність, обговорюючи план випуску з командою управління випусками, щоб узгодити дорожню карту із виробничими випусками.
  • Після створення Дорожньої карти та бачення наступним кроком Менеджера продуктів є створення відставання програмного відставання. Відставання програми складається з елементів випуску, функціональних бітів та пулу нефункціональних вимог (NFR).
  • Команда управління випусками готує план випуску з урахуванням функцій циклів випуску.
  • Команда управління випусками тепер працює над бітами функцій, щоб виконати План випуску та цілі. Вони також працюють над підготовкою архітектури та інфраструктури для забезпечення плавних випусків.
  • З відставання програм ми рухаємось до окремого відставання продукту, яке також відоме як відставання команд. Команда випусків / систем має власний відставання продуктів, аналогічно, у всіх команд Scrum, які працюють над проектом, буде свій індивідуальний відставання продуктів.
  • Відставання товарів складається як з функціональних, так і з нефункціональних історій. Ці історії мають пріоритет Власник продукту, який працює над цією командою Scrum.
  • Зазвичай існує 5-10 команд Scrum, які працюють у масштабованому гнучкому середовищі. Кожна команда Scrum має власника продукту, майстра Scrum та команду розробників. Ролі та обов'язки кожного з членів команди Scrum у Scaled Scrum такі ж, як у звичайному середовищі Scrum.
  • Команда Scrum виконує всі Церемонії Scrum і працює над розробкою Інкременту, який буде подаватися в кінці кожного спринту.

Поради та підказки

  • Для всіх команд Scrum дати початку та кінця спринту зберігаються однаково тривалістю. Отже, спринт для всіх команд Scrum синхронізований.
  • Оскільки всі Scrum-групи працюють над однією місією, залежності між ними повинні бути чітко визначені, заплановані та призначені, щоб мінімізувати порушення поставок продукції. Залежності між командами Scrum - одна з найпоширеніших проблем у Scaled Scrum Environment.
  • Очікується, що кожна команда Scrum надасть Інкремент в кінці кожного Спринту. Всі ці прирости в поєднанні утворюють потенційно доступний програмний приріст.
  • Під час роботи в Scaled Scrum слід ретельно робити переведення членів команди з однієї команди в іншу. Переміщення членів команди під час Спринту заборонено, і це правило не є винятком.
  • Загальний прогрес програми вимірюється шляхом інтеграції приростів, розроблених усіма командами Scrum.
  • Під час роботи в Scaled Scrum щодня або щотижня проводиться церемонія під назвою «Scrum of Scrum», де для участі запрошується представник (зазвичай Scrum Master) від кожної команди Scrum. Ця зустріч така ж, як і щоденного стендапу, і мета також залишається незмінною: «Підтримувати вирівнювання та синхронізацію між кількома командами».
  • Завжди зберігайте основні цінності Scaled Agile Framework (SAFe) незмінними на всіх рівнях.

Основні цінності: Вирівнювання, вбудована якість, вирівнювання та прозорість

Основна вартість

  • Спілкування та співпраця між Scrum Teams є запорукою успішного масштабованого Scrum з точки зору продуктивності, якості та часу виходу на ринок.

Кілька хитрощів, де-не-де в Scrum Framework можуть призвести до неймовірних результатів у вигляді Scaled Scrum.

Чому ми повинні використовувати цей фреймворк?

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

В основному, це працює на основі спритного розвитку, системного мислення та ощадливого розвитку.

Це допомагає у:

  • Узгодження ділових та технічних цілей компанії.
  • Прийняття рішень для покращення результатів.
  • Планування своєчасної доставки.
  • Підвищення якості рішень.
  • Масштабування гнучких процесів до рівня підприємства.
  • Ефективне використання навичок працівника.
  • Визначення ефективних організаційних структур
  • Вимірювання спритної командної діяльності
  • І запропонуйте способи мотивації людей до хорошої роботи та до вивчення нових речей та ризику.

Ось дані підприємств, які успішно це впровадили

дані підприємств, які успішно впровадили SAFe

Конфігурації SAFe

SAFe підтримує повний спектр середовищ розробки з чотирма конфігураціями,

Конфігурація SAFe

1. Основний SAFe

  • Основна конфігурація SAFe є суттю основи і є найпростішою відправною точкою для реалізації.
  • Це основний будівельний блок для всіх інших конфігурацій SAFe і описує найважливіші елементи, необхідні для реалізації більшості переваг Framework.
  • Рівні команд та програм утворюють організаційну структуру, яка називається Agile Release Train (ART), де Agile команди, ключові зацікавлені сторони та інші ресурси присвячуються важливої, постійній місії рішення.

2. Портфоліо SAFe

  • Конфігурація Portfolio SAFe допомагає узгодити виконання портфеля із стратегією підприємства.
  • Організовано навколо потоку вартості.
  • Lean-Agile складання бюджету дає можливість особам, які приймають рішення.
  • Система Kanban забезпечує видимість портфеля та обмеження WIP.
  • Архітектура підприємства керує більшими технологічними рішеннями.
  • Об'єктивні показники підтримують управління та вдосконалення.
  • Доставка вартості через Epics.

3. Велике рішення SAFe

  • Конфігурація SAFe Large Solution призначена для розробки найбільших і найскладніших рішень, які, як правило, потребують декількох випускних поїздів Agile та постачальників, але не вимагають міркувань на рівні портфеля.
  • Це характерно для таких галузей, як аерокосмічна, оборонна, автомобільна тощо.
  • Організаційна конструкція «Поїзд рішень» «Великий рівень рішень» допомагає підприємствам, які стикаються з найбільшими проблемами - створенням великого, мультидисциплінарного програмного, апаратного забезпечення та складних ІТ-систем.
  • Побудова цих рішень вимагає додаткових ролей, артефактів, подій та координації.

4. Повна безпека

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

Фонд

Фонд містить допоміжні принципи, цінності, мислення, керівні принципи впровадження та керівні ролі, необхідні для успішного досягнення вартості в масштабі.

1. Худенькі спритні лідери

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

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

SAFe Lean-Agile Leaders

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

2. Основні цінності

Чотири основні цінності визначають систему переконань щодо SAFe:

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

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

Прозорість

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

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

  • Поступово застосовуйте вбудовані методи якості для програмного, апаратного та мікропрограмного забезпечення. Зрозумійте, навчіть або спонсоруйте розвиток технічних навичок на підтримку високоякісного коду, компонентів, систем та рішень.
  • Фостерні спільноти практик.
  • Зрозумійте, підтримайте та застосовуйте Agile Architecture та Lean User Experience (UX).

3. Худий і рухливий спосіб мислення

Спритні та спритні лідери - це люди, які навчаються впродовж усього життя та викладачі. Вони розуміють і сприймають принципи та практики Lean та Agile.

Худий і спритний спосіб мислення

Наше мислення “Lean-Agile” представлене у двох речах:

(i) Будинок Пісного:

Будинок Пісного - це той, який ви бачите тут.

Він має ряд елементів:

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

У такій структурі ми схильні думати про парадигму пісності.

(ii) Спритний маніфест:

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

Спритний маніфест

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

4. Принципи БЕЗПЕКИ

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

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

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

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

Нарешті, обговоримо реалізацію. Ми опишемо це за допомогою нашої реалізації моделі SAFe 1-2-3.

Номер 1 - навчити агентів змін Lean-Agile. Ми називаємо цих консультантів програм SAFe. Маючи достатній штат агентів змін Lean-Agile на місці та працюючи з вашими партнерами, ви матимете можливість навчати керівників та керівників та менеджерів, які відповідають за управління людьми, які приносять цінність.

Тоді вони зможуть підтримати запуск Agile Release Train. І одним потягом за один раз ви створите портфоліо Agile.

6. Консультанти програми SAFe (SPC)

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

Висновок

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

Він доступний у різних конфігураціях, і компанії можуть ним скористатися

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

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

Також повідомте нам, якщо ви вважаєте, що ми могли забути будь-яку тему в Agile Series. Ми будемо раді пройти додаткову милю та розкрити для вас тему. Далі для вас цікава цікава вікторина з відповідями. Не забудьте спробувати !!

конвертувати декілька відео YouTube у mp3

НАЗАД Підручник | НАСТУПНИЙ підручник

Рекомендована література

^