13 червня 2017   •   Yaroslav Boruta   •   15 min read

Agile чи Waterfall — який варіант відповідає вашому бізнесу?

Протистояння Agile і Waterfall не стільки теоретичне, скільки практичне. Вибір методики, непотрібної під ваш проект, в кращому випадку істотно загальмує його розвиток, в гіршому — відправить в список «ТОП-провалів року».

Гнучка і каскадна моделі розробки проекту (Agile і Waterfall відповідно) — одні з найбільш популярних серед інших методологій управління. Вивчивши особливості конкретно вашого проекту, і озброївшись знаннями з цієї статті, ви зможете з повною впевненістю відповісти на питання: «Що підійде моєму бізнесу — Agile або Waterfall?»

Agile — система ідей і принципів «гнучкого» управління проектами, на основі яких розроблені популярні методи Scrum, Kanban і інші. Ключовий принцип — розробка через короткі ітерації (цикли), в кінці кожного з яких замовник (користувач) отримує робочий код або продукт.
Waterfall — методика управління проектами, яка має на увазі послідовний перехід з одного етапу на інший без пропусків і повернень на попередні стадії.

Що таке Agile

Як і інші популярні методології розробки та управління проектами, Agile з’явився порівняно недавно в США. На відміну від CPM і CCPM, за появу гнучкої методології розробки відповідальна відразу ціла група людей — 17 американських IT-фахівців зі штату Юта. Разом з «Маніфестом гнучкої розробки ПО», в якому вперше прозвучав термін «Agile» вони прописали 12 принципів Agile-розробки.

Їх суть зводиться до таких ключових моментів, що визначає характер гнучкого методу розробки:

  1. Люди і взаємодія важливіші процесів та інструментів
  2. Робочий продукт важливіший вичерпної документації
  3. Співпраця з замовником важливіша узгодження умов контракту
  4. Готовність до змін важливіша проходження попереднім планом.
Agile став основою для цілого ряду гнучких методик, серед яких найбільш відомі Scrum, Lean та екстремальне програмування.

Scrum — методологія гнучкої розробки на основі Agile, в основі якого лежить «спринт» — відрізок від 1 до 4 тижнів, після закінчення якого повинна бути отримана робоча версія продукту.
Lean — метод, який виріс на основі системи управління виробництвом Toyota Production System. В його основі — філософія постійного вдосконалення на всіх рівнях організації, де одне з ключових понять — цінність (то, за що готовий платити замовник).
Екстремальне програмування (XP) — одна з Agile — методик, де важлива роль відводиться періодичній грі в планування із залученням замовника. Вона дозволяє визначити недоліки попередньої ітерації, пріоритетність задач, бажану функціональність продукту з урахуванням побажань замовника.


Переваги та недоліки методу Agile

До переваг методу відносяться:

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

Не уникла методологія і недоліків, які органічно «доповнюють» її плюси:

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




Що таке Waterfall

Методика Waterfall (водоспадна система розробки) — дітище Вінстона Уолкера Ройса, директора Lockheed Software Technology Center в Остіні (штат Техас, США), піонера в області розробки програмного забезпечення.

З методикою Waterfall вийшло так, як і з багатьма винаходами: свій внесок у створення методології зробили Герберт Беннінгтон в 1956 р і Хозьер в 1961 р, а Уолкер використовував їх напрацювання, забезпечивши собі славу «творця Waterfall ». Переможців не судять ...

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

Водоспадна модель розробки waterfall

В оригінальній роботі Уолкера "Managing the development of large software systems«описані 6 стадій розробки продукту, які в 1985 році Департамент захисту США закріпив в стандартах роботи з розробниками програмного забезпечення:

  1. Системні і програмні вимоги : закріплюються в PRD (документі вимог до продукту).
  2. Аналіз : втілюється в моделях, схемах і бізнес-правилах.
  3. Дизайн : розробляється внутрішня архітектура програмного забезпечення, способи реалізації вимог. Це не тільки про інтерфейс і зовнішній вигляд ПО, а й про його внутрішнью структурну логіку.
  4. Кодінг : безпосередньо пишеться код програми, йде інтеграція програмного забезпечення .
  5. Тестування : баг-тестери (тестувальники) перевіряють фінальний продукт, заносячи в трекери відомості про дефекти коду програми або функціоналу. У разі помилок і наявності часу/фінансів відбувається виправлення багів.
  6. Операції : продукт адаптується під різні операційні системи, регулярно оновлюється для виправлення виявлених користувачами багів і додавання функціоналу. В рамках стадії також здійснюється технічна підтримка клієнтів.
