Sign in Subscribe
Framework

Agile frameworks

Zosym Maxym

• 11 min read

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

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

Маніфест Agile

Отже, як зрозуміти різницю між різними гнучкими підходами до управління проектами, і як вирішити, який гнучкий процес вам слід використовувати?

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

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

Agile Methodologies, Frameworks, & Approaches

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

  1. Scrum
  2. Kanban
  3. Scrumban
  4. DevOps/(Bus)DevOps
  5. Design Thinking
  6. Agile Project Management (AgilePM)
  7. PRINCE2 Agile
  8. PMI-Agile Certified Professional (PMI-ACP)
  9. Project Half Double
  10. Agile Program Management (AgilePgM)
  11. Scaled Agile Framework® (SAFe®)
  12. Large-Scale Scrum (LeSS)
  13. Nexus
  14. Scrum at Scale (S@S)
  15. Spotify Model
  16. Scaled Agile Lean Development (ScALeD)
  17. AgileSHIFT
  18. Agile Fluency
  19. Open Space Agility (OSA)
  20. Agility Scales
  21. Холократія (Holocracy)
  22. Sociocracy
  23. Disciplined Agile (DA)
  24. Praxis
  25. Toyota Production System (TPS)
  26. Agile Digital Services (AgileDS)
  27. Management of Portfolios (MoP)
  28. Standard for Portfolio Management (SfPfM)
  29. Agile Portfolio Management (AgilePfM)
  30. Evidence-Based Portfolio Management (E-B PfM)
  31. Bimodal Portfolio Management (Bimodal PfM)
  32. eXtreme Programming (XP)
  33. Acceptance Test Driven Development (ATDD)
  34. Test-driven development (TDD)
  35. Behavior-Driven Development (BDD)
  36. Feature-Driven Development (FDD)
  37. Experiment-Driven Development (EDD)
  38. User Experience Design (UX Design)
  39. Agile Business Analysis (AgileBA)
  40. Continuous Integration/Continuous Deployment (CI/CD)
  41. Agile Modeling (AM)
  42. Crystal Agile Framework

Загальний погляд на Agile Methodologies

Щоб отримати перше враження про різні підходи, автор статті [1] спробував внести певну структуру в підходи, методів і фреймворків.

На зображенні нижче він розмістив 41 найвідоміший гнучкий підхід у певній структурі (деякі з них знаходяться в декількох місцях). Ця картина базується на простішій версії з книги "Масштабування гнучкості в організаціях" Henny Portman.

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

Підходи, рамки або методи позиціонуються у двох основних розділах: розділ "одноразові програми/проекти" та розділ "звичайний/безстроковий". Деякі з них підпадають під обидва розділи, тому вони охоплюють всю сферу.

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

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

Я також кластеризую деякі методи на основі їхньої мети: вони орієнтовані на продукт, на команду чи на культуру? Звичайні або невизначені парасолькові рамки, які використовуються більш постійно (як орієнтовані на продукт, так і на команду), зосереджені саме на ІТ та розробці продукту. Підходи, орієнтовані на культуру, допомагають організаціям підвищити свою гнучкість.

Team-Level Agile Methodologies

Скрам (Scrum)

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

Окрема статті про Скрам (Scrum)

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

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

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

Скрам зосереджений навколо 5 основних процедур, які наведені нижче:

  • Догляд за відставанням (Backlog grooming)
  • Планування спринту (Sprint planning)
  • Щоденний скрам (який також іноді називають щоденним стендапом) Daily scrum
  • Огляд спринту (Sprint review)
  • Ретроспектива спринту (Sprint retrospective)

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

Скрам (Scrum) в BABOK v3

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

Канбан (Kanban)

На додаток до Scrum, на рівні команди ви побачите такі фреймворки, як Kanban (як описано в Kanban Guide for Scrum Teams), або його родичі Scrumban, DevOps і BusDevOps. Вони можуть бути використані як в ІТ-середовищі, так і в інших середовищах.

Окрема стаття про Канбан

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

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

Канбан (Kanban) в BABOK v3

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

DevOps, (Bus)DevOps, and CI/CD

