Agile czy Waterfall (sekwencyjny) – który jest lepszy?

Jako praktyk, trener, coach i konsultant zwinnych metodyk, moglibyście oczekiwać, że powiem: „Agile to jedyny sposób na sukces—zapłaćcie mi dużo pieniędzy, a pokażę wam dlaczego!"

Ale oto prawda (uwaga, spoiler): mogę odpowiedzieć na to pytanie tylko „to zależy". Może to brzmieć niejasno, ale często jest to najbardziej szczera i wartościowa odpowiedź.

Ostatecznie tylko wy możecie zdecydować, co jest najlepsze dla waszego projektu i organizacji, w oparciu o czynniki napędowe i ograniczenia, które rozumiecie lepiej niż ja. Mam nadzieję, że ten artykuł pomoże wam to samodzielnie rozgryźć.

Zacznijmy od przyjrzenia się głównym ideom stojącym za każdym podejściem.

Zarządzanie projektami w modelu kaskadowym następuje zgodnie z sekwencyjnym, predykcyjnym podejściem. Zakres jest zazwyczaj ustalony, a rozwiązanie często w pełni określone przed rozpoczęciem rozwoju. Dostarczenie może nastąpić jako pojedynczy „wielki wybuch" lub w fazach, gdzie każda faza dostarcza znaczną część całościowego rozwiązania.

Typowa metoda kaskadowa obejmuje następujące etapy:

1. Analiza: Zidentyfikuj, udokumentuj, uzgodnij i zatwierdź wymagania oraz wszelkie standardy jakości. W IT obejmuje to wymagania niefunkcjonalne.
2. Projektowanie: Stwórz i zatwierdź szczegółowy projekt, który spełnia uzgodnione wymagania i kryteria jakości.
3. Budowa: Skonstruuj rozwiązanie zgodnie z projektem, zapewniając, że spełnia wszystkie określone wymagania i standardy jakości.
4. Testowanie: Dokładnie przetestuj rozwiązanie, aby potwierdzić, że spełnia uzgodnione wymagania, projekt i inne kryteria jakości.
5. Wdrożenie: Wprowadź rozwiązanie do użytku, aby dostarczyło zamierzoną wartość biznesową.

Każdy etap musi być zaplanowany i wyposażony w zasoby, ze wszystkimi działaniami jasno określonymi, oszacowanymi i przydzielonymi. W wielu przypadkach działania będą podzielone na szczegółowe zadania i przedstawione w formie wykresu GANTT. W przypadku projektu fazowego, wysokopoziomowa analiza i projektowanie powinny nastąpić najpierw, aby ustalić kontekst i zakres dla każdej fazy.

Podejście kaskadowe wymaga predykcyjnego stylu zarządzania projektem, w którym każdy etap produkuje dokumentację określającą, co musi zrobić następny etap.

Cała praca dla każdego etapu jest planowana w oparciu o oczekiwanie (samo w sobie będące przewidywaniem), że rezultat będzie odpowiadał temu, co zostało uzgodnione. Właściwie zatwierdzona dokumentacja jest głównym sposobem komunikowania intencji projektu wszystkim zaangażowanym lub dotkniętym nim osobom.

Kontrola projektu polega na wykazaniu, że dostarczona praca odpowiada dokumentacji z poprzedniego etapu, a także na przestrzeganiu zatwierdzonego planu dla bieżącego etapu. Wszelkie zmiany powinny przechodzić przez formalny proces, w którym dokumentacja jest rewidowana i zatwierdzana. Idealnie, dokumentacja jest regularnie przeglądana, aby upewnić się, że nadal spełnia zmieniające się potrzeby biznesowe.

Zmiany mogą być identyfikowane z pracy w późniejszych etapach procesu kaskadowego. Na przykład, gdy problemy są odkrywane podczas etapu Testowania, które identyfikują niezgodność między określonymi wymaganiami a bieżącymi potrzebami biznesowymi. Wymagana jest analiza tej niezgodności, a wszelkie uzgodnione zmiany kaskadują w dół wodospadu, aby ostatecznie zostać ponownie przetestowane.

Postrzeganie sukcesu w modelu kaskadowym ma zatem tendencję do wiązania się z tym, jak dobrze przewidywania odpowiadają rzeczywistym potrzebom i jak ściśle rezultaty są zgodne z przewidywaniami pod względem budżetu, harmonogramów i jakości.

