Model spiralny (ang. spiral model) to iteracyjny model cyklu życia oprogramowania opisany przez Barry'ego Boehma w 1986 r., w którym projekt przechodzi kolejne pętle spirali, a każda z nich obejmuje cztery ćwiartki: ustalenie celów, analizę ryzyka, budowę i ocenę oraz planowanie następnej iteracji. To właśnie ryzyko - nie harmonogram, nie funkcje - steruje tym, co robi się w kolejnym obrocie.
Analityk spotyka ten model głównie w trzech sytuacjach: na rozmowach rekrutacyjnych (klasyczne pytanie o modele cyklu życia), w dużych organizacjach utrzymujących projekty wystartowane lata temu oraz przy wyborze podejścia dla przedsięwzięć o wysokiej niepewności technicznej, gdzie "czysty" waterfall byłby hazardem.
Przykład (MediFlow). Rejestracja online dla 12 przychodni niesie jedno wielkie ryzyko: integrację z używanym od lat systemem gabinetowym. W modelu spiralnym pierwsza pętla to prototyp rezerwacji dla jednej przychodni i analiza, czy API wytrzyma ruch. Druga pętla rozszerza rozwiązanie na trzy placówki i bada synchronizację grafików. Dopiero trzecia buduje wersję docelową - bo dwa największe ryzyka zostały już zdjęte ze stołu.
Częsta pomyłka. Utożsamianie spirali z agile. Owszem, oba podejścia iterują, ale pętla spiralna jest ciężka dokumentacyjnie, trwa miesiącami i jest sterowana ryzykiem, podczas gdy sprint jest krótki i sterowany wartością biznesową. Drugie potknięcie: mylenie modelu spiralnego z przyrostowym - w przyrostowym dokłada się kolejne gotowe kawałki produktu, w spiralnym każdy obrót może zmienić kierunek całości, bo właśnie po to robi się analizę ryzyka.
Jak czytać diagram modelu spiralnego?
Rysunek spirali, który krąży po podręcznikach, najczęściej pochodzi z artykułu Boehma w IEEE Computer z 1988 r., rozwinięcia tekstu z 1986 r., o którym mówi definicja wyżej. Ma dwa wymiary i od nich zaczyna się czytanie:
- odległość od środka to skumulowany koszt projektu - im dalej od środka, tym więcej już wydano;
- obrót to postęp w bieżącej pętli - przejście przez cztery ćwiartki opisane w definicji wyżej.
Z tego układu wynika cała logika modelu. Pierwsze pętle leżą blisko środka, więc są tanie. Właśnie w nich zdejmuje się największe ryzyka, zanim projekt zacznie kosztować naprawdę dużo. Każda pętla kończy się przeglądem z osobami, które mają wpływ na projekt, i decyzją: kolejny obrót według nowego planu, zmiana kierunku albo zatrzymanie projektu. Model spiralny nie ma z góry ustalonej liczby pętli. Wynika ona z ryzyka: kolejne obroty trwają, dopóki zostaje ryzyko, które trzeba zdjąć przed budową wersji docelowej.
W przykładzie MediFlow z góry tego hasła widać to wprost: dopiero ostatnia pętla buduje wersję docelową, bo największe ryzyka zdjęły pętle wcześniejsze.
Co robi analityk biznesowy w każdej ćwiartce spirali?
Model opisuje, co ma się wydarzyć w pętli, a nie kto to robi. W praktyce spora część pracy w każdej ćwiartce to robota analityka:
| Ćwiartka | Pytanie, które pada | Praca analityka | Gdzie więcej |
|---|---|---|---|
| Cele, opcje, ograniczenia | Czego chcemy w tym obrocie i w jakich granicach? | rozmowy z interesariuszami, zakres pętli, ograniczenia, opcje rozwiązania | business case, ograniczenie projektowe |
| Analiza ryzyka | Co może zatopić projekt i jak to najtaniej sprawdzić? | opis ryzyk, ocena, wybór sposobu sprawdzenia: prototyp, PoC, spike, rozmowa | ryzyko projektowe, rejestr ryzyk |
| Budowa i ocena | Czy to, co zbudowaliśmy, odpowiada na ryzyko? | walidacja z użytkownikami, zebranie wniosków z prototypu | prototyp, prototypowanie |
| Plan następnej pętli | Co bierzemy w kolejnym obrocie i czy w ogóle? | aktualizacja wymagań, materiał do decyzji na przeglądzie | kamień milowy, sign-off |
Najwięcej zależy od drugiej ćwiartki. Hasło o ryzyku projektowym podaje formę, w jakiej dobrze opisane ryzyko trafia do rejestru: przyczyna, zdarzenie, skutek. Jego przykład z MediFlow dotyczy tej samej integracji, którą pierwsza pętla w górze tego hasła sprawdza prototypem: dostawca systemu gabinetowego nie potwierdził gwarantowanej przepustowości API. W modelu spiralnym taka pozycja rejestru wyznacza, co zbuduje najbliższa pętla.
Czym model spiralny różni się od kaskady, V-Modelu i Agile?
Różnica, o którą najczęściej chodzi w pytaniu, sprowadza się do tego, co decyduje o kolejnym kroku projektu:
| Model | Co decyduje o kolejnym kroku | Kiedy da się zmienić kierunek | Hasło |
|---|---|---|---|
| Kaskada | plan faz ustalony na starcie | przez formalny proces kontroli zmian | waterfall |
| V-Model | plan faz, do każdej fazy specyfikacji odpowiadający jej poziom testów | jak w kaskadzie | V-Model |
| Model przyrostowy | lista kolejnych kawałków produktu | między przyrostami, zwykle bez zmiany całości | - |
| Model spiralny | ryzyko, które w danej chwili jest największe | po każdej pętli, łącznie ze zmianą całości | to hasło |
| RAD | prototyp i opinie użytkowników | przy kolejnej iteracji prototypu | RAD |
| Agile (np. Scrum) | wartość biznesowa, kolejność w backlogu | co sprint | Agile, Scrum |
Jedna rzecz zaskakuje osoby, które znają spiralę tylko z tabelki porównawczej. Boehm pisał w artykule z 1988 r., że pojedynczy obrót spirali może wyglądać jak zwykła kaskada. Gdy wcześniejsze prototypy rozwiązały już ryzyka wydajności i interfejsu użytkownika, a zostały ryzyka budowy i kontroli interfejsów, kolejny krok idzie klasycznie, faza po fazie. W raporcie dla Software Engineering Institute z 2000 r. nazwał spiralę wprost generatorem modeli procesu sterowanym ryzykiem (risk-driven process model generator). Czytanie jej jako jednego, sztywnego modelu obok kaskady to więc uproszczenie. Spirala mówi, jak dobierać sposób pracy do ryzyka w danym obrocie.
Jakie są zalety i wady modelu spiralnego?
Zalety:
- największe ryzyka wychodzą wcześnie, w pętlach, które jeszcze mało kosztują;
- zmiana kierunku jest częścią modelu, a nie wyjątkiem wymagającym procedury - po każdej pętli pada decyzja, co dalej;
- zatrzymanie projektu jest uczciwym wynikiem - jeśli pętla pokaże, że ryzyka nie da się zdjąć, projekt można przerwać, zanim pochłonie budżet na budowę;
- dobrze pasuje do przedsięwzięć o wysokiej niepewności technicznej, co zauważa też góra hasła.
Wady:
- model jest tak dobry, jak analiza ryzyka. Sam Boehm wymienił wśród trudności modelu zależność od ludzi, którzy umieją ryzyko ocenić. Zespół, który przeoczy największe ryzyko, spokojnie przejdzie kilka pętli w złą stronę;
- trudno go zakontraktować. To kolejna trudność, którą wymienił sam Boehm, u niego zresztą pierwsza na liście. Hasło o waterfallu pokazuje problem od strony zamawiającego: przy umowie z zewnętrzną firmą na konkretną kwotę ktoś musi wcześniej spisać, co wchodzi w cenę, a spirala nie zna z góry liczby pętli. Z tego samego powodu trudno podać na starcie harmonogram i budżet;
- narzut na małym projekcie. Pętla z analizą ryzyka, przeglądem i dokumentacją ma sens, gdy stawka jest wysoka. W prostym projekcie o znanych wymaganiach to koszt bez pokrycia.
Gdzie analityk spotyka dziś model spiralny?
Z nazwy rzadko. Góra hasła wymienia trzy miejsca: rozmowy rekrutacyjne, projekty wystartowane lata temu w dużych organizacjach i przedsięwzięcia o wysokiej niepewności. Na forum społeczności Analify jeden z postów o kompetencjach analityka wymienia spiralę w jednym szeregu z innymi modelami: „Znajomość metodyk wytwarzania oprogramowania (Agile/Waterfall/V-model/Spiral)".
Częściej niż nazwa żyje sama zasada: o kolejności pracy decyduje ryzyko. W materiałach Analify widać ją w trzech miejscach:
- wpis o analizie ryzyka projektu opisuje projekt w sprintach, w którym integrację z bramką SMS zespół bierze wcześnie, choć samo przypomnienie ma dopiero priorytet Should, „bo jeśli coś ma nie wyjść, lepiej dowiedzieć się na początku niż pod koniec";
- lekcja o planowaniu pracy nad wymaganiami w minikursie o wymaganiach dzieli MediFlow na część robioną z góry (integracje, RODO) i część robioną iteracyjnie (ekrany), a tę hybrydę nazywa wprost: „dopasowanie rygoru do ryzyka", osobno dla każdej części;
- spike i Proof of Concept to w zwinnych zespołach sposób na to samo, co robi pierwsza pętla spirali: kupić wiedzę o ryzyku, zanim zespół zobowiąże się do budowy.
Lekcja o podejściu do analizy w kursie przygotowującym do ECBA opisuje wybór między podejściem predyktywnym a adaptacyjnym zdaniem: „To oś, nie przełącznik". Spiralę można czytać jako projekt, który w każdej pętli na nowo ustawia się na tej osi (to nasze odczytanie, lekcja nie wspomina o spirali).
Jak odpowiedzieć na pytanie o model spiralny na rozmowie?
Wyrecytowanie czterech ćwiartek pokazuje głównie pamięć. Jeśli padnie to pytanie, mocniejsza odpowiedź ma trzy zdania:
- Czym jest: „To iteracyjny model Boehma, w którym projekt przechodzi kolejne pętle, a o tym, co robimy w następnej, decyduje analiza ryzyka."
- Czym różni się od sąsiadów: „W kaskadzie kolejność wyznacza plan faz, w Agile wartość biznesowa, a w spirali największe nierozwiązane ryzyko."
- Co robi w nim analityk: „Opisuję ryzyka w rejestrze, pomagam wybrać najtańszy sposób ich sprawdzenia, np. prototyp, i przygotowuję materiał do decyzji po każdej pętli."
Możliwe dopytania i krótkie odpowiedzi:
- „Czy spirala to to samo co Agile?" Nie. Oba iterują, ale spiralą steruje ryzyko, a sprintem wartość - szerzej w „Częstej pomyłce" wyżej.
- „Kiedy byś go wybrał?" Przy dużym przedsięwzięciu z jednym albo dwoma ryzykami, które mogą przekreślić cały projekt, np. integracją ze starym systemem.
- „Jaka jest największa słabość?" Zależność od jakości analizy ryzyka i trudność w zakontraktowaniu projektu na stałą kwotę.
Gdzie iść dalej
- Inne modele cyklu życia: waterfall, V-Model, RAD, Agile, Scrum; wpis Agile vs Waterfall - rola analityka.
- Praca z ryzykiem: ryzyko projektowe, rejestr ryzyk, studium wykonalności; wpis Analiza ryzyka projektu - rejestr ryzyk krok po kroku.
- Sposoby sprawdzania ryzyka w pętli: prototyp, prototypowanie, Proof of Concept, spike.
- Sprawdź się bez zakładania konta: test z zarządzania ryzykiem.
Jeśli chcesz przejść pracę analityka na jednym case'ie, od ryzyk po wymagania, załóż darmowe konto: dostajesz pierwszą lekcję każdego kursu, trzy podejścia do testów w miesiącu i plan na 30 dni.