Waterfall

Що насправді стверджує Waterfall

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

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

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

Уточнення, про яке не згадують

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

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

П’ять фаз по черзі

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

1. Вимоги

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

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

2. Проєктування

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

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

3. Реалізація

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

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

4. Верифікація

Частини інтегрують і тестують разом, а тоді передають замовнику на приймальне тестування. Це перший момент, коли хтось бачить, як поводиться система цілком.

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

5. Супровід

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

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

V-модель — Waterfall із раннім плануванням тестування

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

V-модель бере ті самі фази й згинає лінію у літеру V. Ліве плече йде вниз через вимоги, дизайн і детальний дизайн. Праве плече піднімається назад через відповідні рівні тестування. Кожна фаза ліворуч у парі з тим рівнем тестування, який її перевірятиме.

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

Економіка за цим вибором

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

• Зміни дешеві → ітеруйте

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

• Зміни дорогі → специфікуйте

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

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

Waterfall поруч із Agile

Як це виявляється в реальній поставці

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

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

Де він вироджується

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

Коли це застосовувати

Пов’язані сторінки

• МенеджментAgileAgile — це спосіб створювати софт, який припускає, що ви в чомусь помиляєтесь, і планує дізнатися про це рано. Agile не є процесом, який «встановлюють», і не є набором зустрічей — це невелика група переконань, записаних 2001 року, на яких побудовано з десяток різних методологій. На цій сторінці ми розберемо ці переконання, усі дванадцять принципів за ними і те, що насправді змінюється в команді, яка сприймає їх серйозно.
• МенеджментPRINCE2PRINCE2 — це структурований метод управління проєктами, побудований навколо одного питання, на яке проєкт має відповідати знову й знову: чи варто це й далі фінансувати? PRINCE2 майже нічого не каже про те, як виконується робота, і дуже багато — про те, хто має право вирішувати, що вона триває. На цій сторінці ми розберемо всі сім принципів, усі сім практик і всі сім процесів — по черзі й простою мовою.
• МенеджментWork Breakdown StructureWork Breakdown Structure (WBS) — це ієрархічний розклад усього, що проєкт має створити, — і, за визначенням, нічого поза цим. WBS — це межа обсягу, намальована як дерево: якщо якоїсь роботи в ньому немає, її немає і в проєкті. На цій сторінці — правило 100%, словник WBS, контрольні рахунки, схема нумерації та питання глибини розкладу.