Компанія Toyota, яка популяризувала методології Lean і Kanban, до кінця 2000-х користувалася каскадною моделлю розробки ПО для потреб виробництва .

Переваги та недоліки Waterfall

В число найбільших переваг методики Waterfall увійшли:

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

Серед недоліків водоспадного методу можна виділити:

  • позбавлений гнучкості процес: так, якщо проект вимагає більше тимчасових і фінансових ресурсів, чим можливо, то під ніж піде фаза тестування. Згідно з дослідженнями консалт-групи Rothman, вартість виправлення багів після випуску продукту вища в середньому в 20 разів, ніж під час повноцінного багатоетапного тестування в процесі розробки
  • «стійкість» до змін: жорсткий каркас з етапів розробки і умова надання тільки готового продукту визначають неможливість вносити зміни під час розробки
  • інерційність: на перших стадіях прогноз тимчасових і фінансових витрат може змінитися в бік збільшення, але змінити проект в сторону оптимізації витрат, зміни функціоналу або концепції до випуску готового продукту неможливо
  • підвищений ризик: класична система тестування має на увазі окреме тестування кожного з компонентів проекту, в тому числі, у взаємодії з іншими. При використанні Waterfall відбувається тестування готового продукту.

Частково недоліки водоспадної моделі розробки виправлені в модифікаціях Waterfall: Сашимі, Waterfall з субпроектів та водоспадна модель розробки зі зниженням ризику.

Сашимі або водоспадна модель з фазами, що нашаровуються — найвідоміша серед них. У ній етапи, як і в оригінальній методиці, йдуть один за одним, але при цьому перекриваються одна іншою в часі.
Waterfall з субпроектів — модель, в якій ви працюєте з трьома великими блоками: концептуалізацію, проектуванням вимог і архітектурною структурою продукту. Потім для кожного з них ви проходите стадії (субпроекти) детального проектування, кодування і тестування. В кінці проводиться інтеграція всіх компонентів на етапі тестування системи.
Водоспадна модель розробки зі зниженням ризику — модифікація класичного Waterfall, в який додані спіралі зниження ризику, які поділяють проект на міні-проекти і кореспондують їх одному або декільком ключовим ризикам.


Порівняльна таблиця

Agile

Waterfall

Суть

Гнучка модель розробки, заснована на
ітеративних принципах

Каскадна система розробки, заснована на жорсткій послідовності процесу розробки

Дата створення

2001 г.

1956 року, 1961 р 1970 г.

Розробники

Група IT-фахівців (США)

Г. Беннінгтон, Хозьер, В. Уолкер Ройс

Принципи застосування

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

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

Плюси


  1. високий рівень взаємодії між членами команди проекту
  2. швидкий результат (робочий код) в результаті «спринтів»
  3. стимулювання змін і поліпшень продукту під час його розробки
  4. безпосереднє залучення замовника до робочого процесу.

  1. зрозуміла і чітка схема робочого процесу
  2. можливість підрахунку точної кількості витрачених на проект ресурсів
  3. не вимагає витрат по налагодженню комунікацій між усіма членами команди.


Мінуси

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


Компанії-практики

Unilever, ряд банків (Альфа Банк, Home Credit, Райффайзен Банк і т.д.)

Cisco Ericsson AB, Toyota (до 2010)

Підійде вам, якщо ...

  1. над проектом працює досвідчена, висококваліфікована команда
  2. ви працюєте над стартапом
  3. потрібно швидко отримати робочу версію продукту
  4. замовник виступає в якості партнера, а не інвестора
  5. продукт розробляється в сфері, схильній до постійних змін.

  1. більша частина або вся робота над проектом проводиться на аутсорсі
  2. у вас є чітка концепція продукту, який хочете отримати
  3. ви не обмежені в часі і ресурсах створення продукту
  4. створення продукту або бізнесу побудовано на дотриманні суворої послідовності виконання задач.

Чи не підійде , якщо...

  • ви не готові витрачати додаткові ресурси на налагодження щоденної стабільної комунікації між усіма учасниками процесу
  • продукт повинен бути створений до конкретного терміну
  • бюджет проекту строго обмежений
  • вам потрібна детальна документація по всім процесам розробки.

  • ви хочете створити інноваційний продукт або великий проект
  • ви не впевнені в концепції пропонованого проекту
  • фінансові ресурси не є ключовим обмежувачем в вашому проекті.

