Вибір між методологіями управління проєктами: Agile чи Waterfall?
Перш ніж перейти до відповіді на головне питання, важливо визначити, якої мети ви прагнете досягти, реалізуючи свій проєкт.
Уявіть, яким буде ваш продукт через місяць, пів року, рік. Сформулюйте це бачення вже зараз. Такий підхід допоможе вам оцінити перспективу, встановити очікування щодо вашої здатності до прогнозування, гнучкості, швидкості виходу на ринок і контролю витрат.
Сьогодні застосування каскадного методу (Waterfall) у розробці проєктів може здаватися застарілим. Досвід показує, що для оперативного реагування на зміни ринку потрібна гнучкість. Однак, якщо ваша мета – випустити через рік продукт з чітко визначеним і обмеженим набором функцій, а ваша команда не має досвіду роботи за гнучкою методологією, консервативний підхід Waterfall може бути прийнятним варіантом.
Але не кожна ситуація є настільки очевидною. Давайте розглянемо, як правильно оцінити, яка методологія підходить саме вашому проєкту.
Що являє собою Waterfall?
Замість академічних визначень, розглянемо практичну реалізацію проєкту за методологією Waterfall:
- Початкове планування: визначення кінцевого продукту та його орієнтовної вартості.
- Збір вимог: ретельне обговорення всіх деталей кінцевого продукту, узгодження та підтвердження вимог.
- Оцінка: визначення бюджету на основі узгоджених вимог.
- Розробка: створення функціонально-технічного проєкту, узгодження його із зацікавленими сторонами.
- Реалізація: розробка кінцевого продукту згідно з проєктом.
- Тестування: проведення різних видів тестування (модульного, системного, функціонального, інтеграційного, продуктивності, регресійного, користувацького та інших). Документування результатів і узгодження їх із зацікавленими сторонами.
- Розгортання: випуск продукту в робоче середовище для користувачів.
- Підтримка: виправлення помилок, виявлених у процесі експлуатації.
Весь цей процес може зайняти від кількох місяців до кількох років. Користувачі зможуть оцінити результат лише наприкінці процесу, і тоді настає момент істини. Якщо протягом цього часу виникне потреба у зміні кінцевого продукту, це розглядається як запит на зміну. Дизайн доведеться переглянути, переробити та затвердити повторно. Кожна зміна збільшує тривалість проєкту, вимагаючи повторного запуску всіх попередніх етапів.
Однак, цей підхід має свої переваги: чітке визначення етапів, фіксований бюджет для кожного етапу та фіксований термін виконання. Якщо ймовірність змін мінімальна, цей варіант може бути оптимальним, хоча й доведеться довго чекати на результат.
Як працює Agile?
Ось приклад роботи проєкту в середовищі Agile:
- Визначення бізнес-бачення: загальне розуміння кінцевого продукту, його бізнес-цілей і користі для користувачів.
- Формування списку: визначення епосів функціоналу та технічних рішень, необхідних для реалізації бачення.
- Оцінка: оцінка епосів та розробка очікувань щодо бюджету та термінів. Визначення MVP (мінімально життєздатного продукту) і набору інших характеристик кінцевого продукту.
- Створення команди: формування scrum-команди і планування спринтів. Розбиття епосів на конкретні функції та історії, їх оцінка і планування на основі пріоритетів.
- Робота над спринтами: реалізація історій у межах кожного спринту, включно з проєктуванням, розробкою, тестуванням і розгортанням. Показ результату наприкінці кожного спринту та збір відгуків.
- Адаптація: внесення змін до функцій або історій з метою адаптації до оновлених обставин. Відображення цих змін у наступних спринтах.
- Випуск MVP: публікація мінімально життєздатного продукту для отримання зворотного зв’язку від користувачів.
- Подальший розвиток: продовження розробки інших функцій, враховуючи відгуки користувачів.
Це лише загальний огляд, але різниця між Agile та Waterfall очевидна. Швидкий зворотний зв’язок, адаптивність, реагування на зміни потреб, своєчасний випуск першого цінного продукту – це переваги, яких ви не отримаєте у проєкті Waterfall.
Agile проти Waterfall
Для успіху проєкту потрібна відповідна методологія управління. Це означає визначення процесів, показників, оцінок і загальних підходів до роботи для всієї команди.
Команда повинна знати правила, критерії досягнення віх, терміни виконання, а також способи вимірювання та оцінки успіху. Зацікавлені сторони повинні розуміти, чого чекати від проєкту та коли вони побачать перші результати.
Загалом можна стверджувати, що проєкти, які працюють у хмарних середовищах, частіше обирають гнучкі методології (або повинні це робити). Проєкти, пов’язані з локальною інфраструктурою, все ще віддають перевагу каскадним процесам. Це є логічним наслідком.
Хмарне середовище створено для постійних змін, швидко адаптуючись до нових реалій завдяки “еластичним” сервісам. Локальна інфраструктура зазвичай визначається на початку, і її важко змінити з часом, тому команда працює з фіксованими параметрами протягом усього проєкту.
Коротке порівняння підходів Agile та Waterfall.
Характеристика | Waterfall | Agile |
Обробка вимог користувача | Зміни розглядаються як формальний процес (запит на зміну). Потребує переробки, що впливає на витрати і терміни | Зміни є частиною звичайного процесу без істотного впливу на витрати чи терміни |
Планування та масштаб проєкту | Масштаб визначається на початку. Етапи фіксовані і відповідають початковому плану | Має чітке бачення кінцевого продукту, але допускає зміни. Робота організована по спринтах |
Відстеження прогресу проєкту | Прогрес відстежується на кожному етапі. Затримка на одному етапі впливає на весь проєкт | Прогрес відстежується за допомогою демонстрацій наприкінці кожного спринту. Зосереджено на робочому продукті |
Командна співпраця | Різні люди на різних етапах проєкту, обмежена взаємодія | Багатофункціональна команда з постійною взаємодією |
Управління ризиками | Відстежується прогрес на кожному етапі. Реагує на ризики згідно з планом | Випереджальне рішення залежностей, адаптація плану для усунення прогнозованих ризиків |
Структура впровадження | Традиційна методологія | Потребує трансформації для адаптації до гнучкого підходу |
Цей вибір визначить кілька важливих аспектів виконання проєкту.
#1. Вимоги до проєкту та управління змінами
Важливим фактором вибору методології є підхід до обробки вимог користувача. Також варто врахувати, як діяти у випадку, якщо згодом виникне потреба у зміні узгоджених вимог.
У проєкті Waterfall всі вимоги визначаються і затверджуються зацікавленими сторонами на початку. Будь-яка зміна розглядається як запит на зміну, який потрібно перевірити, узгодити та затвердити.
Робота, виконана до цього моменту, потребує перегляду та повторного запуску. Витрати потрібно скорегувати, а проєкт може бути продовжено.
Гнучка методологія вітає зміни. Зміни є частиною звичайного процесу. Зацікавлені сторони погоджують зміни, розуміючи, що це важливо для досягнення мети проєкту. Ці зміни одразу плануються у наступних спринтах.
Раніше розроблений вміст змінюється, і команда продовжує працювати з новими вимогами. Немає втрати часу або додаткових витрат, відбувається адаптація до нової ситуації. Управління запитами на зміни не потрібне, оскільки це є частиною планування спринтів.
#2. Планування та обсяг проєкту
Проєкт Waterfall встановлює та фіксує обсяг робіт на початку. План проєкту розробляється з урахуванням цього обсягу. Проєкт розбивається на етапи, такі як аналіз, проєктування, розробка, тестування, розгортання, підтримка та обслуговування, і під ці етапи визначаються команди та ресурси. Головною метою є дотримання початкового плану у межах витрат і термінів.
Проєкт Agile має бачення кінцевого продукту, але не жорсткий план. Кінцева мета зрозуміла, але шлях до неї може змінюватися. Часові рамки проєкту визначаються на основі оцінки попиту і досвіду завантаження команд. План не має окремих етапів. Кожен спринт – це фаза, яка містить дії, необхідні команді для успішного випуску інкременту продукту.
Проєкт Waterfall розглядає зміни як ускладнення, яке потрібно подолати, а Agile – як звичайний процес без додаткових наслідків (за винятком кращого кінцевого продукту).
#3. Відстеження прогресу проєкту
Проєкт Waterfall відстежує прогрес у межах фаз проєкту. Фаза проєктування не може розпочатися до завершення фази аналізу, тестування – до завершення розробки. Затримка на одному етапі впливає на хід інших етапів. Важливо контролювати виконання завдань на кожному етапі, щоб уникнути затримок.
Проєкт Agile відстежує прогрес за допомогою демонстрацій наприкінці кожного спринту. Основним показником прогресу є робочий продукт. Важливо, щоб кожен спринт завершувався із запланованим обсягом робіт. Не варто переносити історії на наступні спринти.
Набагато простіше оцінити загальний прогрес проєкту, якщо є можливість безпосередньо випробувати поточний продукт та надати зворотній зв’язок команді.
#4. Командна співпраця
Проєкт Waterfall передбачає розподіл роботи на окремі етапи, тоді як Agile – постійну співпрацю всіх учасників команди.
У проєкті Waterfall на різних етапах працюють різні групи людей, які можуть частково перекриватись, але все ж це окремі групи.
Гнучка команда – це об’єднання людей для спілкування та створення цінності. Багатофункціональна команда здатна виконувати всі дії життєвого циклу продукту. Відокремлені команди не бажані. Постійна взаємодія команди з зовнішніми зацікавленими сторонами – це важлива умова для успіху проєкту.
#5. Управління ризиками
Важливо мати процес для відстеження ризиків, проблем, та перешкод, які можуть виникнути в ході реалізації проєкту.
У проєкті Waterfall це означає відстеження стану поточної фази проєкту. Звіт про стан зазвичай є у вигляді світлофора: зелений (все добре), жовтий (є проблеми, але відомо, як їх вирішити) або червоний (серйозні проблеми, що впливають на терміни та бюджет).
Проєкт Agile діє інакше. Він не відстежує прогрес у досягненні мети, а вирішує залежності між різними командами та видами діяльності, щоб жодна команда не очікувала на іншу. Метою є зміна плану у випадку виникнення ризику.
Іншими словами, Agile використовує всі можливості для зміни плану, щоб уникнути прогнозованих ризиків. У Waterfall ви реагуєте на ризики постфактум, намагаючись вирішити їх, дотримуючись початкового плану.
#6. Структура впровадження
Впровадження проєкту за методологією Waterfall, як правило, є менш проблематичним, оскільки це стандартний підхід, який вже давно використовується.
Проєкти Agile вимагають трансформаційних практик, зміни звичок, мислення та способів роботи. Це складний та тривалий процес. Компанії інвестують значні кошти та час, щоб навчити людей адаптуватися до гнучких процесів.
Переваги гнучкості, а саме швидка адаптація до потреб клієнтів, є значними, але складною частиною є зміна мислення людей та загального робочого середовища.
У більшості випадків це єдиний спосіб залишатися конкурентоспроможним на ринку. Зусилля, які докладаються для цього, винагороджуються успіхом.
Заключні слова
Сформулюємо чітко: якщо ваш замовник не є консерватором і зацікавлений у швидкому отриманні результатів, вам варто будувати гнучку команду. У сучасному світі це є очевидним. Це справедливо навіть для традиційної локальної інфраструктури. Якщо команда нова, або починає роботу з нуля, має сенс трансформувати процеси до гнучких методологій.
Попри це, існують проєкти, де люди відмовляються слідувати гнучкій методології і працюють поетапно, укладаючи контракти на певний час і бюджет. Вони сподіваються, що проєкт буде відповідати плану.
Це їхнє рішення, але, приймаючи його, вони обирають залишитися у минулому. Цей підхід може бути ефективним деякий час, але рано чи пізно він перестане працювати.
Перегляньте детальну статтю про життєвий цикл Agile-тестування.