Agile vs Waterfall – підходи до розробки програмних продуктів

17.08.2022 562

Підхід до розробки програмного забезпечення визначає успішність реалізації проекту. Найбільш популярними є методики Agile та Waterfall. Слід відзначити, що ці методи є досить зрілими та протестовані на практиці. І хоче в них є спільні риси, загалом підходи принципово відрізняються. Та й на практиці рідко вони зустрічаються у чистому вигляді. У чому різниця між Agile vs Waterfall, та на що спиратися при виборі методики розробки ПЗ, розповімо нижче.

Методологія Agile: основні риси

Система Agile об’єднує ідеї та принципи для гнучкого управління процесом розробки проекту. Методологія з'явилися відносно недавно в США. Розробили її 17 ІТ-фахівців, які й зафіксували 12 принципів цього методу, що можна звести до наступного:

1. Процеси та інструменти є менш значущими, аніж люди та їх взаємодія, комунікація.
2. Продукт, що працює, важить більше документації, в якій прописано все до найменших деталей (Але ми в SDH документаціями не нехтуємо).
3. Співпраця із замовником в перспективі дає значно більше, аніж погоджені умови контракту.
4. Іноді слідувати запланованому алгоритму – не завжди правильно, коли є можливість змінюватися та адаптуватися до нових обставин.

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

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

В компанії SDH зазвичай після кожного спринта ми проводимо демо для замовника та отримуємо фідбек.

Плюси:

• Оскільки орієнтація процесу — на клієнта, забезпечується участь останнього на всіх етапах;
• Гарантії високої якості розробки;
• Клієнт може побачити результати на проміжному етапі, аби скорегувати їх;
• Відчуття дотичності замовника об’єднує, залучає до роботи;
• Такий підхід дає змогу створювати базову версію продукту, аби використовувати її протягом наступних ітерацій. Це незамінно в проєктах, де час представлення на ринку має величезне значення;
• Вищий рівень мотивації та організації команд, що працюють за Agile;
• Відмов значно менше, бо фокус – на поступовому прогресі, що контролюється клієнтом.

Разом з тим, є і недоліки методики Agile:

• Проект може зірватися за відсутності впевненості у продукті;
• Може знадобитися експерт, аби ухвалити важливе рішення;
• Методика непридатна для невеликих проектів (наприклад, сайтів-візиток, лендінгів);
• Прогнозований час розробки може збільшитися, якщо на кожному спринті додавати нові ідеї і таким чином значно розширювати скоп робіт для MVP.

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

“При реалізації цього підходу ми стараємося визначитися разом із замовником про основні функціональності, які мають бути при запуску MVP проекта, щоб надалі розвивати його, спираючись на фідбек від користувачів”, — ділиться досвідом Марина Фоменко, Head of PM у Software Development Hub. 

 

 

Що таке методологія Waterfall

Модель «водоспаду», що застосовується в ході розробки ПЗ, є класичною. Це повна протилежність гнучкій Agile з її постійними тестуваннями та вдосконаленнями результатів. Методика Waterfall базується на поступовому, планомірному проходженні процесу, що розбивається на стадії. І перейти до наступного етапу можна, лише закривши задачі попереднього. 6 стадій розробки ПЗ закріплені засновником моделі Вінстоном Волкером Ройсом 1985 року:

1. Системні та програмні вимоги, зафіксовані документально.
2. Аналіз, втілений у схемах та бізнес-правилах.
3. Дизайн. На цьому етапі будується внутрішня архітектура, можливості втілення вимог, розробляється інтерфейс та структурна логіка.
4. Кодинг.
5. Тестування кінцевого продукту, виправлення помилок.
6. Адаптування продукту під операційні системи.

Переваги Waterfall:

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

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

Серед мінусів:

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

Ці недоліки враховані та виправлені у моделях, створених на базі Waterfall: Waterfall Сашимі з фазами, що нашаровуються, Waterfall із субпроєктами тощо.

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

В SDH для кількох проектів існує напрацьована збалансована модель. Замовник знає, що команда робить певну ітерацію, згідно з описаним завданням (це Waterfall). І він упевнений, що у разі будь-яких термінових змін в обставинах команда не відхилить його прохання та внесе зміни прямо до поточної ітерації (це Agile). 

Agile MVP Waterfall Project Management