Modele wytwarzania oprogramowania: kiedy wybrać model kaskadowy, V-model, spiralny, Agile, a kiedy hybrydę?

Program manager w firmie ubezpieczeniowej wymienia system likwidacji szkód, który działa od piętnastu lat. Na zapytanie ofertowe odpowiada trzech dostawców. Pierwszy proponuje Scrum w rozliczeniu time and materials, z dwutygodniowymi sprintami. Drugi — stałą cenę, szczegółową specyfikację i jedno wdrożenie za osiemnaście miesięcy. Trzeci — trzymiesięczną fazę discovery, potem sprinty, a na końcu formalny etap odbioru prowadzony przez dział compliance. Każdy dostawca jest przekonany, że jego model jest właściwy. Program manager musi zdecydować, które ryzyko firma naprawdę chce ponosić.

To jest prawdziwe pytanie stojące za wyborem modelu wytwarzania oprogramowania. Nie chodzi o „Agile czy Waterfall” jako kwestię gustu. Chodzi o to, kiedy dowiesz się, co poszło nie tak, kto za to zapłaci i ile dowodów potrzebujesz po drodze. Ten sam zespół może odnieść sukces w jednym modelu i ponieść porażkę w innym — przy tym samym projekcie.

Poniżej porównujemy siedem modeli, z którymi program managerowie spotykają się w praktyce: kaskadowy, V-model, przyrostowy i iteracyjny, spiralny, RAD i prototypowanie, frameworki zwinne oraz hybrydy. Przy każdym pokazujemy, skąd się wziął, jakim ryzykiem zarządza i gdzie przestaje działać. Na końcu znajdziesz macierz decyzyjną, którą możesz zastosować do własnego projektu.

Czym jest model wytwarzania oprogramowania i dlaczego jego wybór ma znaczenie?

Model wytwarzania oprogramowania — nazywany też modelem SDLC albo modelem procesu — określa kolejność, w jakiej zespół przechodzi przez etapy cyklu życia oprogramowania: wymagania, projekt, budowę, testy, wdrożenie i utrzymanie. Odpowiada na trzy pytania: czy etapy wykonuje się raz, czy wielokrotnie, jak długo trwa jeden cykl i kiedy działające oprogramowanie po raz pierwszy trafia do prawdziwych użytkowników.

W polskich zapytaniach ofertowych pojęcia „model”, „metodyka” i „metodologia” bywają używane zamiennie, co rodzi nieporozumienia. Warto je rozdzielić. Model opisuje kształt cyklu — sekwencyjny, przyrostowy, iteracyjny, spiralny. Metodyka lub framework, na przykład Scrum, PRINCE2 czy Kanban, opisuje konkretne role, wydarzenia i artefakty, którymi ten cykl się realizuje. Ten sam model iteracyjny można prowadzić w Scrumie albo w Kanbanie, a ten sam PRINCE2 da się połączyć z przyrostowym dostarczaniem. Pytając dostawcę o „metodykę”, pytaj więc o oba poziomy.

Wybór ma znaczenie, bo każdy model przesuwa moment prawdy. W modelu sekwencyjnym organizacja dowiaduje się, czy wymagania były trafne, podczas testów akceptacyjnych — często rok lub więcej po ich spisaniu. W modelu iteracyjnym dowiaduje się tego co kilka tygodni, płacąc za to mniejszą pewnością co do ostatecznego zakresu i kosztu na starcie. Żadna opcja nie jest darmowa. Za późne odkrycie płacisz poprawkami, za wczesne — mniej przewidywalnym planem.

O właściwym wyborze najbardziej decydują trzy cechy projektu:

• Stabilność wymagań — jak prawdopodobne jest, że to, co specyfikujesz dziś, będzie nadal trafne w dniu wdrożenia.
• Koszt późnej zmiany — niski w aplikacji webowej wdrażanej codziennie, bardzo wysoki w oprogramowaniu sterownika w samochodzie czy certyfikowanym wyrobie medycznym.
• Wymagania dowodowe — ile udokumentowanych dowodów weryfikacji wymaga regulator, audytor lub klient.

Czwarty czynnik, często pomijany, dopóki nie zaboli, to umowa. Model wytwarzania i model rozliczeń muszą do siebie pasować. Wracamy do tego w osobnej sekcji, bo właśnie tu wiele dobrze prowadzonych projektów kończy się sporem.

Jak działa model kaskadowy i kiedy nadal jest właściwym wyborem?