Якщо поглянути на часто складний перехід до виробничого середовища, то час виходу на ринок можна скоротити, правильно організувавши перехід і зменшивши кількість помилок при переході, коли команди розробників і виробників об'єднані, а інтеграційне тестування і розгортання автоматизовано (Continuous Integration and Continuous Delivery, CI/CD). Таким чином створюється DevOps команда.

Скрамбан (Scrumban)

Скрамбан (Scrumban) - це поєднання Скраму та Канбану. Спочатку він був задуманий як перехідна модель для переходу від Scrum до Kanban, щоб дати команді можливість випробувати концепції Lean та Kanban.

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

Towards Product Or Program Level Agile

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

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

При інституціоналізації координації керівник проекту зникає, але багато завдань з управління проектом виконують інші особи (ex. the integration team в Nexus, the Release Train Engineer and the Product Manager in SAFe, etc).

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

Nexus

Nexus, як описано в The Nexus Guide, є фреймворком для ініціатив з розробки продукту або програмного забезпечення з трьома-дев'ятьма скрам-командами, в спринтах тривалістю до тридцяти днів. Nexus - це відповідь Кена Швабера, одного з батьків-засновників Scrum, на питання масштабованості Scrum.

Він вимагає більше, ніж просто бажання та гнучкої поведінки різних Scrum-команд для спільної роботи над створенням інтегрованого продукту. Nexus базується і будується на Scrum, а також на правилах і ролях, сформульованих в керівництві по Scrum. Ми можемо позиціонувати Nexus на командному та програмному рівнях SAFe, але він не пропонує положень на рівні портфеля.

Scrum at Scale (S@S)

Scrum at Scale (S@S, розроблений Джеффом Сазерлендом та Алексом Брауном) - це модульна структура. Відправною точкою в S@S є те, що всеохоплююча універсальна концепція неможлива, але що кожного разу ми повинні розглядати масштабування основних принципів Scrum.

Фреймворк може бути адаптований для вашої власної організації шляхом додавання необхідних модулів S@S. S@S базується на добре відомому фреймворку Scrum. За аналогією з Nexus можна сказати, що S@S - це відповідь Джеффа Сазерленда, поряд з Кеном Швабером, іншим батьком-засновником Scrum, на питання масштабованості Scrum.

S@S приносить найбільшу користь, коли:

  • використовується об'єктно-орієнтований технологічний стек (тобто постачання вертикальних користувацьких історій користувачів може бути здійснено протягом двох тижнів);
  • функціональні команди організації мають Т-подібні навички, продукторієнтовані цінності та мінімальний рівень бюрократії;
  • інструмент управління agile або Agile Lifecycle Management (ALM) не є обов'язковим, поки практика міцно не стане звичкою;
  • команда керівників має намір застосовувати scrum і усувати перешкоди в організації.

Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS, розроблений Крейгом Ларманом та Басом Водде) - це гнучкий фреймворк з правилами, заснований на принципах та експериментах.

Компанія LeSS пропонує у вільному доступі базу знань (less.works), що містить інтегрований підхід, принципи, описи процесів, визначення, ролі, приклади тощо, для великомасштабної, переважно ІТ-орієнтованої, розробки продуктів. Прозорість також є ключовою концепцією LeSS. Перша версія датується 2005 роком і з того часу постійно ведеться робота з використання та подальшого розвитку LeSS.

LeSS приносить найбільшу користь, коли:

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

Scaled Agile Framework® (SAFe®)

Scaled Agile Framework (SAFe, розроблена Діном Леффінгвеллом [2]) - це структура, яка дозволяє масштабувати гнучкі команди з метою створення кращих систем, підвищення рівня залученості співробітників та використання правильних міркувань щодо витрат.

Окрема стаття про Scaled Agile Framework® (SAFe®)

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

SAFe базується на п'яти основних компетенціях: lean-agile лідерство (lean-agile leadership), командна та технічна гнучкість (team and technical agility), DevOps та реліз за вимогою (DevOps and release on demands), бізнес-рішення та ощадливі системи (business solutions and lean systems) та ощадливе управління портфелем (lean portfolio management).

Озираючись на карту методів, у розділі "Business as usual/indefinite", ми можемо побачити вищезгадані методи SAFe, LeSS, Nexus та S@S у розділі, орієнтованому на продукт. Всі вони стосуються прикладів, коли кілька команд працюють над одним складним продуктом або потоком створення цінності (продуктово-орієнтовані фреймворки product-targeted frameworks).

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

