Waterfall vs Agile – jak wybrać metodykę prowadzenia projektu

W poprzedniej części tej serii pisałem o tym, że projekt i proces to dwa różne języki – i że mieszanie ich bez świadomości jest źródłem większości organizacyjnych nieporozumień. Na końcu tekstu, który możesz przeczytać tutaj: https://fireup.pro/pl/blog/u-nas-to-dziala-inaczej, zaproponowałem matrycę: zmienność wymagań kontra powtarzalność działań. Jej dwie prawe ćwiartki – projekt tradycyjny i projekt innowacyjny (zwinny) – to właśnie obszar, którym zajmiemy się dziś.

Waterfall vs Agile to nie wybór między starym a nowym ani między lepszym a gorszym. To dwa narzędzia odpowiadające na dwa różne pytania. Waterfall pyta: co dokładnie chcemy zbudować i jak to zaplanować od początku do końca? Agile pyta: czego się jeszcze musimy nauczyć, żeby dostarczyć właściwą wartość? Wybór między nimi zależy od natury problemu, nie zaś od mody ani przyzwyczajeń zespołu.

Historia waterfall i Agile – skąd się wzięły te metodyki?

Zanim sięgniemy po narzędzie, warto wiedzieć, skąd pochodzi i do czego zostało zaprojektowane. To nie jest historia liniowa i właśnie o to chodzi.

W 1969 roku powstał PMI (Project Management Institute), pierwsza organizacja, która podjęła się standaryzacji zarządzania projektami. Rok później, w 1970 roku, Winston Royce opublikował artykuł opisujący sekwencyjny model wytwarzania oprogramowania, w którym kolejne fazy (analiza, projektowanie, implementacja, testowanie, wdrożenie) następują po sobie jak woda spływająca kaskadą – każda zaczyna się dopiero po zakończeniu poprzedniej.

Co istotne i często przemilczane: w tym samym tekście Royce wprost ostrzegał, że brak podejścia iteracyjnego generuje ogromne ryzyko. Ten model sekwencyjny przyjął się jako standard przemysłowy nie dlatego, że Royce go polecał, ale dlatego, że pasował do logiki dużych organizacji i kontraktów rządowych. Przez dekady cytowano pierwszą część jego wywodu, ignorując zastrzeżenie autora.

W 1996 roku PMI opublikował pierwszą edycję PMBOK (Project Management Body of Knowledge). Ten podręcznik stał się swoistą biblią project managera i usankcjonował waterfall jako dominujący sposób prowadzenia projektów: konkretny rezultat, konkretny czas, założony budżet.

Z kolei w lutym 2001 roku praktycy różnych metodyk (Scrum, Extreme Programming, Crystal i innych) spotkało się w górskim kurorcie Snowbird w stanie Utah i w ciągu dwóch dni sformułowali Manifest Agile. Niektórzy pytają: jak można coś takiego wymyślić w dwa dni? Otóż nie wymyślili. Scrum czy Extreme Programming powstały już w połowie lat 90. Siedemnastu praktyków, wywodzących się z różnych środowisk, postanowiło wspólnie wyrazić przekonanie, że tradycyjne podejście do realizacji projektów nie odpowiada wyzwaniom, z jakimi mierzyli się w swojej codziennej pracy. Manifest nie stworzył zwinności, jedynie nazwał i ujednolicił to, co już działo się w praktyce.

I tu widzę pewien wzorzec: w obu przypadkach najpierw mamy konkretne praktyki, a dopiero potem próbę ich zebrania i standaryzacji. PMI nie wymyślił zarządzania projektami – opisał to, co już działało w przemyśle. Sygnatariusze Manifestu nie wymyślili zwinności – nazwali to, co już działało w ich zespołach. Standaryzacja zawsze przychodzi po praktyce, a nie przed nią.

