Jaka jest właściwa metodologia zarządzania projektami

Zanim przejdziemy do sedna kwestii, warto najpierw zdefiniować cel, który pragniemy osiągnąć realizując dany projekt.

Wyobraźmy sobie, jak produkt będzie wyglądał za miesiąc, pół roku, a następnie za rok. Opiszmy to teraz. Takie podejście ułatwi wyznaczenie perspektywy i stworzy fundament oczekiwań w kwestii przewidywalności, elastyczności, tempa pracy, szybkości wejścia na rynek i kosztów w czasie.

W dzisiejszych czasach, koncepcja tworzenia projektów w sposób kaskadowy może wydawać się przestarzała. Szczególnie, że wielokrotnie dowiedziono, iż adaptacja do zmiennych realiów rynkowych wymaga zwinnego podejścia. Niemniej jednak, jeżeli celem jest dostarczenie w przyszłym roku produktu o jasno określonych i niezmiennych funkcjach, a zespół nie ma doświadczenia w metodykach zwinnych, to konserwatywny model kaskadowy może być właściwym wyborem.

Nie zawsze jednak decyzja jest tak jednoznaczna. Zobaczmy, jak można skuteczniej ocenić, która metodyka będzie najbardziej odpowiednia dla konkretnego projektu.

Jak działa model kaskadowy?

Zamiast wdawać się w szczegółowe definicje, które są znane od dawna, przytoczymy praktyczny przykład przebiegu projektu kaskadowego:

• Na początku ustalamy, jaki ma być efekt końcowy i szacujemy przybliżony koszt.
• Następnie rozpoczynamy proces zbierania szczegółowych wymagań. Omawiamy, analizujemy, weryfikujemy i ostatecznie zatwierdzamy wszystkie aspekty produktu końcowego.
• Dokonujemy pełnej wyceny i potwierdzamy budżet.
• Projektujemy rozwiązanie. Organizujemy spotkania z interesariuszami. Tworzymy dokumentację, która jest przez nich recenzowana. Zatwierdzamy ostateczny projekt funkcjonalno-techniczny.
• Przystępujemy do implementacji rozwiązania na podstawie wcześniej przygotowanego projektu. Na tym etapie powstaje kompletny produkt.
• Rozpoczyna się faza testowania, w której przeprowadzamy różnorodne testy: jednostkowe, systemowe, funkcjonalne, integracyjne, wydajnościowe, regresyjne, akceptacyjne. Dokumentujemy wszystkie wyniki i pozwalamy interesariuszom na ich weryfikację.
• Wdrażamy rozwiązanie w środowisku produkcyjnym. Użytkownicy zaczynają korzystać z finalnego produktu.
• Planujemy wsparcie techniczne, w ramach którego zespół programistów usuwa potencjalne błędy.

Cały proces może trwać od kilku miesięcy do nawet kilku lat. Użytkownicy widzą efekty dopiero po zakończeniu wszystkich etapów. Po długim oczekiwaniu następuje weryfikacja tego, czy podjęte działania przyniosły sukces, czy też nie.

Jeśli w trakcie procesu zajdą zmiany i produkt końcowy powinien wyglądać nieco inaczej, taka sytuacja jest traktowana jako konieczność wprowadzenia modyfikacji. Projekt trzeba otworzyć na nowo, przeprojektować i ponownie zatwierdzić. Każda taka zmiana wydłuża czas realizacji. Wymaga ponownego uruchomienia całego cyklu.

Z drugiej strony, mamy solidne wyznaczenie zakresu działań, stały budżet dla każdego etapu i określony harmonogram. Nawet jeśli na efekty trzeba długo czekać, w sytuacji, gdy szanse na zmiany w trakcie projektu są minimalne, model kaskadowy może być preferowanym wyborem.

Jak działa Agile?

Oto przykładowy przebieg projektu realizowanego w metodologii Agile:

