Model wodospadowy jest standardowym podejściem do tworzenia oprogramowania, które istnieje od dziesięcioleci. Jednak nie jest to już najbardziej efektywny sposób budowania oprogramowania. Dzieje się tak, ponieważ model wodospadowy jest wysoce ustrukturyzowany i sekwencyjny, z niewielkim uwzględnieniem procesów iteracyjnych lub informacji zwrotnych od użytkowników. Innymi słowy, jest powolny i przestarzały.

Ale nie trzeba być ekspertem od procesów Agile czy cyklów życia rozwoju oprogramowania, aby zrozumieć, dlaczego model wodospadowy nie jest już tak dobry. Wyjaśnijmy to na kilku przykładach:

Why it’s slow

Model wodospadowy jest powolny z kilku powodów. Jest wysoce sekwencyjny, co oznacza, że każdy etap musi być zakończony, zanim rozpocznie się następny. Jest również sekwencyjny w tym sensie, że każdy etap następuje po sobie w sposób liniowy. Oznacza to, że nie ma zbyt wielu możliwości iteracji lub wpływu opinii użytkowników na proces. I z pewnością nie uwzględnia zarządzania ryzykiem, które jest ogromną częścią rozwoju oprogramowania.

Spis treści

W modelu wodospadowym wymagania nie są elastyczne. W rzeczywistości są one zapisane w kamieniu. Trudno jest wprowadzić do nich zmiany, dostosować się do nowych wymagań lub opinii użytkowników. W niektórych przypadkach cały proces może zostać zatrzymany.

Co to jest Waterfall?

Waterfall jest procesem rozwoju oprogramowania, który podąża za sekwencyjnym, hierarchicznym podejściem do zarządzania projektem. Jest to implementacja ogólnego modelu wodospadowego zarządzania projektami. Jednym z najczęstszych błędnych przekonań na temat metodyki waterfall jest to, że zakłada ona, iż praca jest wykonywana w sposób sekwencyjny. W rzeczywistości metodyka wodospadowa została początkowo wdrożona w celu zapewnienia zespołowi projektowemu osiągnięcia wysokiego stopnia przewidywalności i kontroli nad działaniami projektowymi. Dlatego też metodologia waterfall jest często określana jako “sztywne planowanie” lub “zarządzany chaos”.

Jednocześnie metodyka waterfall zapewnia również mechanizm kontroli i dostosowania działań projektowych do zmieniających się warunków projektu (np. zmieniających się planów, zakresu i kosztów). Dlatego też metodyka waterfall znana jest również jako “kontrolowany chaos” lub “zarządzana elastyczność”.

Ograniczenia Waterfalla

Model waterfall jest sekwencyjny, co oznacza, że każdy etap musi być zakończony, zanim rozpocznie się następny. Jest również sekwencyjny w tym sensie, że każdy etap następuje po innym w sposób liniowy. Oznacza to, że nie ma zbyt wielu możliwości iteracji lub wpływu informacji zwrotnych od użytkowników na proces. I z pewnością nie uwzględnia zarządzania ryzykiem, które jest ogromną częścią rozwoju oprogramowania.

Przykład: Powtarzalny proces tworzenia gry

Załóżmy, że jesteśmy w trakcie tworzenia kolejnej hitowej gry mobilnej. Jest to prosta strzelanka, w której gracz steruje statkiem kosmicznym i wysadza asteroidy w zapomnienie. Kiedy mamy już prototyp, który gracze uznają za wciągający i zabawny, jesteśmy gotowi rozpocząć budowę gry. W tym momencie zaczynamy dostrzegać ograniczenia modelu wodospadowego. Mamy spisane wszystkie wymagania – w tym rozgrywkę, grafikę, muzykę i efekty dźwiękowe. Zaczynamy więc pracę od góry modelu wodospadowego, zaczynając od projektu i rozwoju.

W tym momencie projektanci wykorzystują swoją swobodę twórczą, aby wymyślić statki kosmiczne, planety i asteroidy. Ale gdzieś po drodze zdajemy sobie sprawę, że potrzebujemy więcej asteroid, ponieważ gra jest zbyt łatwa. To powoduje kilka problemów. Po pierwsze, musimy zatrzymać proces projektowania i rozwoju i dokończyć projektowanie pozostałych grafik, muzyki i efektów dźwiękowych. Następnie musimy wrócić do projektantów i powiedzieć im, aby dodali więcej asteroid. Następnie musimy zacząć programować grę od nowa. A kiedy już skończymy, musimy wrócić do projektantów i powiedzieć im, żeby zaprojektowali resztę statku kosmicznego.

Przykład: Nieprawidłowy proces tworzenia aplikacji

Powiedzmy, że tworzymy nową aplikację, która ma pomóc ludziom znaleźć ich idealne miejsca na wakacje. Jest to bardzo szeroka aplikacja, więc będziemy musieli przeprowadzić wiele badań, aby upewnić się, że budujemy coś wartościowego.

Tym razem użyjemy procesu iteracyjnego, który będzie uwzględniał fazy badań, informacji zwrotnej i budowania. Weźmiemy również pod uwagę, że mamy do czynienia z szeroką aplikacją – nie tylko pojedynczą funkcją.

Pierwszą rzeczą, którą robimy, jest zebranie naszych wymagań. Chcemy wiedzieć, co budujemy, po co to budujemy i dla kogo. Chcemy wiedzieć, jakich informacji będzie potrzebowała aplikacja, jakie informacje będzie wyświetlała i jaką funkcjonalność będzie miała. Bierzemy wszystkie te informacje i umieszczamy je w projekcie. Następnie otrzymujemy informacje zwrotne od potencjalnych użytkowników. Analizujemy je, poprawiamy nasz projekt i testujemy go ponownie. Ten iteracyjny proces daje nam szansę uczenia się na błędach i wprowadzania ulepszeń po drodze.

The way forward

Model wodospadowy jest klasycznym podejściem do tworzenia oprogramowania, stosowanym od dziesięcioleci. Jednak nie jest to już najbardziej efektywny sposób budowania oprogramowania. Dzieje się tak dlatego, że model wodospadowy jest wysoce ustrukturyzowany i sekwencyjny, z niewielkim uwzględnieniem procesów iteracyjnych lub informacji zwrotnych od użytkowników.

Innymi słowy, jest powolny i przestarzały. Ale nie trzeba być ekspertem od procesów Agile czy cyklu życia rozwoju oprogramowania, aby zrozumieć, dlaczego model wodospadowy nie jest już tak dobry. Wyjaśnijmy to na kilku przykładach.

Model wodospadowy jest sekwencyjny, co oznacza, że każdy etap musi być zakończony, zanim rozpocznie się następny. Jest również sekwencyjny w tym sensie, że każdy etap następuje po sobie w sposób liniowy. Oznacza to, że nie ma zbyt wielu możliwości iteracji lub wpływu informacji zwrotnych od użytkowników na proces. I z pewnością nie uwzględnia zarządzania ryzykiem, które jest ogromną częścią rozwoju oprogramowania. W modelu wodospadowym wymagania nie są elastyczne. W rzeczywistości, są one zapisane w kamieniu. Trudno jest wprowadzić do nich zmiany, dostosować się do nowych wymagań lub opinii użytkowników. W niektórych przypadkach cały proces może zostać zatrzymany.

Dlatego tak ważne jest, aby upewnić się, że budujesz właściwy produkt we właściwy sposób. A najlepszym sposobem na to jest zastosowanie zwinnego procesu, który uwzględnia informacje zwrotne, iterację i zarządzanie ryzykiem.