To ważne z jednego powodu: jeśli obie metodyki wyrosły z realnych potrzeb, a nie z teorii, to żadna z nich nie jest błędem ewolucji. Waterfall nie jest przestarzałym poprzednikiem Agile, który czeka na zastąpienie. To dwa równoległe nurty, które odpowiadają na różne pytania – i oba mają się dobrze tam, gdzie postawiono je we właściwym miejscu.

Co to jest metodyka waterfall?

Waterfall (kaskada) to model prowadzenia projektu zakładający, że wymagania są wystarczająco znane na początku, by zaplanować wszystkie etapy aż do końca. Każda faza (analiza, projektowanie, implementacja, testowanie, wdrożenie) ma swoje wejście, wyjście i warunki odbioru. W kaskadzie zmiana jest wyjątkiem wymagającym formalnej zgody – i nie bez powodu.

Badania IBM z lat 80. pokazały, że koszt naprawy błędu rośnie wykładniczo wraz z fazą, w której zostaje wykryty: błąd znaleziony w fazie analizy kosztuje symboliczną złotówkę, ten sam wykryty po wdrożeniu – nawet stukrotnie więcej. To szacunki, nie prawo fizyki, ale proporcje pozostają aktualne i tłumaczą, dlaczego waterfall tak mocno stawia na kompletność wymagań na wejściu. Jeśli zakładasz, że zmiana jest droga, to naturalną odpowiedzią jest minimalizowanie jej prawdopodobieństwa przez dokładne planowanie z góry.

Podejście kaskadowe sprawdza się, gdy spełniony jest co najmniej jeden z poniższych warunków:

• Stabilne wymagania – systemy regulowane prawem (lotnictwo, farmacja, finanse)
• Wysoki koszt zmiany – budowa mostu, produkcja hardware, centrum danych
• Wymogi dokumentacyjne – wdrożenia z wymogami audytowymi, np. ERP w instytucji finansowej
• Rozproszony zespół – gdy synchronizacja ciągła jest trudna lub niemożliwa

Dobrym przykładem jest branża lotnicza. Wymagania określone przez prawo, ograniczenia wynikające z fizyki, kod pisany jeden do jednego zgodnie z wymogami, zero zaskoczeń. Tu waterfall nie tylko ma sens, ale jest jedyną rozsądną odpowiedzią. Podobnie farmacja czy hardware. Nie można w trakcie produkcji kilku milionów sztuk stwierdzić, że robimy upgrade. To, co już wyprodukowane, jest wyprodukowane i stanowi koszt.

Z drugiej strony waterfall w świecie dynamicznym, bez żadnej z powyższych przesłanek, to w czystej postaci teatr kontroli. Udajemy, że nad czymś panujemy, kiedy zmiany i tak się dzieją. Tam, gdzie koszt pomyłki uzasadnia sztywne planowanie – kaskada ma sens. Gdzie nie – zmuszanie zespołu do formalnych change requestów przy każdej drobnej zmianie to przepis na frustrację i stratę czasu.

Co to jest metodyka Agile?

Agile to podejście do prowadzenia projektu zakładające, że nie wiemy wszystkiego na początku i celowo budujemy tak, by uczyć się po drodze. Zamiast jednego dużego planu mamy ciągłe planowanie. Zamiast dostarczenia wszystkiego na końcu – regularne, przyrostowe dostarczanie wartości.

Manifest Agile z 2001 roku określa cztery fundamentalne wartości. To nie są hasła marketingowe, lecz cztery konkretne wybory, każdy z realnymi konsekwencjami:

• Ludzie i interakcje ponad procesy i narzędzia
• Działające oprogramowanie ponad obszerną dokumentację
• Współpraca z klientem ponad negocjowanie kontraktów
• Reagowanie na zmiany ponad podążanie za planem

Jim Highsmith, jeden z 17 sygnatariuszy Manifestu, opisał istotę zwinności tak: „Metodyki zwinne pozwalają nam tworzyć zmiany i reagować na nie w sposób odzwierciedlający wartość biznesową, którą dostarczamy.” Kluczowe słowo: wartość. Nie szybkość, nie brak dokumentacji.