• Definiujemy wizję biznesową produktu końcowego. Określamy wymagania biznesowe i oczekiwania względem funkcjonalności dla użytkowników.
• Tworzymy listę Epików (dużych zadań) i zadań technicznych, które są niezbędne do realizacji wizji.
• Dokonujemy wstępnej oceny zadań, aby ustalić przybliżone ramy czasowe i budżet. Określamy Minimalny Produkt Żywotny (MVP) oraz pozostałe cechy produktu końcowego.
• Tworzymy zespół scrumowy i planujemy sprinty w określonym przedziale czasowym. Razem z zespołem dzielimy Epiki na mniejsze funkcje i historie użytkownika. Szacujemy czas realizacji i planujemy prace na kolejne sprinty, biorąc pod uwagę priorytet funkcji i historii.
• Pracujemy nad historiami użytkownika w każdym sprincie. W ramach sprintu projektujemy, programujemy, testujemy i wdrażamy. Po każdym sprincie prezentujemy przyrost produktu i zbieramy informacje zwrotne od użytkowników.
• W przypadku problemów lub konieczności dostosowania, modyfikujemy funkcje lub historie, aby odzwierciedlić aktualne potrzeby. Wprowadzamy zmiany do kolejnych sprintów.
• Po ukończeniu zakresu MVP udostępniamy produkt użytkownikom końcowym w celu szybkiego uzyskania informacji zwrotnej.
• Kontynuujemy rozwój pozostałych funkcji, uwzględniając opinie użytkowników z już wydanej części systemu.

To tylko krótki zarys, ale różnica w stosunku do modelu kaskadowego jest wyraźna. Szybka informacja zwrotna, elastyczność, reagowanie na bieżące potrzeby, dostarczenie wartościowego produktu w jak najkrótszym czasie. Tych cech nie można osiągnąć w projektach realizowanych w modelu kaskadowym.

Zwinność kontra model kaskadowy

Sukces projektu zależy od wyboru odpowiedniej metodologii zarządzania. To oznacza określenie procesów, wskaźników, ocen i sposobów pracy zespołu projektowego.

Zespoły muszą wiedzieć, jakie zasady obowiązują, jak wyznaczać kamienie milowe, kiedy je osiągać oraz jak oceniać sukces. Interesariusze muszą wiedzieć, czego oczekiwać od projektu i kiedy zobaczą pierwsze efekty.

Można uogólnić, że projekty realizowane w chmurze znacznie częściej opierają się na metodologiach zwinnych. Natomiast projekty wykorzystujące infrastrukturę lokalną często preferują model kaskadowy. Jest to naturalny wniosek.

Środowisko chmurowe z założenia jest elastyczne i dostosowuje się do zmian. Środowisko on-premise jest często definiowane na początku, a zmiany w trakcie projektu są trudne do wprowadzenia. Zespoły pracują w oparciu o niezmienne parametry przez cały czas trwania projektu.

Podsumowanie podejścia Agile vs. Waterfall.

Cecha	Model Kaskadowy	Model Zwinny
Obsługa wymagań użytkownika	Zmiany traktowane są jako formalny proces (Żądanie Zmiany). Mogą wymagać powtórzenia pracy, co wpływa na koszty i terminy.	Zmiany traktowane są jako element standardowego procesu, bez istotnego wpływu na koszty i terminy.
Planowanie i zakres projektu	Zakres jest określony na początku i utrzymywany. Fazy są sztywne i zgodne z pierwotnym planem.	Wizja produktu jest jasna, ale dopuszcza się modyfikacje. Praca jest podzielona na sprinty z elastycznym podejściem do zadań.
Śledzenie postępu projektu	Postęp jest śledzony w każdej fazie. Opóźnienia w jednej fazie mogą wpłynąć na harmonogram całego projektu.	Postęp jest śledzony poprzez demonstracje na koniec każdego sprintu. Koncentracja na wykonalnym produkcie.
Współpraca zespołowa	Różne osoby na różnych etapach projektu, ograniczona interakcja.	Wielofunkcyjny zespół ze stałą komunikacją między członkami i interesariuszami.
Zarządzanie ryzykiem	Śledzenie stanu na podstawie postępu fazy. Reakcja na ryzyko retrospektywna.	Koncentracja na proaktywnym rozwiązywaniu zależności i eliminowaniu ryzyka.
Ramy wdrożenia	Tradycyjna metodologia.	Wymaga transformacji podejścia i zmiany sposobu myślenia.

