Що таке методологія Waterfall: як працює водоспадна модель, де використовується, відмінність від Agile

Вода тече строго згори донизу, це закон фізики. На цьому заснована методологія розробки програмного забезпечення Waterfall: всі етапи йдуть суворо послідовно, без повернення на попередні щаблі.

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

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

Waterfall, або каскадна, «водоспадна» модель розробки ПЗ – це одна з методологій, яку застосовують при управлінні проектами.

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

Каскадна модель полягає в послідовному виконанні етапів розробки. При цьому не повернення на попередні етапи, не перескакування з етапу на етап не допускаються.

У стандартному випадку (і у підході, описаному У. Ройсом) етапів сім:

1. Формулювання вимог до завдання.
2. Проектування.
3. Реалізація. Зазвичай це безпосередньо програмування та написання коду.
4. Здійснення - об'єднання різних елементів товару в одне ціле.
5. Тестування.
6. Встановлення.
7. Підтримка.

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

Особливості водоспадної моделі розробки

Головна, на відміну інших методологій, особливість Waterfall — у ній відсутня якась гнучкість. У тих же Agile або Scrum етапи можуть йти паралельно, можливі майже будь-які зміни та повернення на попередні щаблі. Наприклад, встановлюватись і тестуватися можуть частини продукту задовго до того, як почне вимальовуватись загальна картина. ПО може «допилювати» і перероблятися по ходу.

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

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

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

Як працює Waterfall

Розкажу докладно, як улаштовані етапи роботи в каскадній моделі розробки, на прикладі комп'ютерної гри.

1. Визначення вимог. Технічних (по суті — складання ТЗ для програмістів), фінансових (визначення бюджету) тимчасових (термін реалізації проекту) тощо.Грубо кажучи, це має бути така гра, герой бігає і стріляє у ворогів, бюджет мільйон доларів, термін 24 місяці. Тільки докладніше.
2. Проектування. На цьому етапі всі вимоги упаковуються у документацію. Для програмістів це буде логіка гри, дизайн героїв та багато іншого. Проектування — один із найтриваліших етапів розробки за каскадною моделлю. Про ціну помилки ми вже говорили.
3. Реалізація. Власне, написання коду документації, розробленої на попередніх етапах.
4. Втілення - З'єднання частин програми в єдине ціле.
5. Тестування: перевірка готової гри щодо помилок. Правильніше було б назвати цей етап пусконалагоджувальним: всі виявлені баги усуваються або тестувальниками, або програмістами відділу тестування. Ніхто нічого не відправляє на доопрацювання: пам'ятаємо, що повернення на попередні етапи не передбачено.
6. Встановлення. У широкому сенсі — випуск товару ринку та його інсталяція на пристрої кінцевих користувачів (якщо мова про коробочної версії) чи доступом до хмарі (якщо мова про надання ПО по SaaS-модели).
7. Технічна підтримка. Супровід продукту в експлуатації: випуск оновлень, усунення помилок тощо.

Переваги та недоліки водоспадної моделі

Усі біди та недоліки каскадної методології випливають із того, що етапи розробки йдуть послідовно. Почну з того, за що підхід критикують та застосовують обмежено.

• Найголовніший мінус – неможливість нічого змінити, коли процес розробки запущено. Якщо замовник на півдорозі схаменувся і вирішив додати до ПЗ новий функціонал, доведеться все відновити. Гнучкість нуль.
• Це довго та дорого, якщо порівнювати з гнучкими методологіями.
• Один продукт – один проект. Розробки не можна розповсюдити на інше програмне забезпечення.Жодної універсальності або можливість використовувати проект як шаблон. Звідси…
• ...Довго і дорого. Простий приклад: за одним проектом будинку можна збудувати будь-яку кількість будинків. А тут так не вийде: одна програма — один проект, тож дорожче та довше.
• Потрібно багато персоналу: розробники, проектувальники, аналітики, програмісти, тестувальники тощо.
• Критична залежність успіху всього проекту від якості проектування та розробки документації.
• Тестування проводиться наприкінці. Якщо виявлено фатальні помилки, переробляється все від початку.
• Зайва бюрократизація процесу розробки. Часто на перший план, замість якості ПЗ та задоволеності замовника, виходять такі параметри, як трудовитрати, трудомісткість та інші речі, що не мають відношення до якості продукту.
• Немає місця для імпровізації. Якщо у когось із виконавців виникла ідея щодо покращення продукту, реалізувати її не вдасться.