Proces kaskadowy może wydawać się na początku prosty, ale często okazuje się bardziej skomplikowany niż oczekiwano. W dużym stopniu opiera się na dokumentacji, wykorzystuje hierarchiczne zatwierdzenia i stosuje scentralizowane planowanie. Ponieważ wymaga szczegółowej, wstępnej dokumentacji i planowania, proces może stać się skomplikowany, z wieloma powiązanymi elementami wymagającymi połączenia, aby proces osiągnął pożądany rezultat.

Zalety:

• Przejrzysta struktura: Podejście krok po kroku jest łatwe do zrozumienia przez kierowników projektów i wytłumaczenia interesariuszom.
• Przewidywalne planowanie: Kompleksowa analiza i projektowanie na początku wspierają jasne i precyzyjne planowanie oraz budżetowanie.
• Proste śledzenie: Postęp można monitorować poprzez dokumentację (pokazującą, jak osiągane są kamienie milowe) i weryfikować względem planu (w celu potwierdzenia, że zadania są realizowane na czas i w ramach budżetu).

Wady:

• Skomplikowane zarządzanie zmianami: Obsługa niezbędnych zmian może być uciążliwa, czasami prowadząc zespoły do całkowitego ominięcia procesu i skutkując utratą kontroli.
• Późne wykrywanie problemów: Rozwój w dużych przyrostach z testowaniem w dużej mierze skoncentrowanym pod koniec procesu może ujawnić problemy zbyt późno, powodując nieoczekiwane opóźnienia i przekroczenia kosztów.
• Zmniejszone skupienie na wartości biznesowej: Obszerna wstępna analiza i dokumentacja nie oferują bezpośredniej wartości biznesowej; istnieją wyłącznie po to, by kierować procesem.

Chociaż nadal zawiera odrębny element procesu do ramowania rozwoju, zwinne podejście do zarządzania projektami koncentruje się bardziej na ludziach niż na procesie. Praca wstępna jest celowo ograniczona, kształtując jedynie rozwiązanie i plan na wysokim poziomie, pozostawiając drobniejsze szczegóły do ostatniego odpowiedzialnego momentu przed rozpoczęciem rozwoju. Zazwyczaj rozwój przebiega funkcjonalność po funkcjonalności w ramach "Sprintów" o stałej długości.

Uczestnicy projektu – co ważne, włączając w to przedstawicieli biznesu w zespołach deweloperskich – współpracują przez cały czas trwania projektu. Budują mniejsze przyrosty niż w tradycyjnym modelu kaskadowym, korzystając z procesu iteracyjnego.

Każda iteracja obejmuje analizę, projektowanie, budowę, testowanie i idealnie wdrożenie, w cyklach, które mogą trwać zaledwie kilka godzin lub rozciągać się na kilka dni czy tygodni (zamiast tygodni lub miesięcy często spotykanych w modelu kaskadowym). Celem jest wdrażanie części rozwiązania, gdy tylko mogą one dostarczyć wartość.

Rozwój opiera się na szczegółowej współpracy kompetentnych i wykwalifikowanych osób, które organizacja wyposażyła w uprawnienia do opracowania rozwiązania spełniającego potrzeby biznesowe.

Te osoby definiują szczegóły potrzeby przed zaplanowaniem wymaganej pracy deweloperskiej. Następnie realizują ten plan, ciągle go dostosowując, aby skupić się na dostarczaniu maksymalnej wartości. Dla prawdziwej zwinności zespoły często kierują się wartościami takimi jak te znalezione w Scrum, które obecnie jest najszerzej przyjętym zwinnym podejściem do realizacji projektów.

Podejście iteracyjne jest bardzo tolerancyjne na zmiany, ponieważ odkłada szczegółowe planowanie do ostatniego odpowiedzialnego momentu, wykorzystując dane w czasie rzeczywistym i krótkie cykle planowania. Zamiast być w pełni przewidzianym na wczesnym etapie, rozwiązanie stopniowo wyłania się, aby sprostać potrzebom, które zostały nakreślone (ale nie skrupulatnie zdefiniowane) na początku projektu.