Dokonany wybór wpłynie na wiele aspektów realizacji projektu.

#1. Wymagania projektu i zarządzanie zmianami

Ważnym aspektem wpływającym na wybór metodyki jest sposób, w jaki będą realizowane wymagania użytkownika. Kolejnym czynnikiem jest procedura postępowania, gdy zaistnieje potrzeba zmiany już zatwierdzonych wymagań.

W modelu kaskadowym wszystkie wymagania są definiowane i zatwierdzane na początku. Każda zmiana jest traktowana jako Żądanie Zmiany, które wymaga ponownej weryfikacji i akceptacji.

Wszelkie prace wykonane do tego momentu muszą być przeanalizowane i potencjalnie wykonane od nowa. Konieczne jest skorygowanie kosztów (z powodu dodatkowej pracy), a w najgorszym przypadku wydłużenie harmonogramu całego projektu.

W metodyce zwinnej zmiany są mile widziane i traktowane jako standardowe działanie. Wraz z interesariuszami ustalamy, że zmiany są kluczowe dla utrzymania wizji projektu. Nowe wymagania są uwzględniane w kolejnych sprintach.

Oznacza to, że praca wykonana wcześniej może ulec zmianie. Zespoły od razu pracują nad nowymi wymaganiami. Nie traci się czasu ani pieniędzy. Po prostu dostosowujemy się do nowej rzeczywistości i zastępujemy pierwotny plan nowym. Nie ma potrzeby specjalnego zarządzania żądaniami zmian. Wszystko to jest częścią planowania sprintu.

#2. Planowanie i zakres projektu

W modelu kaskadowym na początku ustala się cały zakres projektu. Na tej podstawie tworzony jest plan, a czas trwania projektu jest dzielony na etapy (analiza, projektowanie, rozwój, testowanie, wdrożenie, wsparcie i konserwacja). Zadaniem zespołów jest trzymanie się pierwotnego planu pod względem kosztów i harmonogramu.

Model zwinny zakłada jasną wizję produktu końcowego, ale bez sztywnego planu. Stan końcowy jest znany, ale droga do jego osiągnięcia może się zmieniać. Harmonogram jest określany na podstawie wstępnych oszacowań. Plan nie ma odrębnych faz. Każdy sprint jest mini-fazą, która zawiera wszystkie działania potrzebne do wypuszczenia przyrostu produktu.

Podsumowując, model kaskadowy traktuje zmiany jako komplikację (i szansę dla dostawców na dodatkowy zarobek). Model zwinny traktuje zmiany jako normalne działanie, bez dodatkowych konsekwencji (poza lepszym produktem końcowym).

#3. Śledzenie postępu projektu

W projekcie kaskadowym postęp jest śledzony w poszczególnych fazach. Faza projektowania nie może się rozpocząć przed zakończeniem fazy analizy. Testowanie nie może się zacząć przed ukończeniem kompilacji itd.

Opóźnienie w jednej fazie wpłynie na postęp pozostałych etapów projektu. Dlatego ważne jest kontrolowanie działań w każdej fazie. W przeciwnym razie wzrasta ryzyko opóźnienia, a co za tym idzie całego projektu.

W modelu zwinnym postęp jest śledzony dzięki sesjom demonstracyjnym na koniec każdego sprintu. Wykonalny produkt jest podstawowym miernikiem postępu. Chcemy, aby każdy sprint kończył się pełną treścią. Do kolejnych sprintów nie są przenoszone żadne lub minimalne historie użytkownika.