Model kaskadowy (waterfall) prowadzi przez etapy w stałej kolejności: wymagania, analiza, projekt, kodowanie, testy i eksploatacja. Każdy etap się kończy, zostaje zatwierdzony i przekazuje swój wynik następnemu. Fazy, zalety i wady opisaliśmy szczegółowo w przewodniku model kaskadowy (waterfall) — kiedy go stosować. Tutaj skupiamy się na porównaniu z alternatywami.

Model zwykle wywodzi się z artykułu Winstona Royce’a z 1970 roku „Managing the Development of Large Software Systems”. Ironia jest dobrze udokumentowana: Royce narysował sekwencyjny diagram, po czym napisał, że taka realizacja „jest ryzykowna i zaprasza porażkę”, bo testy na końcu są pierwszym momentem, w którym czasy działania, pamięć i interfejsy są doświadczane, a nie tylko analizowane. Zalecał sprzężenie zwrotne między etapami, wczesne prototypowanie i wykonanie pracy dwa razy. Branża przejęła rysunek i pominęła ostrzeżenia.

Model kaskadowy nadal ma swoje miejsce w konkretnych warunkach:

• Stabilne, dobrze rozumiane wymagania — raport regulacyjny o stałym formacie, migracja znanego systemu na nową platformę, wymiana komponentu o jasno zdefiniowanym interfejsie.
• Wysoki koszt późnej zmiany — gdy sprzęt, certyfikacja lub fizyczne wdrożenie uniemożliwiają częste wydania.
• Umowa o stałej cenie i stałym zakresie — gdy obie strony potrzebują kompletnej specyfikacji, żeby uzgodnić cenę.
• Rozproszona odpowiedzialność — gdy różne organizacje odpowiadają za różne etapy, a przekazania muszą być formalne.

W Polsce do tej listy często dochodzą zamówienia publiczne. Postępowania prowadzone według Prawa zamówień publicznych wymagają opisu przedmiotu zamówienia przed wyborem wykonawcy i często opierają się na wynagrodzeniu ryczałtowym, co naturalnie ciąży ku modelowi sekwencyjnemu — nawet gdy sam projekt lepiej znosiłby podejście iteracyjne.

Słabość modelu kaskadowego jest równie konkretna. Jeśli wymagania są błędne albo się zmieniają, koszt pojawia się na końcu, gdy jest najwyższy, a czasu najmniej. W produktach, których użytkowników jeszcze nie rozumiesz, to wada strukturalna, a nie problem zarządczy.

Co dodaje V-model i dlaczego stosują go branże regulowane?

V-model to model sekwencyjny złożony na pół. Lewe ramię schodzi przez wymagania, projekt systemu, architekturę i projekt szczegółowy. Na dole jest kodowanie. Prawe ramię wspina się z powrotem przez testy jednostkowe, integracyjne, systemowe i akceptacyjne — a każdy poziom testów jest sparowany z poziomem projektu naprzeciwko. Testy akceptacyjne weryfikują wymagania, systemowe — projekt systemu, integracyjne — architekturę, jednostkowe — projekt szczegółowy.

W tym parowaniu tkwi cała istota modelu. Przypadki testowe planuje się w momencie tworzenia każdego artefaktu projektowego, a nie po napisaniu kodu, a każde wymaganie da się powiązać z testem, który je potwierdza. Dla audytora ta identyfikowalność jest cenniejsza niż jakikolwiek pojedynczy test.

Najbardziej znaną formalną wersją jest niemiecki V-Modell. Rozwijany od 1986 roku przez IABG na zlecenie federalnego ministerstwa obrony, w 1991 roku stał się obowiązkowy w projektach obronnych, a w 1992 roku objął cywilną administrację federalną. V-Modell 97 był standardem dla federalnych systemów IT, a w 2005 roku zastąpił go V-Modell XT — modułowy i dopuszczający dostosowanie przyrostowe oraz zwinne.

Dziś V-model jest strukturą odniesienia w oprogramowaniu motoryzacyjnym. Zarówno ISO 26262 (bezpieczeństwo funkcjonalne pojazdów drogowych), jak i Automotive SPICE — którego wersję 4.0 VDA opublikowało w 2023 roku — opisują wytwarzanie jako lewą stronę wymagań i projektu oraz prawą stronę weryfikacji od poziomu jednostki do poziomu systemu. Dostawca, który nie potrafi pokazać tej struktury, będzie miał problem podczas oceny.