Проте підхід має сильні сторони:

• Команда та окремі фахівці завжди знають, що робити. Вся робота детально та покроково розписана.
• Завжди відомі терміни та бюджет проекту.
• Прозорість роботи та повне розуміння з боку замовника.
• Взаємозамінність спеціалістів. Завдяки докладній документації можна реалізувати проект силами будь-якої компетентної команди.

Відмінність методології Waterfall від Agile

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

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

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

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

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

Waterfall, Agile, Scrumban - плюси та мінуси, або Що не так з еталонними підходами до розробки

Сьогодні в методах розробки програмного забезпечення винятки не підтверджують, а швидше замінюють правила. Чистокровний Аgile вдень з вогнем не знайдеш у жодній компанії. Натомість розмножуються різні гібридні методології. Деякі проджекти задаються зовсім крамольним питанням: навіщо потрібні еталонні системи, якщо на практиці всі працюють по-різному?

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

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

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

Критикувати класику – це класика. Waterfall

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

Переваги Waterfall

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

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

По-друге, водоспад підштовхує ретельно оцінювати та опрацьовувати ризики прямо "на березі".Можна сказати, що у Waterfall девіз чеховської людини у футлярі: як би чого не вийшло. Найчастіше держкомпанії та консервативні організації визнають лише таку методологію, а самі слова "Agile", "Scrum" або "Kanban" для багатьох під найсуворішою забороною. Тож хочете перемагати у тендерах та отримувати держконтракти — готуйтеся до «стрибків у водоспад».

Недоліки Waterfall

Головна претензія більшості фахівців до водоспадної моделі – закладена у її дизайн. неприйняття змін та коректив "на льоту". Робота з Waterfall означає нудне проектування товстого ТЗ, яке потім усі проклинають, Розтягнута на місяці, а іноді і роки (буває і таке) реалізація. Етапи роботи виконуються по черзі — їх не можна міняти місцями. Якщо команда слідує Waterfall, то вона не може повернутися назад і внести коригування на ходу - їй доведеться миритися з допущеними помилками до кінця шостої фази і лише потім планувати виправлення. UPD. У коментарях справедливо зауважують, що у Waterfall все ж таки є менеджмент змін до вимог, але застосовується він вкрай рідко.

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

Agile – коли одного маніфесту мало

Не дивно, що так багато розробників воліють різні Agile-методології, але мають свої фічі і баги.

Переваги Agile-методологій

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

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

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

Scrum також вводить додаткову деталізацію за ролямиякі грають члени команди розробки в рамках проекту. Ця методологія регулює комунікаціїНаприклад, рекомендує проводити Daily Scrums. Загалом, у Scrum трохи менше свободи, ніж у Kanban, зате більше організації та порядку. Однак усім плюсам відповідають свої мінуси.

Недоліки Agile загалом

Особливість Agile-методологій у тому, що з ними вже не можна сховатися у футлярі з формально зафіксованих вимог. Як правило, немає чіткого ТЗ та оцінки ризиків на старті: потрібно швидше «вплутатися в бійку», і тільки потім прояснюються перспективи проекту

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

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

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

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

Грає злий жарт і подрібнення процесу на короткі ітерації. Буває, що керівники використовують термінологію Scrum, але насправді просто змушують команди брати на себе невиправдані обсяги завдань у стислий термін. Розробка стає справжнім бігом у колесі, а співробітники вигоряють.

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

