Metodyka Waterfall, znana również jako model kaskadowy, jest jednym z pierwszych usystematyzowanych podejść do zarządzania projektami. Powstała w latach 70., w czasach, gdy potrzeba lepszego planowania dużych projektów oprogramowania stawała się coraz bardziej oczywista. Model ten, zaprezentowany przez Dr. Winstona W. Royce’a w artykule „Managing the Development of Large Software Systems” (1970), szybko zdobył popularność jako sposób na radzenie sobie z rosnącą złożonością projektów IT.
Początki metodyki Waterfall
Pierwsze wzmianki o strukturze przypominającej Waterfall można znaleźć w przełomowym artykule Dr. Winstona W. Royce’a z 1970 roku. W artykule tym Royce opisał proces zarządzania dużymi projektami oprogramowania, wskazując na potrzebę uporządkowanego podejścia, które uwzględnia sekwencyjne etapy pracy.
Oryginalna koncepcja Royce’a obejmowała następujące kroki:
- Zebranie wymagań systemowych.
- Zebranie wymagań oprogramowania.
- Analiza wymagań.
- Projektowanie.
- Kodowanie.
- Testowanie.
- Wdrożenie i utrzymanie.
Royce zauważył jednak, że model ten ma wbudowane ryzyko – problematyczne iteracje między fazami mogą prowadzić do poważnych opóźnień i zwiększenia kosztów. Opisał to słowami, które niestety, znalazły się na drugiej stronie jego artykułu. Tam, gdzie wielu ekspertów już (niestety) nie doczytało.
„I believe in this concept, but the implementation described above is risky and invites failure.”
Winstona W. Royce
Kluczowe założenia metodyki Waterfall
Waterfall jest oparty na następujących zasadach:
- Sekwencyjność etapów: Każdy etap musi zostać zakończony, zanim rozpocznie się kolejny.
- Brak możliwości powrotu: Wprowadzanie zmian w poprzednich fazach jest trudne i kosztowne.
- Silne dokumentowanie: Każdy etap powinien być szczegółowo opisany, aby zapewnić spójność projektu.
Royce wprowadził także pojęcie iteracji ograniczonych do sąsiadujących faz. Ilustrował to na wykresie:
Dzięki tej iteracyjnej strukturze zmiany są bardziej kontrolowane, a praca z dokumentacją pozwala na zminimalizowanie strat w przypadku konieczności korekt.
Cytując autora, niestety rzadko kiedy naniesienie zmian dotyka jedynie poprzedniej fazy projektu. Jak pokazuje to czerwona strzałka, bardzo często błąd znaleziony na etapie testów, wymaga zmiany w projekcie oraz dokumentacji zebranych wymagań.
Co począć? Jak żyć? Jak sprawić, aby metodyka Waterfall była mniej ryzykowna.
W opisie metodyki Waterfall, Dr. Winston W. Royce zawarł podpowiedzi, co można zrobić aby zminimalizować ryzyko – szczególnie przy tworzeniu dużych systemów informatycznych.
1. Stwórz dokładny projekt systemu przed rozpoczęciem kodowania.
Jeśli nie poświęcimy wystarczająco dużo czasu na dokładne zaprojektowanie systemu, ryzykujemy fundamentalne problemy na późniejszych etapach, co może prowadzić do kosztownych opóźnień i konieczności gruntownych zmian w kodzie.
2. Twórz kompletną dokumentacje na każdym etapie.
Royce podkreślał, że dokumentacja jest kluczowym elementem udanego projektu. Nalegał aby że każda zmiana w systemie miała odzwierciedlenie w dokumentacji, co powinno zapewniać spójność na wszystkich etapach projektu. Co niestety powoduje, że metoda Waterfall jest bardzo drogim sposobem wytwarzania oprogramowania.
3. Wykonaj zadanie dwa razy, jeśli to możliwe.
W przypadku dużych i skomplikowanych systemów warto stworzyć pierwszą wersję testową, zanim dostarczy się produkt końcowy klientowi. To podejście pozwala na wcześniejsze wykrycie problemów i udoskonalenie architektury przed wdrożeniem. Jeśli prace zaplanowane są na 30 miesięcy – pilot powinien trwać 10. Jeśli projekt zaplanowany jest na rok – pilot powinien trwać 3 miesiące. (brzmi trochę jak „zróbmy pierwszą iterację krótszą”)
4. Testowanie – zaplanuj, kontroluj i monitoruj.
Testowanie w metodzie Waterfall odbywa się dopiero na końcowym etapie projektu, co niesie ze sobą ogromne ryzyko wykrycia krytycznych błędów dopiero na końcu cyklu życia produktu. Dlatego też trzeba zrobić wszystko aby to ryzyko zmniejszyć – przez dobre planowanie, kontrolowanie i monitorowanie testów.
5. Zaangażuj klienta
Ten punkt to już chyba gdzieś widziałem, tam nazywał się jednak „cenimy współpracę z klientem
bardziej od negocjacji umów”. W 1970 Royce podkreślał, że brak stałej komunikacji z klientem prowadzi do nieporozumień i błędnych założeń, które mogą zostać wykryte dopiero na końcowym etapie projektu. Co proponował – i tu może być dopiero zaskoczenie.
Stała komunikacja i współpraca z klientem powinna obejmować:
- Możliwość przeglądania i zatwierdzania kolejnych etapów projektu, przez klienta.
- Wgląd w specyfikację systemu, przez klienta, tak aby uniknąć rozbieżności w oczekiwaniach.
- Pokazywanie klientowi wczesnych wersji systemu, aby zapewnić zgodność z jego oczekiwaniami.
- Przed wdrożeniem klient powinien mieć możliwość przetestowania systemu w warunkach rzeczywistych.
Brzmi bardziej jak „współpracujmy przez cały czas trwania projektu” niż „opowiedz o wymaganiach i do zobaczenia na koniec, za 12,18 albo 30 miesięcy”.
Problemy i wyzwania metodyki Waterfall
Chociaż Waterfall zdobył popularność, Royce w swoim artykule wskazał na kilka wyzwań:
- Opóźnione wykrywanie problemów:
Testowanie odbywa się na końcu, co sprawia, że błędy ujawnione w tej fazie mogą wymagać powrotu do wcześniejszych etapów. - Wysokie koszty iteracji:
Zmiany w projekcie mogą wymagać przeprojektowania i przeprogramowania. - Zależność od dokumentacji:
Brak szczegółowych specyfikacji może prowadzić do nieporozumień między zespołami.
Ewolucja metodyki Waterfall
Po publikacji artykułu Royce’a metodyka Waterfall została uproszczona i zyskała popularność jako standardowe podejście w zarządzaniu projektami IT. W latach 80. i 90. była szeroko stosowana w dużych projektach inżynieryjnych oraz w przemyśle oprogramowania. Waterfall wpłynął także na rozwój standardów zarządzania projektami, takich jak PMBOK (Project Management Body of Knowledge), gdzie kaskadowe podejście stało się podstawą planowania i realizacji projektów.
Znaczenie historyczne metodyki Waterfall
Waterfall zapoczątkował formalne podejście do zarządzania projektami i wyznaczył kierunek rozwoju dla wielu kolejnych metod. Lekcje z Waterfall, takie jak znaczenie dokumentacji i struktury, pozostają aktualne do dziś.
Royce przewidział wiele problemów związanych z sztywnym podejściem, proponując iteracyjność i zaangażowanie klientów jako kluczowe elementy sukcesu. Chociaż Waterfall stracił na popularności, nadal jest cennym narzędziem w zarządzaniu projektami o stałych wymaganiach.
Historia metodyki Waterfall pokazuje, że nawet najbardziej uporządkowane podejścia wymagają elastyczności i ewolucji. Royce przewidział wiele problemów związanych z sztywnym podejściem, proponując iteracyjność i zaangażowanie klientów jako kluczowe elementy sukcesu. Chociaż Waterfall stracił na popularności, nadal jest cennym narzędziem w zarządzaniu projektami o stałych wymaganiach.
Co więcej podejście to jest zdecydowanie tańsze od podejścia zwinnego – pytanie tylko czy wymagania w Twoim środowisku nie zmieniają się z biegiem czasu (ale tak na serio, serio).
Bardzo serdecznie zachęcam cię do zapoznania się z oryginalnym artykułem Dr. Royce’a – nie tylko by poznać jego historię a przede wszystkim zrozumieć jakie ryzyka dostrzegał w metodzie Waterfall oraz jakie sposoby na ich zmniejszenie proponuje.
Artykuł znajdziesz na stronie https://www.praxisframework.org/files/royce1970.pdf
Jeśli chcesz przeczytać porównanie metod zwinnych i Waterfall – znajdziesz je tutaj:
Więcej o Scrum w artykule” https://rebelsi.pl/scrum-co-to/