This site uses cookies to provide social media features and analyze the traffic.

Waterfall vs Agile – różnice pomiędzy tradycyjnym a zwinnym podejściem do zarządzania projektem

Jedną z pierwszych decyzji, które podejmujemy w podejściu do realizacji nowego projektu lub organizacji procesu zarządzania w naszej działalności jest wybór odpowiedniej metody. Prince 2, Scrum, PMI, Agile – mnogość certyfikatów, szkoleń i opracowań nie ułatwia początkującym menadżerom odnalezienia się w możliwościach jakie dają. Podstawą świadomego podejścia do metod zarządzania jest zrozumienie różnicy pomiędzy podejściem tradycyjnym znanym jako model kaskadowy (ang. Waterfall) a podejściem zwinnym zapoczątkowanym i opisanym w manifeście Agile.

Na czym polega model kaskadowy?

W podejściu kaskadowym planujemy całe przedsięwzięcie z wyprzedzeniem. Podobnie jak w wodospadzie kaskadowym woda spada w jednym kierunku, etapami pokonując kolejne, stałe kaskady tak w tej metodologii polegamy na wykonywaniu czynności projektowych jako określonych faz występujących kolejno po sobie.
Wyróżnia się następujące czynności dzięki, którym projekt jest przeprowadzany od kontrolowanego startu do kontrolowanego zamknięcia:

  1. Przygotowanie projektu
  2. Inicjowanie projektu
  3. Realizacja projektu
  4. Zamykanie projektu

Istotnym aspektem projektu jest jego zakres, który w podejściu tradycyjnym musi być bardzo dobrze znany już na samym początku projektu. Pozwala to skutecznie planować z wyprzedzeniem i realizować projekt w oparciu o plan, wiąże się jednak z bardzo formalnym podejściem do zarządzania wszelkimi zmianami. Jesteśmy ściśle zależni od zaplanowanego przez nas zakresu prac oraz ustalonych wymagań, dlatego zbieramy je dość dokładnie na bardzo wczesnym etapie projektu. Dobrym przykładem projektów naturalnie spełniających wymaganie zakresu projektu znanego na bardzo wczesnym etapie są projekty budowlane, w których całe przedsięwzięcie prowadzone jest ściśle według wcześniej przygotowanej dokumentacji projektowej. Pozwala to na określenie z góry czasu trwania projektu, dat zakończenia etapów oraz szacowanie kosztów, potrzebnych zasobów, sprzętu i materiału. W ten sposób tworzymy określone poziomy odniesienia dla całego projektu oraz etapy, w których możliwa jest weryfikacja, kontrola i ewentualne wprowadzanie zmian w projekcie. Dlatego podejście tradycyjne wykorzystywane jest głównie w bardzo dużych, długoterminowych przedsięwzięciach trwających rok lub dłużej, najczęściej związanych z powstaniem namacalnego efektu.

Cechy podejścia tradycyjnego:

– sekwencyjny przebieg procesu

– działanie w oparciu o plan i formalne zarządzanie zmianą

– zależność od wymagań określonych na wczesnym etapie

– zakres, czas i koszt szacowane i określone dla całego projektu

– nieelastyczny podział na kolejne fazy, przejście do następnej fazy możliwe po zakończeniu poprzedniej

– wykorzystywane w budownictwie, produkcji masowej, postępowaniach przetargowych i innych długoterminowych przedsięwzięciach o konkretnych wymaganiach

Z czym wiąże się praca w modelu kaskadowym?

Waterfall ma oczywiście swoje wady. Podstawowe problemy związane są z momentem weryfikacji wyników prac przez klienta (zewnętrznego lub biznes) dopiero po zakończeniu etapu lub całego projektu. Może dojść do sytuacji, w której klient mając zatwierdzić określoną wartość stwierdzi, że jest ona inna od oczekiwanej i nie spełnia jego wymagań. Klient chce czegoś innego niż dostarczono. Jest to szczególnie frustrujące w sytuacji kiedy zespół projektowy działał zgodnie z zebranymi i ustalonymi na początku projektu wymaganiami, a mimo to oczekiwane wyniki są inne. Jednocześnie wprowadzanie zmian na takim etapie jest trudne, ze względu na pierwotnie ustalony plan, a w skrajnych przypadkach może prowadzić do konieczności anulowania i ponownego przygotowania projektu.
Inną kwestią związaną z waterfall’em jest obszerna dokumentacja projektowa. Metodologie takie jak Prince 2 zawierają szereg reguł, instrukcji i dobrych praktyk tworzenia dokumentacji. Rolą managerów jest dobranie i zastosowanie ich w sposób odpowiedni dla danego projektu. Istotne jest przy tym, że im obszerniejsza dokumentacja w planowaniu z wyprzedzeniem tym trudniej reagować na późniejsze zmiany wymagań. Duży poziom formalizacji nie pozwala na elastyczność w przypadku dużej ilości lub znaczących zmiany.

Wszystkie te wyzwania powodują, że tradycyjnie stosowane kaskadowe podejście do zarządzania projektem, mimo że świetnie sprawdza się w długoterminowych projektach z obszerną specyfikacją wymagań to nie znajduje zastosowania w projektach obarczonych ryzykiem i niepewnością, w których na etapie planowania projektu nie znamy pełnych wymagań i oczekiwanych wyników.

Wyzwania Waterfall’a:

– potwierdzenie, że zostały spełnione wymagania projektu następuje po jego zakończeniu

– planowanie i kontrola projektu wymagania bardzo obszernej dokumentacji – w przypadku znaczących zmian zakresu projektu konieczne może być jego anulowanie oraz ponowne przygotowanie i inicjowanie

Czym jest Agile, czyli zwinne podejście do projektów?

Zwinne podejście do projektowania powstało początkowo jako odpowiedź na wady i ograniczenia tradycyjnego podejścia, które nie sprawdzało się w projektach związanych z tworzeniem i rozwojem oprogramowania.  Pracując z nowymi, rewolucyjnymi produktami nie mamy odpowiedzi na wszystkie pytania projektowe, a rzeczywistość ciągle się zmienia i trudno z wyprzedzeniem planować przebieg prac. Agile spodziewa się zmian w trakcie projektu i je akceptuje, zakłada elastyczność przebiegu prac połączoną z transparentnością i zdrowym rozsądkiem. W podejściu zwinnym chcemy tworzyć właściwą wartość, we właściwy sposób otrzymując informację zwrotną oraz planując w ramach postępu projektu. Założenia te realizowane są poprzez iteracyjne podejście do pracy. Praca dzielona jest na krótkie cykle (sprinty), w trakcie których  zespół skupia się na dostarczeniu konkretnej wymaganej przez klienta wartości, która stanowi część finalnego rozwiązania.  W trakcie takiego cyklu cross-funkcjonalny zespół samodzielnie planuje pracę, projektuje rozwiązanie, testuje i zdobywa feedback (informację zwrotną) od klienta. Dopiero w oparciu o wyniki zakończonego sprintu planowany jest kolejny. Istotne przy tym jest, żeby w każdym sprincie dostarczać funkcjonalne przyrosty (np. pojedyncza działająca funkcja aplikacji), które mogą być oceniane i weryfikowane przez klienta.  Dzięki temu, że nie planujemy zbyt daleko do przodu wszelkie zmiany mogą być wprowadzane i wrażane w kolejnych iteracjach. Sprzyja to również wykrywaniu błędów w programowaniu.

Główne cechy Agile:

– pierwotnie powstał dla jako rozwiązanie wad podejścia kaskadowego w rozwoju oprogramowania

– prosta konstrukcja projektu, która rozwija się wraz z jego postępem

– elastyczne podejście do zakresu i akceptacja zmian

– koncentracja na dostarczanej wartości zamiast zakresie prac

– stosowanie krótkich iteracji oraz weryfikacji po każdej z nich

– wzmacnianie samodzielności i odpowiedzialności zespołu

– wykorzystywany najczęściej w projektach opartych na wiedzy (głównie rozwoju oprogramowania)

Dlaczego Agile nie jest idealny i o czym należy pamiętać?

Podejście zwinne wiąże się oczywiście z pewnymi trudnościami. Pierwszą jest ustalenie właściwych wymagań i zakresu projektu, ponieważ ciągle dopasowujemy się, zmieniamy projekt próbując odpowiedzieć na wymagania klienta i dostarczać oczekiwaną wartość. Podejście zwinne jest łatwe w teorii i w wymogach formalnych, ale bardzo trudne do wdrażania w praktyce. Agile jest filozofią pracy, która zakłada wysokie kompetencje i zaangażowanie zespołu. W rzeczywistości kiedy praktykujemy Scrum, Extreme Programming lub inne zwinne metodyki najczęstszym zagrożeniem jest niewystarczające zaangażowanie i motywacja do stosowania pryncypiów Agile. Może prowadzić to do chaosu i trudności we wdrożeniu podejścia. Również bez wsparcia i zaufania menedżerów wyższego szczebla wprowadzenie niektórych zasad i funkcjonowanie w sposób zwinny okaże się niemożliwe. Dlatego ważna jest kompleksowa transformacja firmy w kierunku Agile oraz ciągłe doskonalenie się zespołów. Do stałego podnoszenia efektywności procesu wytwórczego oraz komfortu pracy prowadzą przyglądanie się własnej pracy, uczenie na błędach i wyciąganie wniosków i likwidowanie przeszkód.
Ostatnim elementem o jakim należy pamiętać jest to, że Agile nie dotyka takich aspektów jak sprzedaż projektu, analiza wymagań biznesowych, rekrutacja i szkolenia zespołu, dokumentowanie pracy, zarządzanie kosztami i konfiguracją oraz relacja z udziałowcami i stosunki prawno-formalne.

Wyzwania Agile:

– w celu zaspokojenia potrzeb klienta i dostarczenia właściwej wartości podejście zwinne wymaga zbierania wymagań i informacji zwrotnej w każdej iteracji

– zarówno członkowie zespołów jak i menadżerowie projektów muszą mieć dobre przygotowanie i wysoką świadomość funkcjonowania zwinnych metodyk oraz być dobrze zmotywowani

– niski poziom kontroli oraz bardzo ograniczona dokumentacja wymagają zaufania kierownictwa wyższego szczebla

– koncentracja głównie na dostarczaniu wartości z pominięciem wielu innych aspektów

Główne różnice pomiędzy podejściem zwinnym (Agile), a tradycyjnym modelem kaskadowym (Waterfall):

Agile Waterfall
– Nie wiemy jak dokładnie będzie wyglądał finalny produkt. – Ściśle określony obraz finalnego produktu.
– Budujemy przyrostowo dostarczając wartość w kolejnych iteracjach. – Zakończenie pełnego projektu i końcowa jakość są ważniejsze niż szybkie rezultaty
– Zmiana jest spodziewana w projekcie, a podejście do zakresu elastyczne. – Zmiana zarządzana jest w sposób bardzo formalny i ma wpływa na korektę planu i zakresu.


 Różnice pomiędzy dwoma podejściami dobrze uwydatnia zestawienie ich na wspólnym przykładzie. Omówmy hipotetyczne przedsięwzięcie jakim jest budowa i uruchomienie szpitala specjalistycznego. W rzeczywistości projekt taki byłby zarządzany z wykorzystaniem waterfall’a. Najpierw przygotowalibyśmy specyfikacje wymagań dla całego przedsięwzięcia, następnie wykonalibyśmy ich analizę i zaprojektowali całość szpitala od budynku, poprzez wykończenie, po wyposażenie w sprzęt specjalistyczny wszystkich oddziałów. Wykonanie następowało by takimi samymi etapami obejmującymi swoim zakresem cały budynek. Na zakończenie potwierdzamy spełnienie wszystkich wymagań projektowych i uruchamiamy szpital. Uruchomienie szpitala podlega szeregowi przepisów takich jak prawo budowlane, czy prawo zamówień publicznych, dlatego bardzo ważne jest wykonanie pełnego projektu zgodnie ze ściśle określonym na początku planem i jego końcowa jakość spełniająca wszystkie wyspecyfikowane wymagania. Z tych samych powodów wszelkie zmiany w projekcie związane są z wysokim stopniem formalizacji.

Przedstawienie tego samego przedsięwzięcia uruchomienia szpitala wielospecjalistycznego jako projektu agile’owego jest przykładem przerysowanym, ale bardzo dobrze pokazującym podstawowe różnice pomiędzy podejściem tradycyjnym a zwinnym. W tym podejściu zaczynamy od wykonania od początku do końca i uruchomienia tylko jednego oddziału szpitala, na przykład chirurgii. Dopiero mając jeden w pełni funkcjonalny oddział, który dostarcza nam już oczekiwaną wartość pracujemy nad uruchomieniem kolejnego. W ten sposób zyskujemy przychód wartości oraz informację zwrotną już na wczesnym etapie projektu stanowiące podstawę do dalszego przyrostowego rozwoju. Informacje uzyskane z każdą iteracją pozwalają podejmować dalsze decyzje biznesowe, możemy na przykład podjąć decyzję o zmianie struktury oddziałów, które planujemy kolejno uruchamiać.

Podsumowując podejście tradycyjne i zwinne to dwa całkowicie odmienne spojrzenia na zarządzanie projektem. Łączy je to, że oba są użytecznymi, dojrzałymi metodologiami, a świadome podejście do zarządzania wymaga zrozumienia różnic między nimi. Po wyborze podstawowej metodologii powinniśmy dalej udoskonalać proces, żeby pasował do celów naszego projektu. Pamiętajmy również, że choć sposób w jaki wykonujemy pracę jest bardzo ważny, to najważniejsze pozostaje dostarczenie właściwej wartości dla naszego klienta.

Jeżeli zainteresowało Cię zwinne podejście do zarządzania, śledź naszego bloga, na którym planujemy opisać jak wykorzystaliśmy zwinne podejście do zarządzania pracą w zespole Creative Labs. A jeśli już teraz chcesz pracować w Scrum lub Agile sprawdź jak organizujemy pracę z wykorzystaniem w google spreadsheet i użyj go do zwinnego zarządzania swoim projektem lub zespołem:

CL Agile / Scrum Board template

Autor: Roland Rychlik