Dzięki priorytetowemu traktowaniu wymagań wysokiego poziomu na początku i zajmowaniu się najpierw najważniejszymi z nich, pozwala zespołom zwinnym utrzymać ścisłą kontrolę nad terminami i budżetami. Rozwój po prostu kończy się w kontrolowany sposób, gdy zostaną osiągnięte limity czasowe lub budżetowe, a z finalnej dostawy wyłączone zostają jedynie najmniej wartościowe elementy.

Ponieważ cykle rozwoju są krótkie (zazwyczaj około dwóch tygodni) i ustalone, sensowne jest mierzenie sukcesu poprzez przyrostowe dostarczanie wartości w przewidywalnym tempie.

Podejście iteracyjne i przyrostowe, z krótkimi cyklami czasowymi napędzanymi przez upełnomocnione, samoorganizujące się zespoły, często wydaje się chaotyczne. Ale przy odpowiednio wykwalifikowanych, współpracujących i zdyscyplinowanych ludziach jest wysoce wydajne i skuteczne. Należy jednak zaznaczyć, że ryzyko używania podejścia zwinnego z osobami, które nie są kompetentne, nie współpracują i nie są zdyscyplinowane, bardzo prawdopodobnie doprowadzi do porażki. To sprawia, że nadzór (ale nie zarządzanie) jest niezbędny do momentu, gdy zespoły wykażą swoją zbiorową zdolność do realizacji zadań.

Zalety:

• Rozwój iteracyjny: Szybkie cykle rozwojowe z możliwością współpracy i ciągłego otrzymywania informacji zwrotnych zmniejszają ryzyko budowania rozwiązania, które nie spełnia rzeczywistych potrzeb.
• Przyrostowe dostarczanie wartości: Dostarczanie namacalnej wartości w krótkich odstępach czasu poprawia ogólną kontrolę, ułatwiając śledzenie postępów i identyfikację działań naprawczych.
• Zdolność adaptacji: Pozostawienie szczegółów na ostatni odpowiedzialny moment pozwala na wyłonienie się rozwiązań spełniających aktualne, a nie przewidywane potrzeby.

Wady:

• Może wydawać się nieustrukturyzowane: Szczególnie dla osób przyzwyczajonych do kontroli opartej na procesach. Nie jest dobrze dopasowane do menedżerów i liderów o wysokich potrzebach kontroli.
• Wysokie kompetencje i współpraca od wszystkich zaangażowanych: Liderzy wymagają pewności siebie, aby zaufać, i kompetencji, aby upełnomocnić swoje zespoły współpracujące.
• Potencjał chaosu i porażki: Zespołom pozbawionym wykazanych kompetencji i profesjonalizmu może się nie powieść bez właściwego nadzoru.

Uwaga: wady opisane powyżej dotyczą zespołów lub organizacji, które są nowe w zwinnym sposobie pracy. Tam gdzie istnieją rzeczywiste kompetencje w zakresie zwinności, trudno jest zidentyfikować uniwersalne wady, chociaż mogą pojawić się takie specyficzne dla kontekstu.

Kluczowe różnice między podejściem agile a podejściem kaskadowym można podsumować w 5 wymiarach:

1. Rozwój rozwiązania – Emergentny vs. Określony:

• Agile: Rozwiązanie wyłania się z czasem, aby sprostać zmieniającym się potrzebom biznesowym. Szczegóły ewoluują bliżej momentu rozwoju, zachowując elastyczność rozwiązania.
• Kaskadowe: Rozwiązanie jest definiowane z góry, aby sprostać oczekiwanej potrzebie. Potrzebna jest staranna kontrola zmian, aby utrzymać zgodność ze zmieniającymi się potrzebami.

2. Uczestnicy projektu – Współpracujący i wielofunkcyjni vs. Wyizolowani i wyspecjalizowani:

• Agile: Członkowie zespołu współpracują ze sobą w szerokich rolach, robiąc wszystko co potrzebne, aby osiągnąć wspólny cel. Celem jest unikanie komunikacji poprzez dokumentację i minimalizowanie przekazywania zadań gdzie tylko to możliwe.
• Kaskadowe: Choć pewien stopień współpracy jest często obserwowany, koncentruje się ona zwykle na konkretnych i wyspecjalizowanych działaniach (takich jak zbieranie wymagań). Uczestnicy projektu mają tendencję do przyjmowania wyizolowanego podejścia inżynierii przemysłowej, które dominowało w myśleniu XX wieku, zazwyczaj z komunikacją i kontrolą zarządzaną poprzez dokumentację.