Крім того, кілька підходів (не перелічених на рисунку) розрізняють продукти, які потребують співпраці максимум дев'яти команд (загалом команда команд не повинна перевищувати число Данбара у 125-150 осіб) та команду команд команд (наприклад, SAFe large solutions, Nexus+, LeSS Huge).

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

Модель Spotify та ScALeD

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

Тут можна позиціонувати модель Spotify (розроблену Хенріком Кнібергом, Андерсом Іварссоном та Йоакімом Сунденом), а також Scaled Agile Lean Development (ScALeD, розроблену Пітером Беком, Маркусом Гартнером, Крістофом Матісом, Стефаном Роком та Андреасом Шліпом).

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

Spotify приносить найбільшу користь, коли:

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

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

Гнучке управління проектами (AgilePM)

Гнучке управління проектами (AgilePM, що походить від Dynamic Systems Development Method, також відомого як DSDM) походить від Agile Business Consortium. Це метод, за допомогою якого різні, можливо, постійні, гнучкі команди та негнучкі команди координуються протягом тривалості проекту.

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

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

PRINCE2 Agile

PRINCE2 Agile (похідне від PRINCE2 від AXELOS) включає в себе як існуючий PRINCE2, так і гнучкий спосіб мислення. Гнучкий спосіб мислення слід розглядати як гнучку поведінку, концепції, рамки, основні напрямки та методи. Існуючі принципи, процеси та теми PRINCE2 залишаються, але повинні бути адаптовані з використанням гнучкого способу роботи та самого проекту.

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

PMI-ACP

PMI Agile Certified Practitioner або PMI-ACP (на додаток до PMBoK Guide від PMI) не є окремою концепцією, а являє собою сертифікацію, засновану на різних книгах (і описаних в них концепціях і базових методиках).

В рамках PMI-ACP визначено 7 доменів, кожен з яких поділяється на ряд областей завдань. До цих сфер відносяться принципи та рамки Agile (principles and framework), орієнтована на цінності поставка (value-driven delivery), управління зацікавленими сторонами (stakeholder management), ефективність роботи команди (team performance), адаптивне планування (adaptive planning), виявлення та вирішення проблем (problem detection and solutioning), а також постійне вдосконалення (continuous improvement).

Project Half Double

Проект Half Double управляється спільнотою відданих практиків з управління проектами, які захоплені своєю справою. Він був створений спільнотою відданих практиків з управління проектами в ітеративний спосіб.

Методологія базується на чотирьох складових, які дозволяють досягти подвійного впливу за половину часу: вплив (impact), потік (flow), лідерство(leadership) та переклад на місцеву мову (local translation).

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

Дисциплінований Agile (DA)

Disciplined Agile (DA) охоплює як разові проекти та програми, так і звичайну розробку продуктів. Інструментарій DA - це інструментарій для прийняття рішень, який описує, як працюють гнучкі команди з розробки програмного забезпечення, DevOps, ІТ та бізнес-команди в умовах корпоративного класу.

Disciplined Agile (DA) пропонує портфельний процес, в якому, крім проектів, враховується ряд "звичайних" аспектів, таких як постійні команди та оперативне управління існуючими ІТ-рішеннями.

DA приносить найбільшу користь, коли:

  • організації хочуть визначити власний шлях масштабування agile;
  • потрібно зберегти гнучкість по всій компанії;
  • потрібно залишити можливість вибору процесу і (або) платформи.

Гнучкі цифрові послуги (AgileDS)

Гнучкі цифрові послуги (AgileDS) призначені для надання та безперервного функціонування, підтримки та обслуговування цих послуг (постійна гнучка команда з надання послуг, що використовує життєвий цикл продукту/послуги).

Crystal Agile Framework

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

Agile отримав окрему секцію в BABOK v3

11.1 The Agile Perspective 11.1.3 Approaches and Techniques

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

Посилання на матеріали:
- [1] https://thedigitalprojectmanager.com/projects/pm-methodology/agile-methodologies/
- [2] https://www.scaledagileframework.com/