Czym jest model Waterfall?

Na początku był Chaos. Z Chaosu wyłonili się.. twórcy metod prowadzenia projektów. Mity mówią, że to byli ich doświadczeni kierownicy. A jak wygląda prawda? Postaram się przedstawić kilka faktów.

Czym są modele kaskadowe i zwinne?

Zarówno model Waterfall, jak i Agile, to podejścia (bądź filozofie) stosowane w projektach. Obie metody wywodzą się z dziedziny tworzenia oprogramowania.

Dużo osób preferuje wymyślenie sobie jakiegoś modelu, żeby łatwiej było określić nad sposób wykonania zadania. To trochę jak np. z projektem „Figura na plażę 2021”. Lubimy dzielić takie wyzwania na fazy. Np. faza pierwsza: -2kg, faza druga: -6kg itp. Robimy plan jak to osiągnąć i się go trzymamy. Przed przejściem do kolejnego etapu, czekamy na zakończenie poprzedniego. Nie możemy zacząć fazy drugiej, bez osiągnięcia „milestones” (z ang. kamienie milowe) fazy pierwszej. Tak w uproszczeniu wygląda Waterfall. Ale możemy też podejść bardziej „zwinnie” i np. ustalić sobie cel na najbliższe 2 tygodnie, codziennie śledzić postęp, zbierać feedback – bardziej od siebie niż innych – i zmieniać nasze cele zgodnie z tym, jak reaguje nasz organizm i jak się czujemy. Mieć bardziej długoterminową wizję, niż dobrze zdefiniowany plan, realizowany krok po kroku. Reagować na zmiany – w tym wypadku na reakcje naszego organizmu i samopoczucie. I to możemy nazwać Agile.

Mam nadzieję, że w miarę zrozumiale to tłumaczę. Zapraszam do dalszej części artykułu, gdzie trochę bardziej przeanalizujemy model Waterfall. A w kolejnej części również Agile.

Charakterystyka Waterfall

Co to jest w ogóle ten model kaskadowy?

Jak sugeruje nazwa, model kaskadowy wyróżnia kilka, przeważnie 5, następujących po sobie faz. Wyobraźmy sobie wodę płynącą po formacjach skalnych, która przesuwa się w dół do kolejnych „etapów”. Nie może zrobić fikołka. Nie może zawrócić. Płynie zgodnie z prądem. Kamień po kamieniu. Wcześniejszy etap musi zostać zakończony, żeby nastąpił kolejny. Jak na obrazku poniżej.

I właśnie tak można obrazowo przedstawić model kaskadowy. Jego inspiracją były fabryki oraz projekty budowlane. I tam na pewno świetnie się sprawdzały! W przypadku projektów budowlanych ciężko w ogóle mówić o innym podejściu. Bo jak postawić ściany bez wcześniej wylanych fundamentów? No.. średnio to widzę.

Jak to wygląda na przykładzie?

Jak już wspominałam, model Waterfall składa się z 5 następujących po sobie faz, które następują kolejno po sobie. Pracę nad projektem zaczynamy od zebrania wymagań. Czyli w przypadku domu, zaczynamy zastanawiać się: Jakie mamy fundusze? Lepiej kupić gotowy czy pakujemy się w budowę? Czego potrzebujemy do zbudowania naszego gniazdka?

Następnie specjaliści planują wykonanie zadań – czyli w tym wypadku idziemy do architekta po plany. Oraz szukamy ekipy, która wie więcej od nas o budowie domu. I jest w stanie zaplanować co trzeba zrobić, by produkt, w tym wypadku dom, powstał.

W kolejnych etapach budowlańcy wykonują pracę. Potem my przychodzimy na „odbiór”, i sprawdzamy. Czy wszystko ok, czy działa, a oni próbują nam wmówić, że „Panie Kierowniku, będzie Pan zadowolony – wszystko na pewno działa”.

I potem przejmujemy nasze marzenie. I zdajemy sobie sprawę, że utrzymanie domu to nie taka prosta spraw, jak się wcześniej wydawało 🙂 Jak to często bywa – wyobrażenie, gdy zamienia się w rzeczywistość, już nie okazuje się takie.. przyjemne.

W przypadku procesu wytwarzania oprogramowania..

..wygląda to bardzo podobnie 😉

Najpierw mamy fazę analizy wymagań, gdzie analitycy biznesowi wraz klientem zdefiniują potrzeby klienta oraz jego oczekiwania. Jakiekolwiek zmiany będą muszą być formalnie zgłaszane (w postaci tzw. change requests), ale często wiążą się one z dodatkowymi kosztami.

Wracając do tematu, po fazie zbierania i opracowywania wymagań, następuje etap projektowania. Architekci projektują wtedy rozwiązanie opierając się na rezultatach analizy wymagań.

Kolejny etap to implementacja, gdzie programiści, graficy i inne role będą dbać o poszczególne elementy systemu. Każda z funkcji będzie dbać o wycinek projektu, nie zawsze mając pojęcie na temat „całego obrazu”. Częścią tej fazy będzie również integracja, podczas której okaże się czy zebrane wymagania i projekt systemu zostały zaplanowane prawidłowo.