3. Zarządzanie – Samoorganizujące się vs. Zarządzane:

• Agile: Zespoły organizują się i zarządzają sobą same, decydując jak wykonać zadania i dostosowując procesy w miarę uczenia się.
• Kaskadowe: Zespoły zazwyczaj otrzymują wskazówki od menedżerów, którzy decydują co należy zrobić, przez kogo i kiedy. Poziom szczegółowości tych instrukcji może się jednak różnić w zależności od projektu lub stylu menedżera.

4. Zmiany – Przyjmowane vs. Odrzucane:

• Agile: Ponieważ zespoły pracują nad szerokimi celami bez definiowania każdego szczegółu z góry, z zadowoleniem przyjmują zmiany w miarę pojawiania się nowych potrzeb lub spostrzeżeń.
• Kaskadowe: Zarządzanie zmianami jest biurokratyczne i kosztowne, ponieważ wymaga dokładnej analizy, dokumentacji i zatwierdzenia. W rezultacie często działa jako bariera dla niezbędnych zmian.

5. Kontrola oparta na: Dyscyplinie zawodowej vs. Zgodności z procesami

• Agile: Opiera się w dużej mierze na kompetencjach zespołu, dyscyplinie i samoorganizacji. Członkowie zespołu składają sobie nawzajem zobowiązania i wspólnie ponoszą odpowiedzialność za zadania i rozwiązania.
• Kaskadowe: Wykorzystuje szczegółowe planowanie i jasne instrukcje. Rola każdego jest zdefiniowana z góry, a kierownik projektu koordynuje działania. Sukces zależy od przestrzegania planu i procesów zgodnie z założeniami.

Jak wspomniałem wcześniej, to zależy…

W dzisiejszym złożonym świecie prowadzenie w pełni zwinnego lub w pełni kaskadowego projektu jest mało prawdopodobne. Częściej zespoły odkrywają, że pewna zwinność może dodać wartości do głównie kaskadowego projektu, podczas gdy niektóre elementy kaskadowe mają sens w skądinąd zwinnym projekcie. To połączenie jest często nazywane podejściem hybrydowym, znajdującym się w szarej strefie między tymi dwoma skrajnościami.

Tak więc, prawdziwe pytanie kierownika projektu nie brzmi „Którą czystą metodę powinienem wybrać?", ale raczej „Gdzie w tym spektrum powinien znaleźć się mój projekt?" Metodyki zwinne sprawdzają się doskonale w środowiskach o wysokiej zmienności, niepewności, złożoności i niejednoznaczności (VUCA). Natomiast podejścia kaskadowe zazwyczaj działają najlepiej tam, gdzie rzeczy są bardziej stabilne, pewne, proste i jasne.

Framework Cynefin może pomóc Ci określić, gdzie w tym spektrum może znajdować się Twój projekt.

Cynefin, wymawiane kuh-nev-in, to walijskie słowo oznaczające wielorakie, wzajemnie powiązane czynniki w naszym otoczeniu i naszym doświadczeniu, które wpływają na nas (na to, jak myślimy, interpretujemy i działamy) w sposób, którego nigdy nie będziemy w stanie w pełni zrozumieć.

W uznanym uproszczeniu Modelu Cynefin, środowisko, w którym pracujemy – w tym przypadku nasze środowisko projektowe – można umieścić na spektrum charakteryzowanym jako jasne, skomplikowane, złożone lub chaotyczne.

W środowisku projektu, które jest:

• Jasne, istnieje oczywista ścieżka między problemem a rozwiązaniem.
• Skomplikowane, ścieżka między problemem a rozwiązaniem może nie być oczywista, ale dobra analiza ujawni ścieżkę do odpowiedniego rozwiązania.
• Złożone, nie jest możliwe zidentyfikowanie pojedynczej ścieżki, nawet przy pomocy analizy, ponieważ przewidywania można oprzeć tylko na teorii, a nie na doświadczeniu.
• Chaotyczne, nie ma podstaw do przewidywania, ponieważ jest zbyt wiele zmieniających się lub sprzecznych czynników. Jedyną drogą naprzód są eksperymenty.

