Metodyka Waterfall

Metodyka Waterfall (model kaskadowy) to jedno z pierwszych usystematyzowanych podejść do dużych projektów software’owych. W latach 70. Winston W. Royce opisał sekwencyjne etapy pracy i od razu zaznaczył, że naiwna implementacja tego schematu jest ryzykowna. Warto czytać go dziś nie jako „stary zły waterfall”, tylko jako lekcję o planowaniu, dokumentacji i miejscu klienta w projekcie.

Początki metodyki Waterfall

W artykule „Managing the Development of Large Software Systems” (1970) Royce przedstawił m.in.:

1. Zebranie wymagań systemowych.
2. Zebranie wymagań oprogramowania.
3. Analiza wymagań.
4. Projektowanie.
5. Kodowanie.
6. Testowanie.
7. Wdrożenie i utrzymanie.

Royce pisał wprost, że wdrożenie opisane „jak na pierwszej stronie” zaprasza do porażki. Problematyczne iteracje między fazami kosztują coraz więcej, im później je wykryjemy. Cytat, który warto znać:

I believe in this concept, but the implementation described above is risky and invites failure.

• Winston W. Royce

Założenia (uproszczonego Waterfall)

• Sekwencyjność - faza kończy się, zanim zaczyna się następna.
• Koszt zmiany - cofanie się do wcześniejszych etapów jest drogie.
• Dokumentacja - spójność przez opis wymagań i projektu.

Royce proponował też ograniczone iteracje między sąsiednimi fazami. Na diagramie wygląda to mniej „kaskadowo”, a bardziej jak wczesne uczenie się:

Czerwona strzałka na jego rysunku to ważna lekcja: błąd wykryty na testach często wymaga zmiany w projekcie i w wymaganiach, nie tylko „poprawki w kodzie”.

Co Royce radził, żeby zmniejszyć ryzyko?

1. Dokładny projekt przed masowym kodowaniem - inaczej płacisz compound interest za złe założenia.
2. Kompletna dokumentacja na etapach - spójność, ale też koszt utrzymania; waterfall bywa drogi w sensie operacyjnym.
3. „Zrób dwa razy” - pilot / pierwsza wersja na część scope’u (Royce sugerował ok. 1/3 czasu projektu na taki krok). Brzmi znajomo jak krótsza pierwsza iteracja w zwinności.
4. Testowanie planowane i monitorowane - bo testy tylko na końcu to ogromne ryzyko.
5. Zaangażowanie klienta - przeglądy, wgląd w specyfikację, wczesne wersje, testy przed wdrożeniem. To nie „powiedz wymagania i zniknij na 18 miesięcy”.

Problemy, które Royce widział (i które nadal wracają)

• Późne wykrywanie błędów - test na końcu cyklu.
• Drogie iteracje - powrót do wymagań i projektu.
• Zależność od jakości specyfikacji - słabe wymagania = drogi rework.

Waterfall dziś

Uproszczony waterfall z lat 80.-90. wpłynął na PMBOK i myślenie o fazach projektu. W świecie, gdzie wymagania i rynek zmieniają się szybciej niż roczny plan, pełna kaskada rzadko jest najtańszym wyborem. Bywa akceptowalna, gdy scope i regulacje są stabilne, a koszt błędu wymaga sztywnej kontroli.

Royce’owski tekst przypomina: nawet „sztywne” podejście potrzebuje iteracji, klienta i wczesnego uczenia się. To most do zwinności i porównania z Agile vs Waterfall.

Źródło

Oryginał: Managing the development of large software systems (Royce, 1970)

Jeśli zastanawiasz się, czy w Twoim kontekście transformacja ma sens, porozmawiajmy.