Інша слабка сторона Agile відсутність адекватних способів оцінки результативності окремих спеціалістів. У результаті внесок кожного розробника або не вимірюється, або розраховується, виходячи з суб'єктивних і відірваних від дійсності KPI. Це знижує мотивацію виконавців та якість роботи.

Ще один істотний мінус - у найбільш поширених Agile-підходах, наприклад, Scrum і Kanban, немає високорівневого управління вимогами. Замовники чи інвестори постійно дають фідбек, корегують побажання до ПЗ. Але у масштабних проектах такі запити можуть висувати одразу кілька зацікавлених сторін. Крім того, менеджерам часто буває складно розбити високорівневі вимоги до розмірів, що дають змогу адекватно оцінити трудовитрати. У таких умовах необхідні сполучна ланка та процеси, які дозволять оцінити та «подружити» вимоги між собою, відсіяти зайве, вибудувати комунікацію з усіма ЛПР-ами.

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

Недоліки Kanban

Простота змін — це, звичайно, добре, але до певної межі. Іноді Kanban все ж таки не вистачає обмежувачів. Скажімо, замовник ПЗ тільки заїкнувся, що йому потрібна та чи інша додаткова функціональність, і на дошці миттєво з'являється нова картка.Завдання в роботі, і ось уже фахівці б'ються над тим, як зобразити кам'яну квітку. А вже за тиждень з'ясовується, що замовник передумав.

Згадується давній випадок із практики. Якось розробляли мобільний додаток — криптовалютний гаманець. Замовник мав кілька ключових вимог до функціональності: чат для користувачів, система обробки ERC20-транзакцій.

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

Крім фальстартів, Kanban поганий тим, що розсіює увагу і підштовхує розробників перескакувати між завданнями.

Недоліки Scrum

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

На наш досвід за перші кілька місяців проекту вкрай рідко вдається розкрити і продемонструвати бізнес-користування окремих фіч. Тож чому б не скоригувати плани в ході спринту і трохи не розвантажити фахівців, якщо на початку виник форс-мажор? Але ні: методологія не велить.

Багато scrum-команди зі світу замовленої розробки грішать частою ротацією складів: далеко не всі учасники проходять проект «від і до»Отже, розробники не бачать результатів і роблять висновків. Часом аналізувати помилки, що розкрилися на пізніх етапах проекту, просто нема кому, оскільки винуватці вже працюють над чимось іншим.

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

Не подобається багатьом і те, що Scrum виключає пряму участь зовнішніх стейкхолдерів у спринтах. У результаті зворотний зв'язок запізнюється, виникають складнощі з підготовкою Definition of Done (критерії приймання) для фіч, які розробляються під час ітерацій.

Викликають проблеми та обмеження рольової моделі Scrum. Власник продукту, скрам-майстер та розробник – ось і всі доступні ролі. Абстрактні «розробники» зливаються в єдину масу і методологічно не прив'язані до завдань чи областей. Це може викликати плутанину, коли незрозумілі ступінь залучення та сфера відповідальності конкретного фахівця.

Закидають Scrum і за перебір із нарадами та настановними заходами. Стендапи, спринт-рев'ю, сторипоінти та інші активності можуть забирати стільки часу, що безпосередньо розробкою займатися ніколи.

Направо підеш… або Як вибрати відповідну базову методологію

Це питання із серії «у чому сенс життя?», адже однозначної відповіді на нього немає. Але, орієнтуючись на плюси та мінуси різних методологій, можна виділити деякі базові передумови застосування того чи іншого підходу.

Передумови застосування WaterFall

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

Друга передумова - низька динамічність і консервативність ринку, для якого створюється продуктНаглядний приклад — бухгалтерія з її обліковими системами, такими ж класичними, як симфонічна музика або костюм-трійка. , на старті прорахувати всі ризики та чітко слідувати ТЗ.

Передумови застосування Agile

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