To jest najczęstsze nieporozumienie, z jakim się spotykam. Manifest nie mówi, że dokumentacja jest zbędna. Mówi, że gdy produkt nie działa, priorytetem jest jego naprawa, a dokumentacja schodzi na drugi plan. Jeśli ktoś mówi „nie dokumentujemy, bo jesteśmy Agile” – to albo żartuje, albo nie rozumie manifestu, albo po prostu mu się nie chce.

Agile ma sens, gdy:

• Wymagania są niejasne lub będą ewoluować
• Koszt zmiany jest stosunkowo niski
• Klient chce i może aktywnie współtworzyć produkt
• Szybkość uczenia się jest ważniejsza niż szybkość dostarczania gotowego produktu
• Rynek jest nieprzewidywalny (startupy, nowe produkty cyfrowe)

Niektórzy myślą, że Agile jest po to, żeby było szybko. Ale nie chodzi o szybkość dostarczania oprogramowania – tylko o szybkość uczenia się. Netflix w 2011 roku podzielił usługę na DVD i streaming, tworząc osobną markę Qwikster. Klienci powiedzieli stanowcze nie. Po trzech tygodniach firma musiała się wycofać. Można tylko przypuszczać, że gdyby przetestowali ten pomysł wcześniej na małej grupie, zaoszczędziliby na późniejszych kampaniach wizerunkowych. To właśnie ta przewaga: szybkość uczenia się, nie szybkość kodowania.

Waterfall vs Agile – 5 kluczowych różnic

Wymiar	Waterfall	Agile
Podejście do planu	Kontrakt – szczegółowy i wiążący od początku	Hipoteza – weryfikowana i doprecyzowywana w toku pracy
Zmiana	Formalny change request; zaburza plan i kosztuje	Trafia do backlogu i jest priorytetyzowana jak każde zadanie
Dostarczanie	Pełny produkt na końcu projektu	Regularnie, iteracyjnie i przyrostowo – każdy inkrement dodaje wartość
Ryzyko	Identyfikowane i zarządzane z góry (dane historyczne, rejestry ryzyk)	Ujawniane stopniowo – każda iteracja odsłania nowe ryzyka do zaadresowania
Rola klienta	Odbiorca – pojawia się przy podpisaniu kontraktu i przy odbiorze	Współtwórca – uczestniczy w przeglądach co iterację, jego feedback kształtuje produkt

Jedna rzecz często pomijana przy tym porównaniu: wybór kolumny to nie jest wybór lepsze czy gorsze. To wybór tego, co najbardziej odpowiada naturze naszego przedsięwzięcia. I nie każdy klient, mówiąc wprost, chce być współtwórcą. Są tacy, którzy mówią: „ja chcę to, a jak to zrobicie, nie chcę nawet wiedzieć.” Z tym też trzeba się liczyć.

Popularne pułapki przy wyborze metodyki

Największe błędy, jakie widzę, nie wynikają ze złej woli. Wynikają z braku zadania właściwego pytania na początku: jak bardzo jesteśmy pewni tego, co chcemy dowieźć, w jakim czasie i jak bardzo jesteśmy usztywnieni regulacjami?

Dobór metodyki przez nawyk, nie przez analizę

To chyba najdroższy wybór – nie finansowo, ale kosztuje najwięcej czasu i energii, bo w ogóle nie jest podejmowany świadomie. Firma od lat prowadzi projekty kaskadowo, przychodzi nowy projekt i wtedy automatycznie: robimy jak zawsze. Po roku okazuje się, że wymagania zmieniały się trzykrotnie, a zespół spędził więcej czasu na procedurze change request niż na samej zmianie.

Cargo kult – forma bez treści

To termin z obserwacji antropologicznych z czasów II wojny światowej. Na Pacyfiku, gdzie stacjonowali Amerykanie, mieszkańcy wysp widzieli jak samoloty przywożą zaopatrzenie dla żołnierzy. Po wojnie, gdy samoloty przestały przylatywać, zaczęli budować z bambusa imitacje lotnisk, pasów startowych i wież kontrolnych, żeby przyciągnąć te towary z powrotem. Wpisz „cargo cult” w wyszukiwarce obrazów – zdjęcia mówią same za siebie.

