Протистояння Agile vs Waterfall не стільки теоретичне, скільки практичне. Вибір методики, непотрібної під ваш проект, в кращому випадку істотно загальмує його розвиток, в гіршому — відправить в список “ТОП-провалів року”.
Гнучка і каскадна моделі розробки проекту (Agile і Waterfall відповідно) — одні з найбільш популярних серед інших методологій управління. Вивчивши особливості конкретно вашого проекту, і озброївшись знаннями з цієї статті, ви зможете з повною впевненістю відповісти на питання: “Що підійде моєму бізнесу — Agile або Waterfall?”
Agile — система ідей і принципів “гнучкого” управління проектами, на основі яких розроблені популярні методи Scrum, Kanban і інші. Ключовий принцип — розробка через короткі ітерації (цикли), в кінці кожного з яких замовник (користувач) отримує робочий код або продукт.
Waterfall — методика управління проектами, яка має на увазі послідовний перехід з одного етапу на інший без пропусків і повернень на попередні стадії.
Що таке Agile
Як і інші популярні методології розробки та управління проектами, Agile з’явився порівняно недавно в США. На відміну від CPM і CCPM, за появу гнучкої методології розробки відповідальна відразу ціла група людей — 17 американських IT-фахівців зі штату Юта. Разом з “Маніфестом гнучкої розробки ПО”, в якому вперше прозвучав термін “Agile” вони прописали 12 принципів Agile-розробки.
Їх суть зводиться до таких ключових моментів, що визначає характер гнучкого методу розробки:
- Люди і взаємодія важливіші процесів та інструментів
- Робочий продукт важливіший вичерпної документації
- Співпраця з замовником важливіша узгодження умов контракту
- Готовність до змін важливіша проходження попереднім планом.
Scrum — методологія гнучкої розробки на основі Agile, в основі якого лежить “спринт” — відрізок від 1 до 4 тижнів, після закінчення якого повинна бути отримана робоча версія продукту.
Lean — метод, який виріс на основі системи управління виробництвом Toyota Production System. В його основі — філософія постійного вдосконалення на всіх рівнях організації, де одне з ключових понять — цінність (то, за що готовий платити замовник).
Екстремальне програмування (XP) — одна з Agile — методик, де важлива роль відводиться періодичній грі в планування із залученням замовника. Вона дозволяє визначити недоліки попередньої ітерації, пріоритетність задач, бажану функціональність продукту з урахуванням побажань замовника.
Переваги та недоліки методу Agile
До переваг методу відносяться:
- короткі і зрозумілі ітерації: цикли розробки тривають від 2 тижнів до 2 місяців, по закінченню яких замовник отримує робочу версію продукту
- висока ступінь залучення виконавців, організаторів і замовників проекту
- головним стоїть робочий продукт як основний показник прогресу — це можна розглядати як плюс, так і мінус, адже в такому випадку до команди проекту висуваються високі вимоги по самоорганізації
- мінімізація ризиків завдяки гнучкій системі внесення змін.
Не уникла методологія і недоліків, які органічно “доповнюють” її плюси:
- стимулювання постійних змін проекту: гнучкість розробки продукту може призвести до того, що він ніколи не дійде до фінальної версії
- підвищені вимоги до кваліфікації і досвіду команди: крім безпосередньо створення продукту команда повинна аналізувати можливі способи поліпшення ефективності власної роботи, безперервно обмінюватися інформацією по проекту, бути вмотивованою і самоорганізованою. Далеко не завжди ресурси проекту дозволяють залучити таких фахівців
- філософський характер методології: Agile — це не чітка інструкція до дії, а ціла філософська концепція. Команда не може механічно застосувати механіку “гнучкої” розробки, потрібно прийняти ключові принципи системи
- складність підрахунку підсумкової суми робіт: стимуляція змін і вдосконалення кінцевого продукту призводить до плаваючого значення вартості проекту.
Що таке Waterfall
Методика Waterfall (водоспадна система розробки) — дітище Вінстона Уолкера Ройса, директора Lockheed Software Technology Center в Остіні (штат Техас, США), піонера в області розробки програмного забезпечення.
З методикою Waterfall вийшло так, як і з багатьма винаходами: свій внесок у створення методології зробили Герберт Беннінгтон в 1956 р і Хозьер в 1961 р, а Уолкер використовував їх напрацювання, забезпечивши собі славу “творця Waterfall “. Переможців не судять …Водоспадна модель розробки передбачає послідовне проходження процесу, розбитого на стадії. Перехід до нового етапу можливий тільки після завершення попереднього.
В оригінальній роботі Уолкера “Managing the development of large software systems“описані 6 стадій розробки продукту, які в 1985 році Департамент захисту США закріпив в стандартах роботи з розробниками програмного забезпечення:
- Системні і програмні вимоги : закріплюються в PRD (документі вимог до продукту).
- Аналіз : втілюється в моделях, схемах і бізнес-правилах.
- Дизайн : розробляється внутрішня архітектура програмного забезпечення, способи реалізації вимог. Це не тільки про інтерфейс і зовнішній вигляд ПО, а й про його внутрішнью структурну логіку.
- Кодінг : безпосередньо пишеться код програми, йде інтеграція програмного забезпечення .
- Тестування : баг-тестери (тестувальники) перевіряють фінальний продукт, заносячи в трекери відомості про дефекти коду програми або функціоналу. У разі помилок і наявності часу/фінансів відбувається виправлення багів.
- Операції : продукт адаптується під різні операційні системи, регулярно оновлюється для виправлення виявлених користувачами багів і додавання функціоналу. В рамках стадії також здійснюється технічна підтримка клієнтів.
Переваги та недоліки Waterfall
В число найбільших переваг методики Waterfall увійшли:
- зрозуміла і проста структура процесу розробки: це знижує поріг входження для команд
- зручна звітність: можна легко відстежити ресурси, ризики, витрачений час і фінанси завдяки суворій етапності процесу розробки та детальної документації проекту
- стабільність задач: задачі, які стоять перед продуктом, ясні команді з самого початку розробки, і залишаються незмінними протягом усього процесу
- оцінка вартості та термінів здачі проекту: терміни випуску готового продукту, як і його підсумкова вартість можуть бути прораховані до моменту запуску розробки.
Серед недоліків водоспадного методу можна виділити:
- позбавлений гнучкості процес: так, якщо проект вимагає більше тимчасових і фінансових ресурсів, чим можливо, то під ніж піде фаза тестування. Згідно з дослідженнями консалт-групи Rothman, вартість виправлення багів після випуску продукту вища в середньому в 20 разів, ніж під час повноцінного багатоетапного тестування в процесі розробки
- “стійкість” до змін: жорсткий каркас з етапів розробки і умова надання тільки готового продукту визначають неможливість вносити зміни під час розробки
- інерційність: на перших стадіях прогноз тимчасових і фінансових витрат може змінитися в бік збільшення, але змінити проект в сторону оптимізації витрат, зміни функціоналу або концепції до випуску готового продукту неможливо
- підвищений ризик: класична система тестування має на увазі окреме тестування кожного з компонентів проекту, в тому числі, у взаємодії з іншими. При використанні Waterfall відбувається тестування готового продукту.
Частково недоліки водоспадної моделі розробки виправлені в модифікаціях Waterfall: Сашимі, Waterfall з субпроектів та водоспадна модель розробки зі зниженням ризику.
Сашимі або водоспадна модель з фазами, що нашаровуються — найвідоміша серед них. У ній етапи, як і в оригінальній методиці, йдуть один за одним, але при цьому перекриваються одна іншою в часі.
Waterfall з субпроектів — модель, в якій ви працюєте з трьома великими блоками: концептуалізацію, проектуванням вимог і архітектурною структурою продукту. Потім для кожного з них ви проходите стадії (субпроекти) детального проектування, кодування і тестування. В кінці проводиться інтеграція всіх компонентів на етапі тестування системи.
Водоспадна модель розробки зі зниженням ризику — модифікація класичного Waterfall, в який додані спіралі зниження ризику, які поділяють проект на міні-проекти і кореспондують їх одному або декільком ключовим ризикам.
Порівняльна таблиця Agile vs Waterfall
| Agile | Waterfall | |
| Суть | Гнучка модель розробки, заснована на ітеративних принципах | Каскадна система розробки, заснована на жорсткій послідовності процесу розробки |
| Дата створення | 2001 г. | 1956 року, 1961 р 1970 г. |
| Розробники | Група IT-фахівців (США) | Г. Беннінгтон, Хозьер, В. Уолкер Ройс |
| Принципи застосування |
|
|
| Плюси |
|
|
| Мінуси |
|
|
| Компанії-практики | Unilever, ряд банків (Альфа Банк, Home Credit, Райффайзен Банк і т.д.) | Cisco Ericsson AB, Toyota (до 2010) |
| Підійде вам, якщо … |
|
|
| Чи не підійде , якщо… |
|
|
Вердикт Agile vs Waterfall
Agile і Waterfall — дві абсолютно різні методики розробки та управління проектами. Кожна з них породила десятки модифікацій і методів, “заточених” під конкретний формат проектів.
Гнучка модель буде ідеальною для IT-компаній, стартапів, проектах в інноваційних сферах
Каскадна модель не здає позиції в будівельних проектах або проектах, де ключовим обмежувачем є термін реалізації проекту, а не фінанси
З урахуванням особливостей кожної з методик і вашого бізнесу, а також на основі критеріїв ризику, часу і залучення зацікавлених осіб, ви зможете самостійно визначити ефективну методологію.
1. Водопад крайне эффективен, так как тред людей направлен на создание целевого продукта, а не на бесконечные вытягивание из заказчиков того, что же они все-таки хотят, переделки ранее сделанного и презентации очередных "сверх ценных" бантиков и рюшечек. Поэтому сроки и бюджет получения целевого продукта минимален и известны в начале проекта.
2. Если заказчику нужен не столько конечный результат, сколько наискорейшее получение самого малого и самого приоритетного функционала, чтобы определиться с приоритетами развития продукта, то тут тоже не нужен никакой Agile. Достаточно выполнить маленький водопадный проект, длительностью 2-4 недели. Потом сразу начать следующий.
3. Если же заказчик не готов брать на себя ответственность за определение конечной цели проекта, как это часто бывает у чинуш при освоении бюджета, то Agile конечно же очень хорошо подходит. Но это уже не разработка, а пособничество в разворовыванию бюджета.
4. Так же хорошо Agile подходит для осуществления процессной, а НЕ проектной деятельности. Например, сопровождение, внедрение ПО, поддержка и постоянное переобучение обучение пользователей.
И добавлю - Agile тем более не подходит для проектного офиса с разделяемыми ресурсами
Вы сами незаметно перешли от каскадной к Agile-методологии.