Częstym nieporozumieniem jest przekonanie, że inne branże regulowane wymagają V-modelu. Nie wymagają. IEC 62304, norma dla oprogramowania wyrobów medycznych, wprost stwierdza, że „nie narzuca konkretnego modelu cyklu życia”, a jej załącznik B podaje jako przykłady strategię kaskadową, przyrostową i ewolucyjną. Raport AAMI TIR45 opisuje, jak zespoły zwinne mogą przyrostowo wytwarzać wymagane dowody. Regulatorzy wymagają planowania, identyfikowalności i dowodów weryfikacji — V-model to jeden wygodny sposób ich dostarczenia, ale nie jedyny.

Jak modele przyrostowe i iteracyjne zmniejszają ryzyko?

Wytwarzanie przyrostowe i iteracyjne często wymienia się razem, ale rozwiązują różne problemy.

Model przyrostowy dzieli system na części dostarczane kolejno, z których każda dodaje użyteczną funkcjonalność. Pierwszy przyrost może obsługiwać rejestrację szkód, drugi — ich ocenę, trzeci — wypłaty. Wymagania dla całego systemu mogą być znane z góry; etapowane jest dostarczanie. Korzyścią jest wcześniejsza wartość i wcześniejsza informacja zwrotna z realnego użycia.

Model iteracyjny powtarza cały cykl — analizę, projekt, budowę, testy — dla tego samego obszaru, za każdym razem go ulepszając. Pierwsza iteracja modułu oceny szkód może być surowa, trzecia gotowa do produkcji. Korzyścią jest uczenie się: każde przejście poprawia to, co poprzednie zrobiło źle.

W praktyce większość współczesnych podejść jest jednocześnie iteracyjna i przyrostowa — podobnie jak wszystkie frameworki zwinne. Zanim Agile zyskał nazwę, Rational Unified Process (RUP) sformalizował to połączenie w czterech fazach — rozpoczęcia, opracowania, konstrukcji i przekazania — z których każda składała się z iteracji.

Częstym pierwszym przyrostem jest minimalny produkt — najmniejsze wydanie, które pozwala prawdziwym użytkownikom sprawdzić kluczowe założenie. MVP nie jest prototypem: działa na produkcji, przetwarza prawdziwe dane i trzeba go utrzymywać. Dobre określenie jego zakresu to jedna z najcenniejszych decyzji program managera, bo wszystko, czego MVP nie zawiera, staje się opcją, a nie zobowiązaniem.

Ryzyko, które te modele zmniejszają, to ryzyko integracji i założeń. Zamiast jednej dużej integracji na końcu system jest integrowany i testowany wiele razy. Zamiast jednego zestawu założeń weryfikowanego przy odbiorze założenia są sprawdzane przy każdym przyroście. Ceną jest dyscyplina architektoniczna: bez solidnej architektury i testów automatycznych każdy nowy przyrost psuje poprzednie, a model degeneruje się w nieustanne poprawki.

Czym jest model spiralny i kiedy wytwarzanie sterowane ryzykiem jest warte narzutu?

Barry Boehm opisał model spiralny w 1986 roku w ACM SIGSOFT Software Engineering Notes, a szerszemu gronu przedstawił go w 1988 roku w IEEE Computer. Jego cechą definiującą jest sterowanie ryzykiem: każda pętla spirali zaczyna się od zidentyfikowania największych pozostałych ryzyk i dobiera działania, które je ograniczą.

Każda pętla przechodzi przez cztery ćwiartki: określenie celów i ograniczeń, ocenę alternatyw i redukcję ryzyk, wytworzenie i weryfikację kolejnego poziomu produktu oraz zaplanowanie następnej pętli. Jeśli największym ryzykiem jest niejasny interfejs użytkownika, pętla buduje prototyp. Jeśli wydajność — test wydajnościowy. Jeśli wymagania są dobrze rozumiane, pętla może wyglądać jak mała kaskada. Spirala jest w istocie modelem do wybierania modeli.

Model spiralny jest wart swojego narzutu, gdy:

• projekt jest duży, kosztowny i nowatorski — nowa platforma, nowa technologia, nowy rynek;
• porażka jest kosztowna, a organizacja potrzebuje jawnych decyzji „kontynuujemy / przerywamy” po każdej pętli;
• jest czas na formalną analizę ryzyka i ludzie, którzy potrafią ją dobrze przeprowadzić.