Галузевий фактор є актуальним для всіх гнучких підходів, але як вибрати між Kanban і Scrum?

Коли підходить Kanban

Найкраще він показує себе для невеликих команд та бюджетівРозбивати на scrum-команди «півтора землекопа» - заплутаєте комунікацію і процеси.

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

Коли підходить Scrum

Застосування Scrum виправдане, якщо команда зростає, а окремий проект перетворюється на повноцінний продукт, який є на ринку довгий час і приносить бізнесу відчутний дохід. Продукт розвивається, а користувачі постійно дають зворотний зв'язок, який потребує обробки.

Припустимо, у служби підтримки банківського додатка постійно запитують, коли з'явиться підтримка нової системи переказів. Стає зрозуміло, що така фіча назріла. Можна сміливо планувати її доставку користувачам, призначати дату релізу, робити з цього PR-подія. У таких ситуаціях Scrum допомагає впоратися зі зростаючим обсягом змін на основі фідбеку. За допомогою спринтів забезпечується достатній рівень планування, щоб не вистачати за все поспіль.

Scrumban: середній шлях

Деякі управлінці намагаються згладити шорсткість традиційних методологій за допомогою гібридних моделей. Ця тенденція почалася з мікшування Waterfall та Agile, але потім «селекціонери» наважилися на схрещування гнучких підходів. У нас в Magnus Tech досить високу ефективність показала система з назвою Scrumban.

Суть методу полягає у скрамівській роботі спринтами, у ході яких використовується Kanban-дошка. На ній фіксуються та пріоритизуються заплановані на ітерацію завдання.

Таким чином, свобода та гнучкість Kanban частково врівноважується правилами Scrum. Розробники не розпорошуються між тасками і не беруться за все поспіль. При цьому в межах спринту можна гнучко розподіляти завдання, коригувати завантаження щодо ситуації. Те, що нескладно змінити відразу, відразу йде в графу «відкрито» на Kanban-дошці і береться в реалізацію. Більш трудомісткі завдання відлітають до наступного спринту.Є також традиційні стендапи, спринт-рев'ю та інші настановні зустрічі, які допомагають краще координувати дії та дають командоутворюючий ефект.

Звичайно, тут свої витрати, адже, поряд з перевагами, Scrumban успадкував і слабкі сторони батьків. Оскільки «фривольний» Kanban не переймаються такими деталями, як розміри команд, участь стейкхолдерів у процесі розробки та розподіл ролей, то тут слово дається Scrum з усіма вищезгаданими недоліками.

До того ж цей гібридний підхід вкрай чутливий до будь-яких прогалин у плануванні. Отже, PM та аналітикам доводиться докладати чимало зусиль щодо підтримки актуальної roadmap проекту. Тільки так реально відстежити, коли пора братися за ту чи іншу функціональність відповідно до заданих стейкхолерами пріоритетами.

Про всяк випадок підкреслю, що «укладати» функціональності в roadmap слід з обережністю, враховуючи фактичну продуктивність команд, людський фактор (лікарняні, відпустки тощо). Якщо звернутися до схеми вище, то видно, що іноді важлива функція передається з дизайну в розробку в межах одного спринту. Але сподіватися, що так буде завжди наївно, адже обставини можуть складатися по-різному.

Коли підходить Scrumban

Подібний гібридний підхід «вистрілює», якщо у програмного забезпечення ще трохи користувачів, але попереду великий обсяг робіт з функціональності. Іншими словами, між MVP та повноцінним мажорним релізом на стадії активної розробки об'ємного проекту. На початку шляху в методології буде переважати Kanban, а спринти можуть мати спрощений вигляд. Але в міру розвитку продукту фокус зміститься у бік Scrum, оскільки зворотного зв'язку побільшає, а горизонт планування розшириться. Відповідно, гнучкість розробки дещо зменшиться, зате з'являться гарантії своєчасної доставки фіч користувачам.