Agile проти методу водоспаду - порівняння та відмінності
У світі роботи ми постійно чуємо, що ми перебуваємо у світі VUCA і нам потрібно адаптуватися до нашого постійно мінливого середовища. Всі говорять про трансформацію в бік гнучкості. Деякі люди, можливо, вже не бачать цього і не розуміють, що це взагалі означає для організацій.
На відміну від так званої водоспадної методології, гнучкість має зовсім інший калібр. Намагаючись зрозуміти, чим відрізняється метод Agile від методу водоспаду, і що і коли краще підходить, цілком можливо заплутатися.
Якщо ви відчуваєте те ж саме, ми можемо вам допомогти, адже тут ми пояснюємо, що означає agile vs. waterfall.
Модель водоспаду
Вірний девізу “старі мітли добре підмітають”, випробуваний і перевірений метод водоспаду використовується в багатьох компаніях. Це не дивно і, безумовно, не завжди неправильно, адже модель водоспаду є класикою проектного менеджменту і в багатьох випадках довела, що може бути ефективною.
Але що взагалі означає Agile проти Waterfall? Модель Waterfall — це лінійна модель процесу, в якій процес організовано в послідовні фази проєкту з чітко визначеними точками початку та закінчення. Приблизно це можна уявити так:
Перш ніж ми заглибимося в тему, невелике зауваження. Нещодавно у нас в гостях були 11 міжнародних експертів з гнучких методів на вебінарі –, присвяченому питанню: Як правильно масштабувати гнучкі методи?
Результатом став цей фантастичний відеозапис (англійською мовою), в якому розглядаються, наприклад, такі питання:
- Як краще починати: знизу вгору чи зверху вниз?
- Як ви допомагаєте лідерам дійти згоди щодо спільного бачення?
- Як правильно обрати гнучкий фреймворк – і чому це насправді не так важливо?
Моя найтепліша рекомендація: подивіться! Це займе відносно багато часу, але воно варте кожної хвилини.
Давайте розглянемо все це на простому прикладі:
У фазі визначення спочатку визначається, що взагалі має бути створено. Наприклад, клієнт висловлює побажання: він хоче стіл. Потім аналізуються та визначаються вимоги та складається план того, що потрібно зробити. На етапі проєктування створюється проєкт продукту, в нашому прикладі — ескіз столу.
У Фаза реалізації стає більш предметним: ми вибираємо матеріал, визначаємо точні розміри та будуємо стіл. Під час контролю ми перевіряємо, чи все працює так, як ми планували: Чи стоїть стіл? Чи правильні пропорції? The Оцінка відбувається разом із клієнтом: Ми передаємо продукт і отримуємо відгук.
Тож навіщо щось змінювати, якщо приказка говорить: “Ніколи не змінюйте працюючу систему”.
Agile (ітеративна) проти водоспадної (лінійної) методології
Незважаючи на те, що модель водоспаду, безумовно, має хороші сторони і є ефективною в багатьох ситуаціях, компаніям варто долучитися до того, щоб стати більш гнучкими. Чому? Тому що світ, в якому ми всі працюємо, висуває до нас все більш складні та суперечливі вимоги, і нам часто буває важко реагувати на них за допомогою мислення водоспаду.
Метод водоспаду має певні небезпеки. Хоча ми маємо високе відчуття безпеки завдяки плануванню та структурі, ми також дуже обмежені в наших процесах. Робочий процес досить статичний, і завдяки точному плануванню у нас є лише дуже невелика свобода дій. А це саме те, що нам потрібно в нашому динамічному середовищі. Саме тут вступає в гру гнучкість. Тож давайте подивимось на Agile проти методу водоспаду.
Але що ж таке гнучкість? Згідно з визначенням Дудень. agile - це щось на кшталт “Виявляє спритність; жвавий і спритний” і це визначення добре перекладається на світ праці.
Спритність у компаніях означає здатність ітеративно адаптувати стратегії, структури та процеси до реальних, поточних обставин. Це дуже важливо, оскільки ми стикаємося зі складними змінами, зумовленими діджиталізацією та демографічними змінами, а отже, повинні залишатися адаптивними.
До речі, коротка примітка в контексті agile-трансформації: Хочете переконатися, що ви зараз встановлюєте правильні пріоритети у вашій agile-трансформації?
Тоді пройдіть нашу перевірку зрілості для вашої agile-трансформації - це займе лише 3 хвилини. Ви навіть отримаєте орієнтир на основі понад трьохсот інших учасників. Дивіться кнопку 🙂
Побудова таблиці за допомогою гнучких методів
Давайте дотримуватися того ж прикладу, що й раніше: клієнт хоче стіл. Тож ми починаємо з того, що робимо ескіз. Я показую його замовнику, і він вирішує, чи так він його собі уявляв, чи ні. Якщо ні, то ескіз знову адаптується. Як тільки ескіз готовий, я обираю матеріал і ітеративно запитую клієнта, чи все його влаштовує.
Можливо, клієнт потім скаже: “О, ні, я думаю, я б хотів сосну замість вишні”. Значить, це все ж таки інша деревина, і ми робимо новий вибір. Потім стіл збирається, і тут також регулярно консультуються з клієнтом і в разі потреби вносять зміни.
Ви бачите: Гнучка методологія дозволяє нам гнучко реагувати на мінливі вимоги, що є актуальним у складному середовищі.
Тому статичний характер методології водоспаду не завжди є достатнім. Крім того, може статися так, що помилки в реалізації стануть очевидними лише під час оцінювання через жорстку концепцію моделі водоспаду. Це призведе до значно більших витрат на виправлення, ніж гнучка адаптація.
"Багато членів команди не наважуються висловитися!"
Вирішіть цю проблему
"Ми виявляємо занадто багато несподіваних проблем і помилок на пізньому етапі!"
Вирішіть цю проблему
"Чому іноді на підготовку простої ретроспективи я витрачаю години?"
Вирішіть цю проблемуAgile проти водоспадних методів у світі праці
Часто все ще важко розробляти гнучкі та ітеративні процеси в компаніях. Це пов’язано з тим, що люди, як правило, не схильні до ризику за своєю природою і іноді десятиліттями соціалізувалися у своєму професійному середовищі з шаблоном мислення, сформованим водоспадами.
Тут уникнення ризику відноситься до тенденції у ситуаціях прийняття рішень обирати можливість, яка пов’язана з найменшим ризиком - тобто найменшою втратою - щодо результату. (пор. Kahneman & Tversky, 1979)
Agile vs. Методи водоспаду вимагають від нас відмовитися від цієї уявної безпеки: замість того, щоб покладатися на перевірені часом методи та використовувати фіксовані структури та принципи, старі моделі мислення про ілюзію планування руйнуються та використовуються ітеративні методи. Спочатку це призводить до відчуття підвищеної невизначеності, оскільки необхідно використовувати нові - начебто ризиковані - підходи, які інтерпретують невизначеність як частину плану.
Планування цієї невизначеності призводить до необхідної гнучкості в довгостроковій перспективі. Ми розробляємо низку варіантів дій, що, в свою чергу, стабілізує безпеку в робочому світі VUCA.
Збереження балансу між динамікою та стабільністю
Гнучка методологія - як і методологія водоспаду - має певні недоліки:
- Методи Agile роблять невизначеності планування видимими і враховують їх, так що плани повинні включати більше можливостей для нових знахідок
- Конкретний результат оцінити складніше, оскільки нові знахідки можуть призвести до відхилень від початкового запланованого результату.
- З причин, згаданих вище, успіх здається менш передбачуваним, на відміну від класичного проекту водоспаду.
Зрозуміло, що залежно від проєкту різні підходи є більш-менш придатними.
Водоспадна модель особливо підходить для проєктів, які вже заздалегідь відомі та сталі вимоги включають.
Agile-методи особливо оптимальні для проєктів, у яких багато непередбачуваних факторів можуть виникнути, і тому потрібні гнучкі рефлексійні цикли. У більшості технологічних проєктів така невизначеність неминуча, тому саме тут agile-методи стрімко набирають обертів.
До речі: якщо ви хочете конкретно вимагати гнучкого мислення у вашій команді або компанії, варто ознайомитися з нашою статтею про дивовижна правда про гнучке мислення .
Agile проти водоспадного методу або комбінації?
Bei all dem Hype um “agile” kann man manchmal dazu neigen, agile Methoden als Allheilmittel zu sehen. Zu Unrecht. Das vielleicht verblüffende Ergebnis dieses Textes ist eindeutig.
Виявляється, що використання обох методологій комбінований ефективно веде до мети (Herrmann, 2007). Такі комбінації корисні в ситуаціях, коли потрібна модель водоспаду, але вона не відповідає складності проекту.
Своєрідною серединою обох методів є так званий Функціональна розробка, орієнтована на можливості (FDD).
За адресою FDD розробляєш хоч і - як у методології водоспаду - конкретний, довгостроковий план з окремими, встановленими послідовностями: функціями. Однак окремі функції дуже короткі, завдяки чому можливі короткострокові реакції на мінливі вимоги. Хоч цей підхід і не такий ітеративний, як гнучкі методи, але за певних обставин він є прийнятним компромісом.
І ось ми підходимо до дещо дивовижного результату: Не завжди має бути Agile проти методу водоспаду. Обидва методи цілком можуть доповнювати один одного. Обидва мають право на існування. Залежно від проєкту та контексту.
Але оскільки для багатьох гнучкі методи все ще залишаються незвіданою територією, вони справедливо запитують себе, як вони можуть спробувати гнучкі методи.
Не знаєте, з чого почати?
Для багатьох “гнучкість” ще є чимось новим. Вони справедливо ставлять питання: чи краще мені зробити проєкт гнучким, чи за методом водоспаду? З чого б я почав з гнучкими методами? “Гнучкою” відповіддю на це було б: почніть експерименти. Ітеративно випробовуйте різні речі.
Зазвичай гнучкі методи впроваджуються двома шляхами, які також чудово підходять для “початківців”: Kanban і ретроспективи.
Канбан і ретроспектива як класична відправна точка
Канбан використовує публічну дошку (Kanban), на якій кожен член команди робить свою поточну діяльність прозорою. Це сприяє комунікації, ефективності та, зрештою, успіху проекту. Ви можете знайти більше інформації про Kanban тут..
Основна ідея ретроспективних зустрічей полягає в тому, щоб активно рефлексувати один про одного як команда на регулярній основі. Зазвичай кожні два тижні ви сідаєте на ретроспективну зустріч і ставите питання на кшталт: “Що йде добре зараз? Що йде не так добре? І яких заходів ми можемо вжити, щоб покращити ситуацію?
Якщо ви думаєте про впровадження гнучких методів…
Якщо ви все ще шукаєте відповідну ретро-дошку, наша стаття може допомогти вам з цією темою: Найкращі ретро-дошки в порівнянні.
Джерела
Річард Х. Талер, Амос Тверскі, Даніель Канеман, Алан Шварц, Вплив короткозорості та несхильності до втрат на прийняття ризику: експериментальний тест, Щоквартальний економічний журналТом 112, випуск 2, травень 1997, стор. 647–661, https://doi.org/10.1162/003355397555226
Геррманн, А. (2007). Feature Driven Development між водоспадом та гнучкістю.