W małych projektach rzadko się sprawdza. Planowanie i analiza ryzyka w każdej pętli mogą kosztować więcej niż ryzyka, które usuwają. Model w dużym stopniu zależy też od kompetencji osób oceniających ryzyko: spirala prowadzona przez zespół, który ryzyko niedoszacowuje, to po prostu wolna kaskada.

Trwałym wkładem modelu spiralnego jest pytanie, a nie diagram. „Co może najbardziej zaszkodzić temu projektowi i jaki jest najtańszy sposób, żeby sprawdzić to teraz?” — to pytanie każdy program manager powinien zadawać na każdej bramce etapowej, niezależnie od stosowanego modelu.

Kiedy RAD i prototypowanie mają sens?

Rapid Application Development (RAD), spopularyzowany przez Jamesa Martina na początku lat 90., zastąpił długą specyfikację szybkimi cyklami warsztatów z użytkownikami, prototypowania i budowy przy użyciu wydajnych narzędzi. Jego współczesnymi następcami są platformy low-code i duża część dzisiejszego wytwarzania narzędzi wewnętrznych. RAD najlepiej sprawdza się w aplikacjach biznesowych z jasno określoną grupą użytkowników, umiarkowaną złożonością techniczną i użytkownikami, którzy co tydzień mogą dawać informację zwrotną.

Prototypowanie jest węższe: budowa modelu systemu — klikalnych makiet, jednorazowego proof of concept albo prototypu ewolucyjnego, który wyrasta na produkt — żeby czegoś się dowiedzieć przed podjęciem zobowiązań. Technikę opisujemy w artykule o rapid prototypingu.

Dwie zasady oddzielają udane prototypowanie od kosztownego zamieszania:

1. Z góry zdecyduj, czy prototyp jest jednorazowy, czy ewolucyjny. Prototyp jednorazowy optymalizuje szybkość uczenia się i musi zostać wyrzucony. Ewolucyjny musi być budowany w jakości produkcyjnej od pierwszego dnia. Traktowanie jednorazowego prototypu jako pierwszego wydania to jedno z najczęstszych źródeł długu technicznego.
2. Prototypuj najbardziej ryzykowną część, a nie najłatwiejszą. Piękny prototyp ekranu logowania nic ci nie powie. Surowy prototyp silnika obliczeń albo integracji ze starym systemem centralnym powie, czy projekt jest wykonalny.

RAD i prototypowanie mają trudności w dużych systemach ze złożonymi integracjami, ostrymi wymaganiami niefunkcjonalnymi albo z użytkownikami, którzy nie mogą poświęcić czasu. Bez zaangażowania użytkowników szybkie cykle produkują szybkie błędy.

Czym różnią się Agile, Scrum i Kanban jako modele wytwarzania?

W lutym 2001 roku siedemnastu praktyków spotkało się w Snowbird w stanie Utah i spisało Manifest Zwinnego Wytwarzania Oprogramowania: cztery wartości i dwanaście zasad. Agile nie jest pojedynczym modelem, tylko rodziną podejść, które łączy iteracyjno-przyrostowe dostarczanie, bliska współpraca z biznesem i przedkładanie reagowania na zmianę nad realizację planu.

Dwa najpopularniejsze frameworki różnią się organizacją przepływu pracy:

• Scrum działa w stałych przedziałach czasu (sprintach do miesiąca, zwykle dwutygodniowych), z trzema odpowiedzialnościami — Product Owner, Scrum Master i Developerzy — oraz zdefiniowanymi wydarzeniami. Scrum Guide 2020, opublikowany przez Kena Schwabera i Jeffa Sutherlanda w listopadzie 2020 roku, wprowadził Cel Produktu i przypisał każdemu artefaktowi zobowiązanie: Cel Produktu dla backlogu, Cel Sprintu dla sprintu i Definicję Ukończenia dla przyrostu. Scrum pasuje do rozwoju produktu ze stabilnym zespołem i backlogiem, który można repriorytetyzować co kilka tygodni.
• Kanban nie ma sprintów. Praca płynie w sposób ciągły przez zwizualizowane etapy z limitami pracy w toku, a zespół optymalizuje czas realizacji. Kanban pasuje do utrzymania, wsparcia, zespołów platformowych i każdej pracy, która napływa w nieprzewidywalny sposób.

Według 17. edycji raportu State of Agile firmy Digital.ai Scrum pozostawał najpopularniejszym frameworkiem na poziomie zespołu, stosowanym przez 63% respondentów pracujących zwinnie. Edycja 18. przestała pytać o frameworki zespołowe i wykazała, że 48% respondentów stosuje hybrydowe modele dostarczania, a 26% — autorskie.

