Чому ми маємо так багато моделей для управління проєктами? І чому не можна разом обрати для використання єдину ідеальну універсальну модель? Насправді, відповідь лежить на поверхні.

Всі існуючі моделі мають в собі спільне «ядро» — потребу в фасилітації, або сприянні, реалізації продукту з найвищою цінністю для користувача. Однак, низка факторів, скажімо, складність проєкту, фронт робіт, обмеженість в часі та бюджеті, кількість спеціалістів в команді, змушують підбирати модель, яка врахує вхідні фактори і оптимізує процес розробки продукту. Тобто, все заради оптимізації.

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

Тут варто згадати про одну з найвідоміших методологій в управлінні проєктами Waterfall (Водоспадна модель). Ця методологія виникла в промисловості, але актуальна й зараз. Чому?

1. Модель добре працює з передбачуваними, повторюваними процесами, як-от, серійне виробництво.
2. Не вимагає від замовника постійної комунікації та зворотного зв’язку протягом усього проєкту, тому що максимальна кількість вимог має бути сформульована на перших фазах проєкту.
3. Після визначення вимог замовник одразу знає остаточну вартість проєкту.

Але коли ми говоримо про використання методології в інших сферах, зокрема у сфері розробки програмного забезпечення, ми бачимо слабкості такого підходу:

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

Ці і інші недоліки системи Waterfall сформували підґрунтя для виникнення гнучкої моделі управління проєктами Agile. Засновники Аgile позиціонують його більше, як світогляд (mindset), основні цінності та принципи якого викладені в Agile маніфесті.

Переваги Agile:

1. Висока адаптивність підходу, завдяки якому Agile стрімко розвивається у сферах Technology, Healthcare/Pharma, Industrial Manufacturing і інших.
2. Протягом усього життєвого циклу проєкту йде тісна комунікація з замовником, що позитивно впливає на задоволення потреб клієнтів.
3. Скорочується час виходу продукту на ринок.

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

Agile об’єднує навколо себе велику кількість концепцій та технік, найпоширеніші з яких Scrum, Kanban, Scrumban, Lean, Extreme Programming (XP) й інші. За підсумками 2022 року, маємо такий рейтинг:

Рейтинг очолюють Scrum, Kanban та їх мікс — Scrumban.

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

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

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

Scrumban — суміш церемоній Scrum з елементами Kanban, що допомагає команді поліпшувати ефективність завдяки:

• Ліміт WIP (work in progress) — обмеження кількості задач, над якими команда працює одночасно, з метою уникнення перенавантаження і підвищення якості виконання. Якщо команда обрала ліміт WIP у 3 задачі, то вона може працювати одночасно тільки над 3 задачами.
• Система витягування (Pull System) — процес, який допомагає пріоритезувати задачі таким чином, щоб команда працювала тільки над найважливішим на даний момент.
• Безперервний потік (Continuous Flow) — підхід до роботи, в якому завдання проходять крізь весь процес розробки без затримок, що максимізує швидкість та ефективність.

Як проєктний координатор та скрам мастер, я брала участь у реалізації кількох проєктів в рамках проєктного навчання в EPAM University. На прикладі одного із них, а саме проєкту «Дітям від дітей», я відповім на ряд найпопулярніших питань від команд розробників, які вперше стикались зі Scrum на реальному проєкті.

Спершу, кілька слів про проєкт та його особливості.

“Дітям від дітей” (‘Children to Children’) — проєкт заснований у 2020 році авторкою оповідань Катериною Халецькою. Його мета: допомогти дітям з інвалідністю (з вадами зору) знаходити друзів по всьому світу через творчість. Тож основним завданням проєкту є розробка простору, адаптованого під потреби дітей, що дозволить розширювати їхнє коло спілкування.

В середньому над проєктом працює 10-12 осіб. Зокрема, UI\UX дизайнери, які також виконують роль Product Owners (власників продукту), бізнес аналітик, системні інженери, кілька Back-end та Front-end розробників, а також проєктний координатор та скрам майстер.

Чому для цього проєкту обрали концепцію управління Scrum?

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

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

Отже, топ питань, які мені найчастіше доводилося чути від студентів.

Навіщо щодня збиратися на Daily Scrum зустрічі? Чи є це певною формою контролю?

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

Скрам майстер – це проєктний менеджер в Scrum?

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

Я не розумію, як оцінювати задачі в story point. Це все дуже абстрактно, чому не можна робити це в годинах чи днях?

Мабуть, це одне з найпоширеніших питань, водночас – одне із найскладніших. Новачкам дійсно важко оцінювати задачі в конкретних story point, а на додачу враховувати оцінку попередніх задач. Ось декілька порад, щоб полегшити процес оцінювання розміру задачі.

• Обговоріть з командою, чи всі розуміють, як оцінювати в story point.
• Можливо вам важко оцінити задачу, бо ви не до кінця розумієте, як її виконати. Спробуйте знайти експерта, який розповість про особливості задачі або виділіть час на вивчення задачі детальніше.
• Розгляньте можливість розбити задачу на дрібні складові. Зазвичай менші задачі легше оцінювати. Проте такий підхід не завджи є можливим або достатньо ефективним.
• Обговоріть з вашою командою, чи дійсно вам варто дотримуватися оцінювання в story point. Адже це не є вимогою у Scrum і ви можете використовувати той варіант оцінювання, який є зручним для вашої команди.

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

Джерела для більш детального вивчення оцінювання в story points:

What Are Agile Story Points?

Don’t Equate Story Points to Hours

В чому різниця story point, man day, t-shirt size, bucket system?

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

Story points — це система оцінювання, яка базується на складності задачі, а не на часі. Ця система дозволяє більш точно оцінювати складні задачі та враховувати фактори, що впливають на їх виконання (часто використовують числа Фібоначчі для оцінювання задач: 0, 1, 1, 2, 3, 5, 8, 13, 21 і т д.)

Man days — це система оцінювання, яка базується на часі, необхідному для виконання задачі. Один man day — це один робочий день.

T-shirt size — це система оцінювання, яка базується на "розмірі" задачі. Задачі оцінюються за розмірами одягу: XS, S, M, L, XL, XXL. Ця система дозволяє швидко оцінювати задачі та інтуїтивно орієнтуватися в їх складності.

Bucket system — це система оцінювання, яка базується на "складності" задачі. Задачі розподіляються на кілька "категорій" або "кошиків", в залежності від їх складності. Наприклад, "кошик 1" може містити найпростіші задачі, а "кошик 5" — найскладніші.

Джерела

► LinkedIn Agile vs Waterfall LinkedIn course

► Agile vs Waterfall Project Management

► Agile Vs. Waterfall: Which Project Management Methodology Is Best For You?

► The 2020 Scrum GuideTM

► Kanban Guide