Agile або Waterfall

Вердикт

Agile і Waterfall — дві абсолютно різні методики розробки та управління проектами. Кожна з них породила десятки модифікацій і методів, «заточених» під конкретний формат проектів.
Гнучка модель буде ідеальною для IT-компаній, стартапів, проектах в інноваційних сферах
Каскадна модель не здає позиції в будівельних проектах або проектах, де ключовим обмежувачем є термін реалізації проекту, а не фінанси
З урахуванням особливостей кожної з методик і вашого бізнесу, а також на основі критеріїв ризику, часу і залучення зацікавлених осіб, ви зможете самостійно визначити ефективну методологію.
відповісти
Александр 7 лютого 2018
В части Waterfall полная ерунда, переписанная из рекламы обучения Agile.
1. Водопад крайне эффективен, так как тред людей направлен на создание целевого продукта, а не на бесконечные вытягивание из заказчиков того, что же они все-таки хотят, переделки ранее сделанного и презентации очередных "сверх ценных" бантиков и рюшечек. Поэтому сроки и бюджет получения целевого продукта минимален и известны в начале проекта.
2. Если заказчику нужен не столько конечный результат, сколько наискорейшее получение самого малого и самого приоритетного функционала, чтобы определиться с приоритетами развития продукта, то тут тоже не нужен никакой Agile. Достаточно выполнить маленький водопадный проект, длительностью 2-4 недели. Потом сразу начать следующий.
3. Если же заказчик не готов брать на себя ответственность за определение конечной цели проекта, как это часто бывает у чинуш при освоении бюджета, то Agile конечно же очень хорошо подходит. Но это уже не разработка, а пособничество в разворовыванию бюджета.
4. Так же хорошо Agile подходит для осуществления процессной, а НЕ проектной деятельности. Например, сопровождение, внедрение ПО, поддержка и постоянное переобучение обучение пользователей.
відповісти
Чингис 9 лютого 2018
класс, спасибо за развернутый аргументированный комментарий
відповісти
Яна 2 квітня 2018
Александр, подскажите, пожалуйста, где можно прочесть подробнее про методологии управления проектами?
Глеб Батищев 7 лютого 2019
Сазерленд Джефф - Scrum. Революционный метод управления проектами
відповісти
Влад 7 червня 2019
+++
И добавлю - Agile тем более не подходит для проектного офиса с разделяемыми ресурсами
відповісти
Роман 20 січня 2020
"маленький водопадный проект, длительностью 2-4 недели"-что-то это напоминает, уж не спринт ли?
Вы сами незаметно перешли от каскадной к Agile-методологии.
+813
відповісти
Дима 19 вересня 2021
Полная чушь про гибкость итеративных принципах. Для манагеров, которые вообще не хотят забивать голову об организации поддержания нормального жизненного цикла, это плюс. К сожалению, управляют командой разработчиков, как правило люди в своей жизни только написали Hello word!! на каком нибудь простеньком VBA и НИ РАЗУ не довели проект в качестве разработчика от начала и до конца. Насмотрелись рекламных/вебинаров про Agile.
відповісти
J 28 вересня 2021
Не скроллится таблица с мобильных устройств (safari)
відповісти
Dmitriy 28 вересня 2021
Для уточнения деталей и предоставления ответа свяжитесь с нами, пожалуйста, через форму обратной связи https://worksection.com/support.html

esc
Поділитись у
или
Закладки корисна опція, яка розташована у верхньому правому кутку вашого акаунту Worksection. Для чого потрібні закладки Усе “гаряче”, “термінове” та “важливе” ви можете додати у закладки, аби тримати...
23 червня 2021   •   2 min read
В компании, где ведется несколько проектов одновременно, важно собирать данные по разным параметрам: по количеству затраченного на проект времени, по количеству успешно завершенных задач, по плановому...
1 червня 2021   •   7 min read
Для компаній, які працюють на "погодинці", тайм-трекер – ключовий інструмент в реалізації проектів і задач. Як приклад: наш клієнт – агентство performance-маркетингу ROMAN.UA. За допомогою тайм-трекера...
17 травня 2021   •   7 min read

Більш ніж 1300 компаній використовують Worksection. Приєднуйтесь!

Worksection використовують 1300 компаній

Відмінно!

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