Do skalowania na wiele zespołów służą frameworki takie jak SAFe, LeSS czy Nexus, które opisujemy w haśle słownika o metodykach skalowania Agile. Dodają warstwy koordynacji i warto je wprowadzać dopiero wtedy, gdy prosta koordynacja między zespołami wyraźnie zawodzi — a nie jako punkt startowy.

Współczesne zespoły zwinne rzadko poprzestają na samym frameworku. Praktyki DevOps — ciągła integracja, testy automatyczne i ciągłe dostarczanie — skracają drogę od ukończonego elementu backlogu do oprogramowania na produkcji z tygodni do godzin. Zmieniają też ekonomię wyboru modelu: gdy wydanie nie kosztuje prawie nic, argument za dużymi, rzadkimi wydaniami słabnie, a koszt późnej zmiany spada w każdym modelu, także sekwencyjnym. Projekt kaskadowy z automatycznym zestawem testów i potokiem wdrożeniowym jest dużo mniej kruchy niż taki, który testuje się ręcznie na końcu. Porównując dostawców, pytaj nie tylko o proponowany model, ale też o to, jaka część ich procesu dostarczania jest zautomatyzowana.

Główny warunek Agile bywa niedoceniany: dostępny przedstawiciel biznesu z prawem do decyzji. Bez Product Ownera, który co tydzień podejmuje decyzje, sprinty produkują przyrosty, których nikt nie weryfikuje, a model traci jedyną realną przewagę nad planem sekwencyjnym.

Czym są modele hybrydowe, takie jak Water-Scrum-Fall, i czy działają?

W 2011 roku analityk Forrestera Dave West opisał to, co widział w większości organizacji, jako Water-Scrum-Fall: kaskadową fazę wstępną z planowaniem, budżetowaniem i wymaganiami; wytwarzanie w sprintach w stylu Scrum; oraz kaskadowy etap wydania z formalnymi testami, zatwierdzeniami i wdrożeniem. Przedstawił to jako rzeczywistość Agile w większości firm, a nie jako rekomendację.

Dekadę później hybrydy są normą, a nie wyjątkiem, co potwierdzają dane State of Agile. Pytanie nie brzmi, czy łączyć modele, tylko czy połączenie jest świadome. Działające hybrydy mają trzy wspólne cechy:

• Ograniczona w czasie faza wstępna. Faza discovery trwająca tygodnie, a nie miesiące, która dostarcza wizję, zarys architektury, spriorytetyzowany backlog i widełki budżetu — a nie kompletną specyfikację. Tu jest miejsce na modele procesów, takie jak diagramy BPMN, które opisujemy w osobnym przewodniku.
• Iteracyjna budowa z prawdziwymi przyrostami. Sprinty kończą się zintegrowanym, przetestowanym oprogramowaniem, a nie stanem „programowanie skończone, testy później”.
• Faza końcowa zautomatyzowana, a nie biurokratyczna. Zatwierdzenie wydania opiera się na dowodach wytwarzanych na bieżąco — testach automatycznych, identyfikowalności, skanach bezpieczeństwa — a nie na wielomiesięcznej fazie testów po ostatnim sprincie.

Hybrydy zawodzą, gdy dominują w nich elementy kaskadowe: sześciomiesięczna specyfikacja, potem sprinty, które tylko ją implementują, a na końcu trzymiesięczne testy, które odkrywają problemy. To model kaskadowy z dodatkowymi spotkaniami — wolniejszy niż którykolwiek z czystych modeli.

Użytecznym wariantem w pracy regulowanej jest V-model na poziomie systemu, Agile na poziomie oprogramowania: wymagania, architektura systemu i końcowa walidacja podlegają strukturze V z formalnymi bramkami, a komponenty oprogramowania powstają iteracyjnie wewnątrz tej ramy. Tak pracuje wiele zespołów w motoryzacji i wyrobach medycznych.

Jak model wytwarzania wpływa na umowę i budżet?

Model wytwarzania i model rozliczeń muszą do siebie pasować, inaczej umowa będzie walczyć z procesem. Najczęstsze niedopasowanie to umowa o stałej cenie połączona z wytwarzaniem zwinnym i otwartym backlogiem. Klient oczekuje stałego zakresu za stałą cenę, dostawca — repriorytetyzacji w każdym sprincie, a każda zmiana staje się negocjacją.