Jeśli nie, proces implementacji się wydłuży, a przejście do etapu testowania będzie znacznie opóźnione. Co oczywiście nie poskutkuje wydłużeniem się czasu projektu, ale raczej skróceniem czasu testowania. I na tym etapie mogą zostać znalezione błędy zarówno w kodzie, jak i w wymaganiach. Prowadzi to do podróży w górę kaskady, tak, aby te wymagania poprawić, określić ich wpływ, wprowadzić zmiany w architekturze, ponownie zaimplementować czy poprawić niektóre funkcjonalności i znowu wykonać testy. Tak, aby można było oddać klientowi produkt bez błędów i przejść do fazy utrzymania.

Wady modelu kaskadowego

Jak widać na powyższym przykładzie model Waterfall ma kilka wad, mianowicie:

  • wymagania, które pozostają stałe i nie zawsze są dokładnie określone przez klienta na początku projektu.

Nie ukrywajmy, że nawet my w procesie odchudzania zmieniamy nasze plany, zestawy ćwiczeń, a przede wszystkim – cel ulega przedefiniowaniu. Wraz z upływającym czasem i podejmowanymi działaniami często docieramy do punktu, gdzie początkowe wymagania okazują się totalną pomyłką.

  • koszt wprowadzania zmian rośnie w miarę przechodzenia do kolejnych faz,

W fazie projektowania są jeszcze stosunkowo niskie. Ale w przypadku testowania czy utrzymania? Myślę, że znane są sytuacje, gdy klient otrzymuje gotowy produkt, a po jakimś czasie uruchamiany jest nowy projekt, żeby ten produkt udoskonalić. Możemy sobie wyobrazić, że całkiem sporo to kosztuje 🙂

  • skrócony czas pracy testerów,

Na czym najłatwiej oszczędzić? Dokładnie.

Plus „jak nie przetestujemy to może nie znajdziemy błędów”, hm?

  • niespełnione oczekiwania klientów,

Ten obrazek mówi wszystko 🙂

  • późna integracja systemu,

Co prowadzi do późnego wykrywania błędów i.. zwiększonych kosztów, bo musimy wrócić do poprzednich faz, wprowadzić zmiany i ponownie je zaimplementować.

  • trudności w zapewnieniu produktu o dobrej jakości,

Trudno zadbać o jakość, jeśli zajmujemy się głównie gaszeniem pożarów.

Podsumowanie modelu Waterfall

  • jest to model etapowy,
  • kolejna z faz następuje po zakończeniu wcześniejszej,
  • spędzamy w nim dużo czasu na planowaniu,
  • rezultat końcowy próbuje się dokładnie zdefiniować już na początku, w taki sposób, by uniknąć zmian,
  • ewentualne zmiany są kosztowne i wymagają powrotu do poprzednich faz.

Czy Waterfall się do czegokolwiek nadaje?

I teraz padnie ulubiona odpowiedź.. wszystkich. TO ZALEŻY. A od czego?

Od naszego projektu. Jeżeli projekt spełnia wymienione niżej kryteria, to model kaskadowy jak najbardziej jest wskazany.

A te warunki to:

  • zakres projektu i wymagania się nie zmieniają,
  • zespół bardzo dobrze zna technologię,
  • zespół rozumie wszystkie wymagania i poprawnie oszacował zakres prac do wykonania,
  • brak zewnętrznych czynników, które mogą wprowadzać zmiany planów.

No trochę ciężko tutaj o taki projekt, zwłaszcza w branży IT czy finansów, gdzie – mam wrażenie – nie ma nic stałego. Musimy ciągle się rozwijać. Non stop działać i doskonalić zarówno technologię, jak i nasze umiejętności. Ale w przypadku np. produkcji samochodu, czy statku kosmicznego – takie podejście może się sprawdzić. Albo wprowadzania jasno określonych regulacji, które musi spełnić nasza organizacja, żeby działać zgodnie z przepisami.

Chociaż obecnie chyba Elon Musk próbuje zbudować rakietę SpaceX wykorzystując metody zwinne i.. w lutym chyba coś wybuchło 🙂 Więc może do budowania tego typu „pojazdów” wskazany jest model kaskadowy.

Słowem podsumowania

Model Waterfall jest przejrzysty i prosty. Może dlatego zyskał taką popularność. Bardzo często chcemy, żeby nasze życie było tak ustrukturyzowane i dzięki temu – może łatwiejsze. Tylko tworząc jakiś produkt, albo przeprowadzając projekt bardzo ciężko jest już na samym początku dokładnie zdefiniować wymagania. Zaplanować przebieg. Trzymać się planu. Być opornym na wszelkie zmiany.

Bo koniec końców, chodzi o naszych klientów? O ich dobro, a nie projekt, który „na papierze” zostanie zakończony sukcesem. Bo.. czy on będzie miał jakąkolwiek wartość?

Zostawiam Was z tym pytaniem 🙂

Cieszę się, że chcecie być Bliżej Projektów!

Do usłyszenia 🙂

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *