Miałam okazję pracować wiele lat w projektach prowadzonych podejściem tradycyjnym (Waterfall) i w projektach zarządzanych zwinnie (skupię się na metodyce Agile Project Management). Chciałabym przybliżyć Ci różnice pomiędzy tymi dwoma podejściami. Dzięki temu ocenisz, które z nich jest właściwe w przypadku Twojego projektu.
Waterfall
Podejście klasyczne do zarządzania projektami zakłada, że wszystkie wymagania są bardzo dobrze zdefiniowane na samym początku projektu. Pozwala to zaplanować wszelkie działania w projekcie, następnie je zrealizować i zweryfikować jakość wyników.
Niestety brzmi to zbyt optymistycznie, żeby mogło być realne. W trakcie realizacji projektu tym podejściem bardzo często okazuje się, że nie wszystko zostało przewidziane, zdefiniowane i zaplanowane. A im później się o tym dowiadujemy, tym droższe będzie wyjście z tej sytuacji. W efekcie projekt albo zostaje zatrzymany, albo kończy się dużo później i z dużo wyższymi wydatkiami. Ku niezadowoleniu klienta.
Agile Project Management
Metodyka Agile Project Management jest jedną z metodyk (obok PRINCE2 Agile), które wprowadzają zmianę w podejściu do zarządzania projektami:
- praca w cyklach i szczegółowe planowanie tylko najbliższego cyklu,
- priorytetyzacja wymagań,
- udział biznesu w realizacji projektu,
- bieżąca weryfikacja jakości rozwiązania, nad którym pracuje zespół projektowy,
to tylko niektóre ze zmian, jakie wprowadziła metodyka Agile Project Management i które pozwalają dostarczyć na czas działające i przetestowane rozwiązanie.
Waterfall vs. Podejście zwinne
Postanowiłam zebrać podstawowe różnice pomiędzy tymi podejściami w poniższej tabeli.
Waterfall | AgilePM® | |
Korzyści poprojektowe | Bardzo często projekty trwają tak długo, że nie przynoszą korzyści biznesowych po ich zakończeniu w związku ze zmieniającym się otoczeniem organizacji. | Klient może dostosowywać oczekiwane rezultaty końcowe do zmieniającego się otoczenia. |
Wielkość projektu | Przy dużych projektach na rezultaty projektu przyjdzie nam czekać bardzo długo. Przy bardzo dużym zakresie projektu, projekt jest realizowany etapami. | Pozwala dostarczać rezultaty projektu w cyklach, dzięki czemu klient szybko dostaje wartość biznesową. |
Wymagania | Wszystkie wymagania muszą zostać zdefiniowane na początku projektu i nie podlegają zmianie. | Pozwala definiować wymagania na bieżąco, w miarę jak poznajemy potrzebę klienta. Kluczem jest priorytetyzacja MoSCoW. |
Zmiana | Im później wymagana, tym bardziej kosztowna. | Oczekiwana i akceptowana w każdym momencie. |
Jakość | Testy wykonywane na końcu, po zakończeniu procesu tworzenia rezultatów projektu; w efekcie błędy mogą być kosztowne w naprawie. Często projekt zamykany z jakością poniżej wstępnych ustaleń (w wyniku ograniczeń kosztowych lub nieprzekraczalnych terminów dostawy). | Testy wykonywane w każdej iteracji (równolegle z rozwojem wyników projektu); naprawa błędów szybka i mało kosztowna. Oczekiwana jakość wyniku końcowego nie podlega zmianom. |
Harmonogram projektu | Teoretycznie stały, ale w praktyce często modyfikowany w związku z koniecznością zmiany wymagań, poprawy jakości itp. | Ustalony i niezmienny. Modyfikacji ulega zakres projektu (priorytetyzacja MoSCoW). |
Budżet projektu | Teoretycznie stały, ale w praktyce często modyfikowany w związku z koniecznością zmiany wymagań, poprawy jakości itp. | Ustalony i niezmienny. Modyfikacji ulega zakres projektu (priorytetyzacja MoSCoW). |
Zaangażowanie klienta | Klient zaangażowany jest tylko na początku i na końcu projektu. | Klient obecny jest cały czas w projekcie. Jego zaangażowanie jest kluczem do sukcesu projektu. |
Zespół | Zespół realizuje wyznaczone zadania, nie ma mocy decyzyjnej. | Zespół zmotywowany, samoorganizujący się i decyzyjny. |
Podsumowanie
Pamiętaj, żeby przy wyborze podejścia należy się kierować się złożonością projektu oraz stopniem znajomości wymagań na etapie planowania. Zawsze będą takie projekty realizowane w sposób tradycyjny mimo rosnącej popularności podejścia zwinnego.