Методологія розробки Waterfall: що це, як працює і чим відрізняється від Agile

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

Пише про керування в Skillbox Media. Працювала координатором проектів у Російському музеї, писала для блогу агенції CRM-маркетингу Out of Cloud.

Буває, що теоретично методологія ясна, та був справа доходить до застосування і починаються питання. На курсі «Управління проектами» викладачі Skillbox розбирають інструменти управління на реальних кейсах, щоб студенти легко та безпомилково застосовували їх у роботі.

Що ще за Waterfall?

Waterfall – модель «Водоспад», водоспадна або каскадна розробка продуктів. Вона подібно до потоку води направляє команди вирішувати завдання послідовно і строго за первісним планом. Назва з'явилася в 1970 році у статті Вінстона Уолкера Ройса, директора Lockheed Software Technology Center, а структура запозичена у діаграми Ганта.

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

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

Як працює Waterfall

Розробка при використанні каскадної моделі – це п'ять послідовно послідовних етапів.

Аналітика

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

Проектування

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

Розробка

На цьому етапі пишуть код продукту згідно з планом, макетами та вимогами. Жодного кроку вбік, все чітко по ТЗ.

Тестування

Код готовий, розпочинається тестування. Тут можуть виникнути проблеми. Наприклад, команда виявить серйозні помилки в коді і витраче багато часу, щоб їх виправити. Це головний мінус каскадної моделі розробки.

Експлуатація та підтримка

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

Як відрізнити Waterfall від гнучких методологій

Класична методологія Waterfall — це робота із заздалегідь написаного та узгодженого ТЗ. Гнучкість тут не вітається. У цьому основна відмінність водоспадної моделі від Agile.

Waterfall відрізняється від Agile та самими принципами роботи, про які ми говорили вище.

12 принципів Agile

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

Методологія розробки Waterfall: що це, як працює і чим відрізняється від Agile

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

Пише про керування в Skillbox Media. Працювала координатором проектів у Російському музеї, писала для блогу агенції CRM-маркетингу Out of Cloud.

Буває, що теоретично методологія ясна, та був справа доходить до застосування і починаються питання. На курсі «Управління проектами» викладачі Skillbox розбирають інструменти управління на реальних кейсах, щоб студенти легко та безпомилково застосовували їх у роботі.

Що ще за Waterfall?

Waterfall – модель «Водоспад», водоспадна або каскадна розробка продуктів. Вона подібно до потоку води направляє команди вирішувати завдання послідовно і строго за первісним планом. Назва з'явилася в 1970 році у статті Вінстона Уолкера Ройса, директора Lockheed Software Technology Center, а структура запозичена у діаграми Ганта.

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

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

Як працює Waterfall

Розробка при використанні каскадної моделі – це п'ять послідовно послідовних етапів.

Аналітика

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

Проектування

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

Розробка

На цьому етапі пишуть код продукту згідно з планом, макетами та вимогами. Жодного кроку вбік, все чітко по ТЗ.

Тестування

Код готовий, розпочинається тестування. Тут можуть виникнути проблеми. Наприклад, команда виявить серйозні помилки в коді і витраче багато часу, щоб їх виправити. Це головний мінус каскадної моделі розробки.

Експлуатація та підтримка

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

Як відрізнити Waterfall від гнучких методологій

Класична методологія Waterfall — це робота із заздалегідь написаного та узгодженого ТЗ. Гнучкість тут не вітається. У цьому основна відмінність водоспадної моделі від Agile.

Waterfall відрізняється від Agile та самими принципами роботи, про які ми говорили вище.

12 принципів Agile

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