Logika jest prosta. Stała cena wymaga stałego zakresu, a stały zakres — stabilnych wymagań, czyli warunków, w których dobrze działają modele sekwencyjne. Jak wyjaśniamy w artykule o tym, kto naprawdę płaci za przeniesienie ryzyka w modelu fixed price, dostawca wycenia niepewność jako ryzyko i dolicza ją do ceny. Im mniej stabilne wymagania, tym wyższa premia za ryzyko.

Typowe połączenia, które działają:

Model wytwarzania	Pasujący model rozliczeń	Co jest stałe	Co jest zmienne
Kaskadowy, V-model	Stała cena, płatności za kamienie milowe	Zakres, cena, termin	Niewiele — zmiany przez procedurę zmian
Przyrostowy	Stała cena za przyrost	Zakres i cena bieżącego przyrostu	Zakres kolejnych przyrostów
Spiralny	Budżet przyznawany etapami	Budżet na pętlę	Wszystko po najbliższej decyzji „kontynuujemy / przerywamy”
Agile (Scrum, Kanban)	Time and materials lub budżet z limitem przy stałym zespole	Zespół, rytm, pułap budżetu	Zakres
Hybryda	Discovery za stałą cenę, potem T&M lub dostarczanie z limitem	Wyniki i cena discovery	Zakres dostarczania w widełkach budżetu

Przy wytwarzaniu zwinnym budżet z limitem, stały zespół i zmienny zakres często dają klientowi przewidywalność, której potrzebuje, bez udawania, że zakres jest znany. Postęp mierzy się działającymi przyrostami, a spriorytetyzowany backlog pokazuje, co się nie zmieści. O tym, jak szacować pracę tak, żeby takie widełki były wiarygodne, piszemy w artykule o story pointach jako teatrze decyzyjnym.

Znaczenie ma też model zaangażowania ludzi. Zespół zarządzany przez dostawcę, dostarczający stały zakres, sam niesie ryzyko dostarczenia. Specjaliści, którzy dołączają do Twojego zespołu w modelu staff augmentation, pracują w modelu, który prowadzisz Ty — więc model, backlog i odbiór przyrostów pozostają Twoją odpowiedzialnością. Żadne podejście nie jest ogólnie lepsze, ale model wytwarzania musi jasno mówić, kto planuje, kto priorytetyzuje i kto odbiera.

Niezależnie od wybranego modelu zapisz go w umowie wprost: rytm pracy, kryteria odbioru przyrostów, sposób obsługi zmian i to, kto ma prawo zmieniać priorytety. Umowa, która milczy o modelu, pozwala każdej stronie założyć własny.

Co mówią dane o skuteczności różnych modeli?

Najczęściej cytowana liczba pochodzi od Standish Group. W szeroko przytaczanym podsumowaniu danych z raportu CHAOS 2020 42% projektów zwinnych zakończyło się sukcesem wobec 13% projektów kaskadowych, a porażką zakończyło się 11% projektów zwinnych i 59% kaskadowych. Standish definiuje sukces wąsko: w terminie, w budżecie i z zadowalającym rezultatem.

Te liczby są użytecznym sygnałem, ale zanim trafią do prezentacji dla komitetu sterującego, potrzebują trzech zastrzeżeń:

1. Populacje się różnią. Organizacje wybierają model kaskadowy dla dużych, złożonych projektów sterowanych umową, a Agile — dla pracy produktowej z zaangażowanymi interesariuszami. Model i typ projektu są skorelowane, więc porównanie nie jest równoważne.
2. Definicje kształtują wyniki. Projekt dostarczony w terminie z ograniczonym zakresem liczy się inaczej niż projekt z pełnym zakresem dostarczony z opóźnieniem. Projekty zwinne z założenia zmieniają zakres, co poprawia ich wyniki w miarach terminu i budżetu.
3. Metodykę krytykowano. Badacze od lat kwestionują dobór próby i definicje Standish. Traktuj te liczby jako orientacyjne, a nie jako prawo.

To, co dane konsekwentnie potwierdzają, jest mniej efektowne i bardziej użyteczne: krótsze pętle informacji zwrotnej zmniejszają koszt pomyłki. Mniej ważne jest, czy uzyskasz je ze sprintów, przyrostów, prototypów czy pętli spirali, niż to, czy uzyskasz je w ogóle. Projekt kaskadowy z wczesnymi prototypami i etapową integracją jest mniej ryzykowny niż projekt scrumowy, którego przyrostów nikt nie pokazuje użytkownikom.

