WATERFALL

Metodyka Waterfall stanowi aktualnie najpopularniejsze podejście do zarządzania projektami praktykowane we współczesnych organizacjach. Jest to klasyczny system, oparty na metodzie kaskadowej dekompozycji projektu na poszczególne fazy projektowe, następujące jedna po drugiej. Jeśli którakolwiek z faz nie przynosi satysfakcjonującego rezultatu, realizowane są kolejne iteracje kaskady aż do momentu uzyskania założonego celu. Metodyka Waterfall sprawdza się w wielu dziedzinach gospodarki - budownictwie, produkcji, usługach charakteryzujących się powtarzalnością i wszystkich innych procesach produkcji dóbr materialnych. Sednem metodologii Waterfall jest szczegółowy plan, zakładający sekwencyjną realizację zadań prowadzącą do finalnego rozwiązania. Waterfall opiera się na rygorystycznym przestrzeganiu terminów i prowadzeniu dokumentacji podejmowanych działań. Realizacja zadań następuje krok po kroku, nie pozostawiając żadnej przestrzeni dla odstępstw. Jeśli jednak jeden krok ulegnie wstrzymaniu, dodatkowe koszty i czas realizacji projektu grożą ostatecznym fiaskiem całej operacji. Waterfall skonstruowany jest według prostej zależności - krok A musi zostać ukończony zanim krok B zostanie zainicjowany. Taki model pracy sprawdza się zwłaszcza w strukturach kaskadowych, w gałęziach przemysłu, gdzie nie ma dużej konkurencji pomiędzy przedsiębiorstwami, na rynkach ustabilizowanych czy też w ramach procesów poddanych regulacjom i standaryzacji.



HISTORIA WATERFALL

Sięgająca swoimi korzeniami do gałęzi przemysłu opartych na realizacji zadań krok po kroku (np. produkcja przemysłowa czy budownictwo) metodyka Waterfall powstała na potrzeby rozwoju oprogramowania w latach pięćdziesiątych XX wieku. Ramy tego systemu zostały opisane przez Dr. Winstona Royce’a w rozprawie pt. „Zarządzanie procesem tworzenia dużych systemów oprogramowania”. Tą zastępcza wówczas metodologię Royce określił jako „ryzykowną i sprowadzającą kłopoty”. Zakładano wtedy, że sprawdzi się ona wyłącznie w obszarze tworzenia oprogramowania, a i to dopiero po wielu testach i przy dobrej znajomo- ści potrzeb klientów.

MODEL WATERFALL

We współczesnym środowisku pracy, zespoły IT nierzadko są zmuszone stosować tą metodologię Waterfall, aby dostosować się do całej organizacji. W modelu tym, który jest dedykowany projektom informatycznym, twórcy oprogramowania podążają ścieżką składającą się z 8 kroków. Wraz z końcem jednej z faz, otwiera się możliwość zainicjowanie kolejnej.

8 Faz Modelu Waterfall:

  • Faza koncepcyjna.
  • Rozpoczęcie.
  • Analiza.
  • Projektowanie.
  • Budowa.
  • Testy.
  • Produkcja/wdrożenie.
  • Obsługa.

KIEDY KORZYSTAĆ Z WATERFALL

Metodologia Waterfall najlepiej służy realizacji projektów o jasno określonych ramach i sprecyzowanej wizji produktu finalnego. Sprawdza się jedynie, gdy klienci nie wysuwają oczekiwań, co do zmian zakresu projektu po rozpoczęciu prac nad nim oraz gdy precyzja w projekcie i zgodność ze szczegółowym planem są istotniejsze niż szybkość jego wykonania. Kod zostaje dostarczony klientowi, gdy zostanie uznany za kompletny, a nie natychmiast po jego wygenerowaniu. W przypadku pozostałych obszarów organizacji, Waterfall stosowany jest przy tradycyjnym zarządzaniu projektami, które realizowane są następujących po sobie krokach, w ściśle zdefiniowanej i niezmiennej kolejności.

ZALETY I WADY WATERFALL

ZALETY

Wyjątkowa szczegółowość

Planowanie, planowanie i jeszcze raz planowanie – oto zaleta numer jeden Waterfall. Drobiazgowe przygotowania przekładają się na kompleksowość planu projektu, co - nawiązując do założeń Royce’a - w przypadku tworzenia oprogramowania powinno opierać się na dobrej znajomości potrzeb klientów. Stosowanie metodologii Waterfall wymaga gromadzenia szczegółowej dokumentacji, co z korzyścią przekłada się na realizację projektów w przyszłości.

Rezultaty zgodne z oczekiwaniami

Na żadnym etapie klienci nie pozostają w niepewno- ści, co do kształtu oprogramowania, które otrzymają w wyniku realizacji projektu przy zastosowaniu metodologii Waterfall. Rozmiar przedsięwzięcia, jego koszty oraz harmonogram realizacji są precyzyjnie nakreślone i przedstawione klientowi przed przystąpieniem do tworzenia kodu. Waterfall nie znosi odstępstw od ustalonego planu, stąd realizacja projektu nie ulega modyfikacjom w stosunku do pierwotnych założeń. Jeżeli klient życzy sobie realizacji projektu X, zespół zadaniowy zrealizuje projekt X, a nie projekt zmodyfikowany do wersji Y.

Nie wybija z rytmu

Prowadzenie dokumentacji oraz przejrzyste oczekiwania pozwalają wykluczyć nieporozumienia. Jeżeli zespół zadaniowy napotyka trudności, przekazanie projektu innemu zespołowi przebiega gładko i bez zakłóceń. Sprecyzowany plan oraz dokumentacja pozwala również na płynne wdrożenie w prace nowego członka zespołu zadaniowego, bez zachwiania ram czasowych przewidzianych dla projektu.

WADY

Brak możliwości powrotu do wcześniejszej fazy

W ramach metodologii Waterfall, projekty realizowane są zgodnie ze ściśle określonym planem i odstępstwo od pierwotnego harmonogramu jest utrudnione, a wręcz niemożliwe. Jeżeli wstępne wymogi okażą się w jakiś sposób wadliwe lub oczekiwania klienta ulegną zmianie w trakcie realizacji jednej z faz projektu, zespół musi rozpocząć pracę od nowa, począwszy od tworzenia nowego kodu. W takich przypadkach, projekty często upadają i trzeba zaczynać je na nowo, co wpływa na wzrost kosztów i czasochłonność przedsięwzięcia.

Możliwość przeprowadzenia testów dopiero po ukończeniu projektu

Testy kodu w projekcie realizowanym z zastosowaniem Waterfall są ukończone dopiero po jego ostatecznym ukończeniu. Po stworzeniu kodu, przedkłada się go do końcowego testu jakości, która to faza z samej istoty pochłania dużo czasu, potrzebnego wyczyszczenie zidentyfikowanych, nieuniknionych defektów.

Brak możliwości modyfikacji zgodnie ze zmianą oczekiwań

Oczekiwania klientów zwykle ewoluują w trakcie prac nad projektem. Metodologia Waterfall nie jest w stanie sprostać wymaganiom pojawiającym się w czasie realizacji projektu. Klient musi więc jasno przekazać wszelkie przewidywane potrzeby związane z projektem, zanim proces realizacji zostanie uruchomiony. Ścisły, kaskadowy charakter procesów w ramach Waterfall po prostu wyklucza zaspokojenie zmiennych oczekiwań.