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

Scrum

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

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

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

Kanban

Ще один популярний підхід — це Kanban. Його краще використовувати для продуктів на етапі підтримки. Саме в цей час досить велика частка роботи команди залежить від зворотного зв’язку користувачів ПЗ, і є постійні зміни пріоритетів роботи. 

Рекомендації для застосування

Кожен з цих фреймворків має чіткі рекомендації, які описані у гайдах:

Але, зазвичай, повністю ці рекомендації не використовуються, бо це або не потрібно, або неможливо з об’єктивних причин. Тому вельми можливі різні варіації Scrum, які називають СкрамБат, або поєднання деяких практик зі Scrum і Kanban, які називають Scrumban. 

LeSS та SAFe

Для великих проєктів і команд досить популярними є фреймворки LeSS або SAFe. 

  1. LeSS (Large-Scale Scrum) — це фреймворк, що розроблений для масштабування Scrum. LeSS полегшує використання Scrum для роботи з декількома командами, які працюють над спільним продуктом або проєктом.

Основна ідея LeSS полягає в тому, що більші команди можуть застосовувати ті ж самі Scrum-принципи, що і менші. У фреймворку LeSS існує дві версії: базова (Basic LeSS) та розширена (LeSS Huge).

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

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

Waterfall

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

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

 

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