W powyższym przypadku jasna domena nadaje się do czystego podejścia kaskadowego, a chaotyczna domena wymaga zwinności. Pozostałe dwie – najczęstsze w rzeczywistości – prawdopodobnie najlepiej obsłuży podejście hybrydowe. Zadaj więc sobie pytanie: „które z powyższych najlepiej opisuje środowisko mojego projektu?" i pozwól, aby to kierowało wyborem twojego podejścia.

Musisz również wziąć pod uwagę inne ograniczenia wynikające z zasad i kultury twojej organizacji przy podejmowaniu decyzji o najbardziej sensownym podejściu do twojego projektu. Próba sprawienia, aby podejście kaskadowe działało w kulturze charakteryzującej się zwinnością lub podejście zwinne działało w kulturze charakteryzującej się dowodzeniem i kontrolą, spowoduje problemy.

Podejście hybrydowe może być bardziej prawdopodobne, że „się sprzeda" i odniesie sukces.

Manifest Agile, rozszerzony o szersze zastosowanie poza oprogramowaniem, określa cztery deklaracje wartości mające kierować praktykami w stronę zwinnych zachowań. Każdy, kto dąży do pracy w sposób zwinny, powinien cenić:

Koncentrując się na elementach po lewej stronie, przy jednoczesnym uznawaniu wartości tych po prawej.

Chociaż toczy się debata na temat tego, czy pierwotny Manifest w pełni sprawdza się w dzisiejszym świecie – szczególnie w kontekście oprogramowania – deklaracje wartości nadal oferują pomocne wskazówki dla zarządzania projektami. Ma sens opieranie zarządzania projektem zwinnym na elementach po lewej stronie, a zarządzania projektem waterfall na elementach po prawej stronie.

• Ludzie i praca zespołowa: Monitorowanie i wspieranie profesjonalnej dyscypliny oraz współpracy.
• Dostarczanie wartości biznesowej: Skupienie się na wartości, która wspiera potrzeby biznesowe, zamiast odznaczania wymagań procesowych.
• Aktywne zaangażowanie biznesowe: Zapewnienie, by przedstawiciele biznesu pracowali ściśle z zespołem przez cały projekt.
• Spełnianie bieżących potrzeb przy wdrożeniu: Zapewnienie, że rozwiązanie odpowiada rzeczywistym wymaganiom biznesowym w momencie uruchomienia—nawet jeśli te wymagania różnią się od pierwotnego planu.

• Przestrzeganie predefiniowanych procesów: Zapewnienie, że wszyscy stosują się do ustalonych kroków i zatwierdzeń.
• Tworzenie dokumentacji predykcyjnej: Opracowywanie jasnych specyfikacji i sprawdzanie, czy rozwiązanie jest z nimi zgodne.
• Właściwe zatwierdzanie zmian: Walidacja wszystkich zmian w oryginalnej dokumentacji.
• Przestrzeganie planów: Zapewnienie, że plany pozostają dokładne i reagują na zatwierdzone zmiany.

W konfiguracji hybrydowej zarządzanie musi znaleźć odpowiednią równowagę między elementami zwinnej metodologii a metodologią kaskadową. Wymaga to dostosowania, które części każdego podejścia mają największy sens w konkretnym kontekście projektu.

Najbardziej skuteczne podejście do realizacji projektów powinno być kierowane przez kontekst – zarówno charakter pracy, jak i środowisko, w którym projekt będzie funkcjonować. Wystrzegaj się każdego, kto promuje czysto zwinne lub czysto kaskadowe podejście jako uniwersalnie stosowalną receptę na sukces.

Nawiązując po raz ostatni do modelu Cynefin – opisuje stan Aporia (oznaczający impas) lub Confusion i nie jest to dobre miejsce do przebywania. Najprawdopodobniej znajdziesz siebie i swój projekt cierpiącymi w tym miejscu, jeśli nie jesteś w stanie lub nie chcesz dopasować swojego podejścia do projektu do jego kontekstu i środowiska.

Musisz myśleć samodzielnie, analizować kontekst i działać odpowiednio. Postępując w ten sposób, masz największe szanse na przejście z Aporia/Confusion do jednego z innych stanów, gdzie podejście, najprawdopodobniej hybrydowe, zoptymalizuje twoje możliwości sukcesu projektu.