Jak wybrać model wytwarzania oprogramowania dla swojego projektu?

Żaden model nie jest najlepszy w ogóle. Poniższa macierz podsumowuje, kiedy który pasuje. Oceń swój projekt w każdym wierszu i szukaj kolumny, która zgadza się najczęściej. Jeśli dwie kolumny remisują, zwykle wygrywa hybryda.

Cecha projektu	Kaskadowy	V-model	Przyrostowy / iteracyjny	Spiralny	RAD / prototypowanie	Agile (Scrum, Kanban)	Hybryda
Stabilność wymagań	Wysoka	Wysoka	Średnia	Niska do średniej	Niska	Niska	Średnia
Koszt późnej zmiany	Wysoki	Bardzo wysoki	Średni	Wysoki	Niski	Niski	Średni do wysokiego
Dowody dla regulatora	Umiarkowane	Silne (ISO 26262, ASPICE)	Umiarkowane	Silne na bramkach	Słabe	Możliwe przy dyscyplinie (IEC 62304, TIR45)	Silne na poziomie systemu
Nowatorstwo techniczne	Niskie	Niskie do średniego	Średnie	Wysokie	Średnie	Średnie do wysokiego	Średnie do wysokiego
Wielkość projektu	Mała do dużej	Średnia do dużej	Średnia do dużej	Duża	Mała do średniej	Dowolna, skalowana SAFe lub LeSS	Średnia do dużej
Dostępność biznesu	Niska wystarczy	Niska wystarczy	Średnia	Średnia	Bardzo wysoka	Wysoka (Product Owner)	Średnia do wysokiej
Pasujący model umowy	Stała cena	Stała cena, kamienie milowe	Stała cena za przyrost	Budżet etapowy	T&M	T&M lub budżet z limitem	Discovery za stałą cenę plus T&M
Czas do pierwszej wartości	Późno	Późno	Wcześnie	Średnio	Bardzo wcześnie	Wcześnie	Wcześnie do średnio

Pięć pytań doprecyzowuje wybór:

1. Na ile jesteśmy pewni, że dzisiejsze wymagania będą trafne w dniu wdrożenia? Jeśli uczciwa odpowiedź brzmi „niezbyt”, unikaj czystego modelu sekwencyjnego.
2. Ile kosztuje nas zmiana po wydaniu? Jeśli wydanie wymaga ponownej certyfikacji albo zmian sprzętowych, planuj mniej wydań, za to lepiej zweryfikowanych.
3. Kto potrzebuje dowodów i jakich? Przypisz wymagania regulacyjne i audytowe do artefaktów, zanim wybierzesz ceremonie.
4. Czy biznes da nam decydenta co tydzień? Jeśli nie, Agile będzie działać poniżej oczekiwań, a model z mniejszą liczbą większych punktów informacji zwrotnej będzie bezpieczniejszy.
5. Jaką umowę podpiszemy? Model wytwarzania i model rozliczeń wybieraj razem, nigdy jeden po drugim.

Zastosujmy macierz do ubezpieczyciela ze wstępu. Wymagania co do reguł likwidacji szkód są w dużej mierze znane, bo wynikają z ogólnych warunków ubezpieczenia i przepisów — ale sposób pracy likwidatorów w nowym systemie i integracje z partnerami, takimi jak warsztaty czy rzeczoznawcy, są niepewne. Koszt późnej zmiany jest średni: system nie jest certyfikowany jak wyrób medyczny, ale każda zmiana reguł wymaga uzgodnienia z działem compliance. Regulator oczekuje udokumentowanej kontroli nad zmianami i testami. Biznes może oddelegować Product Ownera, ale tylko na część etatu. Umowa ma mieć przewidywalny budżet, bo zatwierdza go zarząd.

Taki profil nie wskazuje czystego modelu. Czysty Scrum w rozliczeniu T&M zostawia zarząd bez widełek budżetu i dział compliance bez jasnej ścieżki dowodowej. Stała cena z jednym wdrożeniem za osiemnaście miesięcy przesuwa całe ryzyko sposobu pracy likwidatorów na sam koniec projektu. Najbliżej profilu jest trzecia oferta: krótka faza discovery za stałą cenę, która dostarcza model procesów, architekturę i widełki budżetu; następnie przyrosty wdrażane kolejno dla kolejnych typów szkód, rozliczane w budżecie z limitem; a w tle zautomatyzowane testy i identyfikowalność wymagań, na których opiera się odbiór przez compliance. Warunek jest jeden — faza discovery musi trwać tygodnie, a nie trzy miesiące, i skończyć się decyzją, a nie kolejną wersją specyfikacji.