Znacznie łatwiej jest ocenić postęp projektu, gdy można na bieżąco testować przyrost produktu i od razu przekazywać zespołowi informacje zwrotne.

#4. Praca zespołowa

W metodologii kaskadowej działania są rozdzielone, w przeciwieństwie do współpracy zespołu zwinnego.

W projekcie kaskadowym różne osoby pracują na różnych etapach. Mogą się w pewnym stopniu przenikać, ale nadal są to odrębne grupy.

Zwinny zespół opiera się na komunikacji i wspólnych wartościach. Jest to zespół interdyscyplinarny, zdolny do wykonywania wszystkich zadań związanych z cyklem życia produktu. Stała komunikacja pomiędzy zespołem a interesariuszami jest podstawą udanego projektu zwinnego.

#5. Zarządzanie ryzykiem

Niezbędne jest posiadanie procesu śledzenia zagrożeń, problemów i przeszkód, które mogą wystąpić w projekcie.

W modelu kaskadowym polega to na śledzeniu postępu aktualnej fazy. Raportowanie stanu projektu jest oparte o schemat semafora: zielony (wszystko jest w porządku), żółty (istnieją problemy, ale wiemy, jak je rozwiązać) lub czerwony (poważne problemy, które mogą wpłynąć na harmonogram lub budżet).

W modelu zwinnym zarządzanie ryzykiem jest inne. Nie śledzimy postępu w kierunku celu, ale rozwiązujemy zależności pomiędzy różnymi zespołami i rodzajami działań. Celem jest unikanie sytuacji, w której jeden zespół czeka na inny.

Może pojawić się ryzyko. W takim przypadku należy zmienić plan, tak aby go wyeliminować, zamiast szukać rozwiązania, trzymając się pierwotnego planu.

W metodyce zwinnej proaktywnie planujemy tak, aby uniknąć ryzyka. W modelu kaskadowym reagujemy na ryzyka retrospektywnie, starając się je rozwiązać w jak najkrótszym czasie.

#6. Ramy wdrożenia

Wdrożenie metodologii kaskadowej jest łatwiejsze niż w przypadku modelu zwinnego. Metodologia kaskadowa jest często standardem i jest stosowana od lat.

Wdrożenie metod zwinnych wymaga zmiany nawyków, sposobu myślenia i pracy. Jest to trudne i czasochłonne. Firmy inwestują w szkolenia, aby dostosować ludzi do zwinnych procesów.

Korzyści płynące z szybkiej adaptacji do potrzeb klienta są znaczne, ale najtrudniejsza jest zmiana sposobu myślenia i środowiska pracy.

W większości przypadków jest to konieczne, aby utrzymać konkurencyjność na rynku. Firmy, którym to się uda osiągają wielki sukces.

Ostatnie słowa

Podsumowując, jeśli nie mamy bardzo konserwatywnego klienta i potrzebujemy szybko dostarczać wyniki, najlepiej od początku budować zwinne zespoły. W dzisiejszym świecie jest to niemal standard. Dzieje się tak nawet w tradycyjnych systemach on-premise. Zwłaszcza, jeśli zespół jest nowy, warto dostosować procesy pracy do zwinnych metodyk.

Pomimo tego wciąż zdarzają się projekty, w których odmawia się stosowania zwinnego podejścia. Prace są kontraktowane na określony czas i budżet. Oczekuje się, że projekt będzie realizowany bez odstępstw od planu (z różnymi wynikami, zwykle niezbyt dobrymi).

To jest decyzja, którą mają prawo podjąć, ale oznaczają one pozostanie w przeszłości. Takie podejście może działać przez jakiś czas, ale w końcu przestanie być efektywne.

Zapraszam do zapoznania się ze szczegółowym artykułem na temat cyklu życia testów Agile.