W 1970 roku Winston W. Royce opublikował artykuł „Managing the Development of Large Software Systems”, w którym opisał proces tworzenia oprogramowania dla NASA. Miał w nim diagram z siedmioma fazami ułożonymi jedna pod drugą, jak stopnie schodów. Nie nazwał tego „waterfall”, nie powiedział też, że to dobry pomysł. Wręcz przeciwnie – ostrzegał, że to ryzykowne. Ale nazwa się przyjęła, diagram wędrował między korporacjami, a po 50 latach ten model wciąż budzi emocje, jak mało która metodologia w zarządzaniu projektami IT.
\n\n
Siedem etapów, które nie cofają wody
\n\n
Model kaskadowy to sekwencja kroków, które następują po sobie jak ogniwa w łańcuchu: wymagania, analiza, projektowanie, implementacja, testowanie, wdrożenie, utrzymanie. Każdy etap kończy się formalnym zatwierdzeniem dokumentacji i dopiero wtedy rozpoczyna się kolejny. W teorii brzmi logicznie, w praktyce przypomina trochę budowę domu, w którym nie możesz zmienić zdania o układzie pokoi, gdy fundament już stoi.
\n\n
Fred Brooks w „The Mythical Man-Month” z 1975 roku opisywał tę sekwencyjność jako naturalną konsekwencję mentalności inżynieryjnej lat 60. Jeśli budujesz most, najpierw projektujesz go w całości, potemlewiesz beton. Problem w tym, że oprogramowanie nie jest mostem. Można je zmieniać do ostatniej chwili. A właściwie – trzeba je zmieniać do ostatniej chwili, bo dopiero w trakcie użytkowania wychodzą na jaw rzeczywiste potrzeby użytkowników.
\n\n
Dlaczego waterfall nadal żyje
\n\n
W 2008 roku jedna z agencji rządowych w Wielkiej Brytanii wdrażała system IT według klasycznego waterfallu. 18 miesięcy analizy wymagań, kolejne 12 miesięcy projektowania, 24 miesiące programowania. Kiedy system wszedł na produkcję, okazało się, że przepisy prawne, które miał obsługiwać, zmieniły się trzy razy w międzyczasie. Projekt kosztował podatników 220 milionów funtów. Historia jak wiele innych, ale pokazuje, dlaczego waterfall wciąż funkcjonuje w określonych środowiskach.
\n\n
Tam gdzie wymagania są stabilne, regulacje szczegółowo opisane, a ryzyko zmiany kosztowne – waterfall ma sens. Systemy bankowe obsługujące płatności międzynarodowe, oprogramowanie dla urządzeń medycznych certyfikowanych przez FDA, czy projekty infrastrukturalne finansowane z budżetu publicznego. W tych kontekstach każda zmiana wymaga ponownej walidacji, audytu, dokumentacji na 300 stron. Czasami lepiej zaplanować wszystko z góry, niż zmieniać w biegu.
\n\n
Co się dzieje, gdy kaskada się psuje
\n\n
Najczęstszy problem to efekt, który Brooks nazwał „adding manpower to a late project makes it later”. Projekt opóźnia się w fazie implementacji, ktoś decyduje, że dołoży ludzi, komunikacja robi się coraz bardziej skomplikowana, i paradoksalnie wszystko zwalnia jeszcze bardziej. W waterfallu nie ma mechanizmu wczesnego ostrzegania – dopóki nie dotrzesz do fazy testowania, nie wiesz naprawdę, czy system działa.
\n\n
Drugi problem to dokumentacja jako artefakt sam w sobie. W projektach waterfallowych powstają dokumenty specyfikacji wymagań na 150 stron, które nikt nigdy nie przeczyta w całości. Komitet sterujący, opisany w PRINCE2, zatwierdza kolejne etapy na podstawie prezentacji PowerPoint, a nie faktycznego użycia systemu. I nagle okazuje się, że wszyscy zgodzili się na coś, czego nikt tak naprawdę nie rozumiał.
\n\n
Czy da się z tego uciec
\n\n
Wiele organizacji próbowało hybryd. Waterfall w dużej skali, agile w zespołach deweloperskich. Albo ogólna rama projektu w PMBOK, ale iteracje wewnątrz każdej fazy. Czasami to działa, częściej kończy się na „agile theatre” – zespoły robią sprinty, ale i tak czekają 6 miesięcy na zgodę zarządu na wdrożenie czegokolwiek.
\n\n
Royce w swoim oryginalnym artykule proponował coś, o czym rzadko się mówi: iteracyjne podejście z dwoma pełnymi przebiegami przez cały proces. Pierwszy to prototyp do wyrzucenia, drugi to właściwy system. Brzmi jak wczesna wersja Scruma, prawda? Ale historia zapamiętała tylko ten jeden diagram, bo był prosty, czytelny i dał się łatwo wkleić do slajdów.
\n\n
Źródła
\n
- \n
- Royce W.W., “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, 1970.
- Brooks F.P., “The Mythical Man-Month: Essays on Software Engineering”, Addison-Wesley, 1975.
- PMBOK Guide, Project Management Institute.
\n
\n
\n
Zdjęcie: Andrea Piacquadio / Pexels