Jak zmienić model w trakcie projektu i nie stracić kontroli?

Czasem model wybrany na starcie przestaje pasować. Wymagania, które wyglądały na stabilne, zaczynają się zmieniać, regulator żąda więcej dowodów niż planowano albo projekt sekwencyjny musi pokazać wartość przed kolejną rundą budżetową. Zmiana jest możliwa, ale trzeba nią zarządzać jak odrębną zmianą.

Kontrolę zapewniają cztery kroki:

• Nazwij wyzwalacz. Zapisz, dlaczego model przestał pasować — zmienność wymagań mierzoną liczbą zgłoszeń zmian, niedotrzymany kamień milowy, nowe wymagania regulacyjne. Ten zapis chroni decyzję przed komitetem sterującym i w umowie.
• Ustal nową bazę, a nie nową nazwę. Przejście z modelu kaskadowego na Scrum bez zamiany specyfikacji w spriorytetyzowany backlog i bez ponownego zaplanowania budżetu to tylko zmiana nazw faz. Określ, co od teraz jest stałe, a co zmienne.
• Dostosuj umowę. Umowa o stałej cenie rzadko przetrwa przejście na Agile bez zmian. Uzgodnij aneks — na przykład budżet z limitem dla pozostałego zakresu — przed pierwszym sprintem, a nie po pierwszym sporze.
• Chroń ścieżkę dowodową. Jeśli projekt jest regulowany, ustal, jak w nowym modelu będą powstawać zapisy identyfikowalności i weryfikacji. Utrata tej ścieżki w trakcie przejścia to jeden z najszybszych sposobów na negatywny wynik audytu.

Zdarza się też ruch odwrotny. Projekty zwinne, które osiągnęły stabilny rdzeń, czasem przechodzą na bardziej planowy rytm wydań przy końcowej integracji ze sprzętem albo z systemami partnerów. To nie porażka Agile, tylko dobór właściwego modelu do bieżącego ryzyka. Dobry program manager traktuje model jak narzędzie, które można wymienić, gdy zmienia się zadanie — a nie jak tożsamość zespołu.

Który model wybrać i jakie są najważniejsze wnioski?

Wybór modelu wytwarzania oprogramowania to wybór dotyczący ryzyka: które ryzyko chcesz odkryć wcześnie, które akceptujesz późno i kto płaci za każde z nich. Najważniejsze wnioski:

1. Dopasuj model do stabilności wymagań i kosztu późnej zmiany, a nie do mody. Stabilne wymagania i kosztowne zmiany sprzyjają modelom sekwencyjnym, zmienne wymagania i tanie wydania — iteracyjnym.
2. Royce ostrzegał przed czystą kaskadą już w 1970 roku. Model sekwencyjny działa najlepiej z wczesnymi prototypami i etapową integracją — tak, jak zamierzał jego autor.
3. V-model jest punktem odniesienia w motoryzacji, ale oprogramowanie wyrobów medycznych zgodne z IEC 62304 może powstawać w dowolnym udokumentowanym cyklu życia, także zwinnym.
4. Hybrydy są normą. Niech będą świadome: krótka faza discovery, prawdziwe przyrosty i zautomatyzowane dowody, a nie długa specyfikacja i długa faza testów.
5. Model wytwarzania i umowę wybieraj razem. Stała cena wymaga stałego zakresu, Agile — zmiennego zakresu przy stałym zespole lub budżecie.

W ARDURA Consulting od ponad 10 lat realizujemy projekty software developmentu dla klientów w Polsce, Europie, na Bliskim Wschodzie i w USA — w umowach o stałej cenie, w rozliczeniu time and materials i w modelach hybrydowych, w branżach regulowanych i nieregulowanych. Każdą współpracę zaczynamy od uzgodnienia modelu wytwarzania razem z warunkami handlowymi, bo widzieliśmy, jak często to niedopasowanie między nimi, a nie kod, przesądza o wyniku.

Jeśli wybierasz model dla nowego projektu albo ratujesz projekt, w którym model przestał pasować, porozmawiaj z naszym zespołem. Pomożemy ocenić profil ryzyka i zaproponujemy model dostarczania oraz umowy, który do niego pasuje.