Забудьте Agile на хвилину, подумайте, що означає «водоспад».
Існує етап вимог, на якому кожен намагається розібратися, ЯКІ проблеми потрібно вирішити кінцевим продуктом. Люди певний час сперечаються з цього приводу, а потім усі підписуються на набір вимог. Після цього визначено сферу вашої діяльності, підписуються договори, і замовник може скинутись і чекати, коли ви придумаєте товар, який вирішує ці визначені вимоги.
Далі - одна (а може і дві) фази проектування. Дизайнери (які можуть бути, а можуть і не бути розробниками) сперечаються про те, ЯК система повинна працювати разом, щоб відповідати підписаним вимогам. Проблеми можуть виникнути, якщо вони не зовсім розуміють вимогу, що може означати, що вони повинні повернутися до замовника, потенційно повторно відкривши фазу вимог (і отримати ще один раунд відключення) або принаймні налаштувати управління змінами в дію . Часто дизайнери просто найкраще здогадуються. Вони можуть придумати логічну модель даних та безліч UML, що описують нову систему та як вона повинна працювати. Потім вони підписуються на ньому.
Тепер розробники переходять до фактичного початку кодування на основі підписаного дизайну. Проблеми можуть виникнути, якщо вони не зовсім розуміють дизайн, а це може означати, що доведеться повернутися до дизайнера, що потенційно може повторно відкрити фазу проектування (і отримати ще один раунд відключення) або принаймні налаштувати управління змінами в дію . Дизайнери можуть, в свою чергу, усвідомити, що плутанина дійсно повертається до вимог, що означає, що їм доведеться знову відкрити обговорення вимог, підписатися та подальше управління змінами. Часто програмісти (у яких настає термін) просто роблять найкращі здогадки. Вони роблять все можливе, щоб зробити функціональний код. Потім відпускають його на тестування.
Тепер наступає фаза тестування системи. Тестери тестують виходячи з їх розуміння вимог та дизайну, і реєструють те, що вони сприймають як дефекти, в системі управління відстеженням / зміною помилок, змушуючи розробників знову почати розробку, якщо вони не вважають проблему як недолік дизайну, який повертає його назад до проектування тощо. З часом системні тести проходять і підписуються.
Нарешті, замовник повертається і робить тести прийняття користувача в новій системі. Саме тут вони вирішують, чи те рішення, яке тестували тестери, розробники розробляли, а дизайнери розробляли, саме те, що вони хочуть. Якщо цього немає, можливо, вам доведеться повернутися до етапу проектування або навіть переглянути вимоги.
Ідея водоспаду полягає в тому, що важко (і дуже небажано) повертатися назад, коли фаза завершена. Різні люди, як правило, беруть участь у різних етапах, тому є багаторазові роздачі, кожна з яких створює великий ризик неправильного тлумачення та втрати інформації. Існує також значна розрив між тим, коли клієнти кажуть, що хочуть, і коли бачать, що було побудовано, за цей час реальні вимоги цілком можуть змінитися.
Agile методології зосереджені на міцному спілкуванні та співпраці між усіма зацікавленими сторонами. Принцип "Співпраця з клієнтом над переговорами контракту" означає, що вам не доведеться проходити серію підписань та передач, а натомість просто працювати разом із замовником, кожна ітерація визначає вимоги до частини головоломки. і негайно формувати тести, дизайн та робочий код - при цьому всі гравці спілкуються максимально безпосередньо (виключаючи витрати та ризики, що передаються). Замовник швидко перевіряє робочий код, виключаючи ризики затримки часу. Усі заходи відбуваються у спільному вихорі, а не в потоці вниз.
Для чудового огляду того, що намагаються зробити спритні методології, я настійно рекомендую спритний розробник програмного забезпечення Allistair Cockburn : Кооперативна гра .