Organizacje wdrażające Agile bez zrozumienia działają dokładnie tak samo: kopiują zewnętrzną formę (sprinty, daily standup, backlog), nie rozumiejąc po co, i w efekcie mają dużo rytuału, zero zwinności. Wszyscy są tacy zwinni, tylko tej zwinności tak naprawdę nie ma.

Agile jako wymówka do braku planowania

Agile zmienia horyzont planowania, nie eliminuje go. Zwinność w gruncie rzeczy wymaga często wyższej dyscypliny niż kaskada – zamiast jednego raportu na końcu projektu mamy codzienne synchronizacje i przeglądy co iterację.

Kaskada jako wymówka do unikania rozmowy z klientem

Ta wymówka nie zastępuje rozmowy, tylko odkłada ją w czasie i powiększa rachunek. W modelu tradycyjnym klient pojawia się dwa razy: przy podpisaniu kontraktu i przy odbiorze. Wszystko pomiędzy to praca za zamkniętymi drzwiami. Czasem to zaleta – brak zmian. Częściej ryzyko – bo dużo możemy nie odkryć.

Czy sprint to mini-waterfall?

To pytanie pojawia się regularnie i rozumiem, skąd się bierze. Sprint ma cel, oczekiwany rezultat, oznaczony początek i koniec – pozornie więc spełnia kilka cech projektu. Ale różnic jest co najmniej tyle samo. W kaskadzie jakość jest osobnym etapem, w sprincie jest wbudowana w proces – analiza, implementacja i weryfikacja dzieją się równolegle, nie sekwencyjnie. Poza tym kolejny sprint to zazwyczaj rozwój tego samego produktu, nie nowe przedsięwzięcie – brakuje mu cechy unikalności, którą powinien mieć projekt. Skłaniam się więc ku odpowiedzi: nie, sprint to nie mini-waterfall. To jednak inna pułapka myślowa – mieszanie pojęć, które prowadzi do błędnych wniosków o tym, czym zwinność w ogóle jest.

Mieszanie podejść bez świadomości

Hybryda może być najmądrzejszym wyborem albo największym chaosem – zależnie od tego, czy ktoś ją świadomie zaprojektował, czy tylko zgodzono się na nią przez brak sprzeciwu. Widziałem to wiele razy: projekt startuje zwinnie, mamy sprinty, backlog, daily. W połowie klient naciska na datę końcową i stały zakres. Backlog się zamraża, sprinty stają się etapami, nikt tego nie nazywa, nikt nie zmienia kontraktu, nikt nie informuje zespołu. Efekt: chaos metodyczny, chaos ról, Scrum Master staje się poganiaczem zamiast wspierającym edukatorem.

Fixed price Agile – zwinność w sztywnym kontrakcie

Jeszcze jako freelancer, gdy rozmawiałem z trudnym klientem, rysowałem trójkąt. W rogach pisałem: szybko, tanio, dobrze – i mówiłem: wybierz dwa. Pewnie w takich sytuacjach było widać, że nie jestem dobrym sprzedażowcem – ale trójkąt robił swoje. Agile i Fixed Price nie są sprzeczne, ale wymagają świadomego przeprojektowania kontraktu. 

W kaskadzie logika jest prosta: ustalamy zakres, z niego wynika czas i budżet. W Agile jest odwrotnie: czas i budżet są stałe (iteracje mają określony rytm i koszt), a zakres zmienia się wedle potrzeb i priorytetów. Jeśli klient tego nie rozumie – będzie czuł, że traci kontrolę. Jeśli rozumie – zyskuje coś cenniejszego: pewność, że budżet idzie na to, co rzeczywiście dowozi wartość.

Sprawdzone podejścia:

• Stały budżet, zmienny zakres – klient określa budżet, zakres jest priorytetyzowany iteracyjnie
• Faza Discovery poza kontraktem – odkrycie wymagań przed podpisaniem głównego kontraktu
• Time & Material z górnym limitem – elastyczność przy zachowanym caps na całkowity koszt

Matryca wyboru: waterfall, Agile czy hybryda?

Moje ulubione narzędzie diagnostyczne to dwuwymiarowa matryca. Nie da ona gotowej odpowiedzi – żadne narzędzie jej nie da – ale pomoże zadać właściwe pytanie. A to właśnie od właściwego pytania zaczyna się świadomy wybór metodyki. Zanim więc zdecydujesz, oceń dwie zmienne:

Pierwsza zmienna: jak bardzo znane są wymagania – od niejasnych do precyzyjnie spisanych. Druga: jak kosztowna jest zmiana – od taniej do bardzo drogiej.

	Niska zmienność wymagań	Wysoka zmienność wymagań
Wysoki koszt zmiany	Waterfall	Hybryda z silną kontrolą zmian
Niski koszt zmiany	Agile lub waterfall – wybór dowolny	Agile

Znane wymagania, wysoki koszt zmiany – waterfall. To przestrzeń precyzyjnego planowania i kontroli. Wiemy, co chcemy zbudować, a każda zmiana w trakcie jest na tyle kosztowna, że opłaca się poświęcić więcej czasu na analizę z góry.

Niejasne wymagania, niski koszt zmiany – Agile. To świat iteracji i uczenia się. Nie wiemy jeszcze dokładnie, co chcemy zbudować, ale możemy to odkrywać krok po kroku bez ponoszenia wysokich kosztów każdej korekty.

Znane wymagania, niski koszt zmiany – dowolność. Obie metodyki zadziałają. Wybór zależy od preferencji zespołu, kultury organizacji i charakteru klienta – nie od natury problemu.

Niejasne wymagania, wysoki koszt zmiany – hybryda z silną kontrolą zmian. Najtrudniejsza kombinacja. Nie wiemy jeszcze wszystkiego, ale każda pomyłka boli. Wymaga świadomego zarządzania: iteracyjnego odkrywania wymagań przy jednoczesnym rygorze decyzji o zmianie.

Ćwiartka ze znanymi wymaganiami i niskim kosztem zmiany to też może być naturalna granica, gdzie projekt zaczyna przechodzić w proces – ale tylko wtedy, gdy dochodzi trzeci element: powtarzalność. Jeśli robimy to samo wielokrotnie i zależy nam na identycznym rezultacie za każdym razem, mówimy już o czymś innym niż projekt. Pisałem o tym szerzej w artykule Projekt czy proces – czym się różnią i co wybrać?

Dobór metodyki to w gruncie rzeczy problem diagnostyczny. Zanim sięgniemy po narzędzie, musimy wiedzieć, z czym mamy do czynienia – bo to natura problemu powinna dyktować wybór, nie nawyk ani moda. Dobry lekarz nie przepisuje lekarstwa przed badaniem.

Trzy rzeczy, które warto zapamiętać:

• Diagnoza przed wyborem. Matryca wymagania / koszt zmiany to minimum, od którego warto zacząć.
• Obie strony mają rację – w odpowiednim kontekście. Ani waterfall nie jest reliktem, ani Agile nie jest panaceum.
• Największe ryzyko to brak świadomości. Kult cargo, nawykowy dobór metodyki, nienazwane hybrydy – to nie zła wola, to brak zatrzymania się i zadania pytania: dlaczego właśnie tak?

Artykuł powstał na podstawie wewnętrznego szkolenia z cyklu zarządzania projektami prowadzonego w fireup.pro – miejscami zachowuje rytm języka mówionego i to celowy zabieg. To druga część serii – w pierwszej omówiłem różnicę między projektem a procesem, w kolejnej przyjrzymy się konkretnym frameworkom: Scrum, Kanban i podejściom do skalowania.