Вікіпедія

Scaled agile framework

Немає перевірених версій цієї сторінки; ймовірно, її ще не перевіряли на відповідність правилам проекту.

Масштабована гнучка розробка (англ. scaled agile framework, абр. SAFe) — набір загальновизначених принципів, підходів, шаблонів робочого процесу який базується на методологіях гнучкої розробки (Agile). Основною ціллю використання подібних підходів є організація роботи в розробці програмного забезпечення де як правило, потрібно часто адаптовуватися до змін і актуалізувати кінцевий продукт. Схожі підходи використовується в інших сферах, таких як фінанси, банківська справа, страхування тощо, але меншою мірою. Разом з подібними методологіями такими як: великомасштабний скрам (Large-Scale Scrum), дисциплінована гнучке доставлення (Disciplined agile delivery), SAFe - спеціалізується на збільшенні організації за межами однієї команди і допомагає вирішити пов'язані з цим проблеми комунікації, взаємодії і досягнення запланованих результатів.

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

Загальна концепція масштабованої гнучкої розробки SAFe спочатку була сформований на рівні абстракції і визначення загальних правил взаємодії окремо взятої команди з Agile-середовищем - у вигляді команд розробників, організація роботи яких схожа. Ці загальновживані правила і формулювання викладені в книзі 2007 року.[1] Останнє оновлення версії 4.5 було опубліковано в червні 2017.[2]

Основні проблеми гнучкої розробки в великих організаціях

ред.

Відповідність до тривалого планування

ред.

Зазвичай команди розробників фокусуються на перелік запланованих завдань(англ. backlog) на 2 або 3 наступні цикли розробки, але в компаніях з великою кількістю команд і відповідно працівників, є потреба планувати виконання завдань на значно більший період, наприклад на 12-18 місяців.[3] Такі рішення приймаються в дискусіях з клієнтами для того, щоб реалізація продукту або його оновлення були актуальними на ринку.[4]

Дотримання принципів гнучкості на абстрактних рівнях відповідальності

ред.

Для окремо взятих команд, де підходи управління проєктами - Скрам, Канбан мають чіткий набір правил і принципів які визначають як саме розробники мають бути готові до адаптації, а для менеджменту організації є визначені тільки загальні вимоги. Як можливе вдосконалення або поєднання - SAFe має багато подібностей до визначень крос-функціональних команд, але одночасно дозволяє використовувати більш абстрактні форми планування. SAFe іноді критикують за дотримання занадто великої кількості практик, які іноді складно поєднувати в реальному плануванні проєкту.[5]

Особливості з делегованими повноваженнями

ред.

На прикладі Scrum, як одного з найпоширеніших типів використання методології гнучкої розробки передбачено, що власник продукту завжди бере на себе відповідальність за весь життєвий цикл продукту, включаючи дохід від інвестиційних рішень щодо розвитку, а також актуальність на ринку. У масштабних розробках, і збільшеній кількості залежностей компонентів розробки, продукт потребує перегляду кількох групових резервів і, наприклад може потребувати представлення менеджером продукту. І в такому вигляді роль власника продукту може приймати іншу форму наближену до менеджера, або розробника продукту.[6]

Синхронізація результатів

ред.

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

Виділення часу для інноваційних рішень і планування

ред.

Цикл планування SAFe рекомендує додаткову ітерацію після релізу, таким чином команди можуть удосконалити їх практики в роботі і підготуватися до наступного циклу розробки.[8] Існує також критика такого додаткової ітерації, як така що є "антигнучкою" і робить загальне розуміння SAFe як подібної до іншої форми організації робочого процесу такої як Водоспадна модель.

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

ред.

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

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

Сертифікати

ред.

Існують різні сертифікати які мають відповідні тренінги, які надають можливість зрозуміти загальні відомості і необхідний інструментарій для різних рівнів, що мають допогти практичному використані.[9]

  1. "SAFe Активіст" - SAFe Agilist (SA)
  2. "SAFe Практикант" - SAFe Practitioner (SP)
  3. "SAFe Консультант програми" - SAFe Program Consultant (SPC)
  4. "SAFe Менеджер продукту / Власник продукту" - SAFe Product Manager / Product Owner (SPMPO)
  5. "SAFe Тренер-консультант продукту" - SAFe Program Consultant Trainer (SPCT)
  6. "SAFe Скрам-майстер" - SAFe Scrum Master (SSM)
  7. "SAFe Поглиблений скрам-майстер" - SAFe Advanced Scrum Master (SASM)

Посилання

ред.
  1. ↑ Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley. ISBN 978-0321458193.
  2. ↑ Cleveland, Regina. Scaled Agile, Inc. Releases SAFe® 4.5. prweb.com. Архів оригіналу за 15 квітня 2018. Процитовано 11 вересня 2017.
  3. ↑ Eklund, U; Olsson, H; Strøm, N (2014). Industrial challenges of scaling agile in mass-produced embedded systems. Springer International Publishing. ISBN 9783319143583. {{cite book}}: Проігноровано |work= (довідка)
  4. ↑ Stettina, C; Horz, J (2015). Agile portfolio management: An empirical perspective on the practice in use. International Journal of Project Management. 33(1): 140—152.
  5. ↑ Elssamadisy, Amr. Has SAFe Cracked the Large Agile Adoption Nut?. InfoQ. Архів оригіналу за 11 листопада 2017. Процитовано 11 листопада 2017.
  6. ↑ Maximini, Dominik (11 вересня 2013). A critical view on SAFe - Scrumorakel - Blog. Scrum Oracle. Архів оригіналу за 5 травня 2021. Процитовано 27 листопада 2017.
  7. ↑ Stafford, Jan (9 грудня 2013). Scaling Agile development calls for defined practices, consultant says. SearchSoftwareQuality. Архів оригіналу за 15 червня 2018. Процитовано 27 листопада 2017.
  8. ↑ Killick, Neil (21 березня 2012). The Horror Of The Scaled Agile Framework. Agile, Scrum, Kanban, Lean, and everything that's in between. Архів оригіналу за 1 грудня 2017. Процитовано 27 листопада 2017.
  9. ↑ Certification. Scaled Agile. Архів оригіналу за 18 лютого 2016. Процитовано 19 лютого 2016.

Див. також

ред.
Отримано з https://uk.wikipedia.org/wiki/Scaled_agile_framework