Jaka jest różnica między rozwojem iteracyjnym a przyrostowym?
Na moich szkoleniach często zauważam, że uczestnicy mylą rozwój iteracyjny i przyrostowy (IID). Celem tego artykułu jest wyjaśnienie zależności między rozwojem przyrostowym a iteracyjnym.
Rozpocznę od porównania podejścia kaskadowego i zwinnego, posługując się przykładem dostarczania aplikacji płatniczej. Dołączono również krótkie webinarium dotyczące tych podejść. W drugiej części artykułu umieszczę podejście kaskadowe i zwinne w macierzy pokazującej przecięcie rozwoju przyrostowego i iteracyjnego oraz wyjaśnię wszystkie cztery ćwiartki tej macierzy.
Zwinne czy kaskadowe: rozwój aplikacji płatniczej
Podejście kaskadowe
Jeśli przykładowa aplikacja zostanie opracowana zgodnie z tradycyjnym modelem kaskadowym, na rysunku 1 można zaobserwować następujące kroki.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Rysunek 1: Diagram przedstawia typowy cykl życia w modelu kaskadowym na przykładzie dostarczania aplikacji.
Inicjowanie projektu
Wszystko zaczyna się od sponsora projektu z działu marketingu, który zdołał wygospodarować niezbędne środki na tę aplikację. Założył on, że aplikacja poprawi utrzymanie klientów i napływ nowych klientów. Wyobraził sobie trzy grupy funkcji wysokiego poziomu.
Po zatwierdzeniu projektu zostaje wyznaczony kierownik projektu i tworzony jest zespół projektowy. Po wielu dyskusjach i warsztatach dotyczących zbierania wymagań uzgodniono, że zostanie dostarczona aplikacja płatnicza z 250 funkcjami. Wszystkie te funkcje zostają zapisane w obszernym i bardzo szczegółowym dokumencie wymagań oprogramowania, który podpisują sponsor projektu i przedstawiciel klienta (a także inni kluczowi interesariusze).
Faza projektowania projektu
W kolejnym kroku zespół projektowy przekłada wymagania na projekt aplikacji. Architekt sprawdza projekt pod kątem zgodności z zasadami projektowania. Sprawdza również, czy wszystkie wymagane atrybuty danych są dostępne w systemie zaplecza.
Minęły już dwa miesiące, a klient nie widział jeszcze niczego działającego, jedynie kilka raportów z postępów. Raporty te prawdopodobnie obejmują jakiś rodzaj raportowania typu „arbuz”, przez co klient nie ma pojęcia, czy projekt przebiega zgodnie z planem.
Faza rozwoju projektu
Opracowanie aplikacji zajmuje sześć miesięcy, a gdy jest już gotowa, przedstawiciel klienta zostaje poproszony o wskazanie kilku osób, które mogą pomóc w przeprowadzeniu testu akceptacji użytkownika. Podczas testu okazuje się, że kilka funkcji nie działa.
Zespół projektowy nie rozumie dlaczego. Wszystko jest dokładnie tak, jak opisano w dokumencie wymagań. Prowadzi to do wielu dyskusji, przeróbek i opóźnień, a klienci nie są zadowoleni z rezultatów. Co więcej, jeśli przyjrzymy się końcowemu rezultatowi, możemy zauważyć, że wiele opracowanych wymagań nie jest wykorzystywanych przez klienta lub jest wykorzystywanych rzadko.
Mogłoby być jeszcze gorzej. Załóżmy, że opracowanie aplikacji zajęło 1,5 roku, a inny bank dostarcza aplikację płatniczą, gdy jesteście dopiero w połowie prac. Co zrobilibyście w takim momencie? Czy nadal mielibyście realne uzasadnienie biznesowe, aby kontynuować i ukończyć własną aplikację?
Patrząc na rysunek 1, staje się jasne, że w podejściu kaskadowym zakres i leżące u jego podstaw kryteria jakości są ustalone, a dostarczenie następuje jednorazowo. Wszystkie kroki są wykonywane raz dla całego projektu, a kontrola zarządcza koncentruje się na kosztach i czasie. Dostarczenie wartości klientowi następuje dopiero po wdrożeniu kompletnej aplikacji.
Podejście zwinne
Jeśli opracowujemy aplikację z wykorzystaniem zwinnego podejścia do zarządzania projektem, obserwujemy następujący schemat:
- Zespół deweloperski stwierdza, że jest w stanie dostarczyć dwie pierwsze funkcje ustalone jako priorytetowe przez właściciela produktu w pierwszej iteracji.
- Zespół projektowy co trzy tygodnie (w sprincie, iteracji lub przedziale czasowym) dostarcza przyrost produktu.
- Po pierwszych dostarczeniach lub przyrostach widzimy klienta, który ma pewność, że projekt zakończy się dostarczeniem produktu. Ma już działającą aplikację i rozumie, że nie ma w niej jeszcze wszystkich funkcji, ale te, które już są, działają.
Patrząc na najnowsze wydanie i dostarczone funkcje, klient wskazuje całkowicie nową funkcję. Taką, o której nikt nie myślał na początku projektu, ale która mogłaby zwiększyć produktywność klienta.
Po każdym przyroście opinie klienta prowadzą do powstania nowych możliwości funkcjonalnych (których nie było na pierwotnej liście) lub modyfikacji potencjalnych funkcji. Produkt staje się coraz bardziej dojrzały. Z każdym przyrostem klient otrzymuje nową wersję i jest coraz bardziej zadowolony.
Rysunek 2: Diagram przedstawia cykl tworzenia oprogramowania w metodyce zwinnej, wykorzystując ten sam przykład dostarczenia aplikacji.
Jeśli przyjrzymy się rysunkowi 2, zobaczymy stały przepływ dostarczania w określonym czasie i przy wykorzystaniu stałych zespołów zwinnych (są to koszty stałe). Zakres i podstawowe kryteria jakości są elastyczne (dynamiczne), a dostarczanie odbywa się często i w małych partiach (są to przyrosty).
Wszystkie kroki przeznaczone do dostarczenia funkcji lub historyjki użytkownika są wielokrotnie powtarzane (co czyni proces iteracyjnym), aż do osiągnięcia wymaganej jakości. Kontrola zarządcza koncentruje się na dostarczaniu wartości klientowi. Dostarczanie wartości klientowi następuje po każdym wdrożeniu przyrostu.
Podejście kaskadowe a zwinne: rezultaty dostarczania
Jeśli przyjrzymy się bliżej dwóm produktom — zarówno z podejścia kaskadowego, jak i zwinnego podejścia do tworzenia oprogramowania — zobaczymy produkt z 250 funkcjami i niezbyt zadowolonego klienta oraz produkt zawierający zaledwie 150 funkcji i bardzo zadowolonego klienta (zob. rysunek 3).
Rysunek 3: Diagram porównuje różnice w czasie, liczbie funkcji i satysfakcji klienta w podejściu kaskadowym i zwinnym.
A jeśli przyjrzymy się jeszcze dokładniej produktowi dostarczonemu w podejściu zwinnym, zobaczymy jedynie podzbiór 100 funkcji z pierwotnej listy oraz 50 nowych lub zmodyfikowanych funkcji. Jest to zgodne z niektórymi ważnymi zasadami Manifestu zwinnego, w tym z następującymi:
- Prostota, czyli sztuka maksymalizowania ilości pracy, której nie trzeba wykonywać: tylko 150 funkcji zamiast 250
- Akceptowanie zmieniających się wymagań, nawet na późnym etapie tworzenia: dostosowywanie się do informacji zwrotnych od klienta po każdej iteracji i każdym przyroście
Zwinne procesy tworzenia oprogramowania wykorzystują zmiany na rzecz przewagi konkurencyjnej klienta (dostarczono 50 nowych lub zmodyfikowanych funkcji). W rezultacie klient jest bardzo zadowolony. Najwyższym priorytetem zespołu jest zaspokojenie potrzeb klienta poprzez wczesne i ciągłe dostarczanie wartościowych systemów oprogramowania.
Miniwebinar: dostarczanie kaskadowe a zwinne
Oto krótki webinar poświęcony różnicom między dostarczaniem kaskadowym i zwinnym.
Różnice między tworzeniem iteracyjnym i przyrostowym
Teraz, gdy omówiłem różnice między podejściem kaskadowym i zwinnym na przykładzie tworzenia aplikacji do płatności, umieszczę podejście kaskadowe i zwinne na macierzy porównującej tworzenie iteracyjne i przyrostowe.
Na koniec omówię produkt o minimalnej funkcjonalności (MVP) oraz minimalny produkt rynkowy (MMP), a także pokażę, gdzie wpisują się one w różne podejścia i mapę historyjek. Dodałem również odpowiedni miniwebinar.
Macierz tworzenia iteracyjnego i przyrostowego
Jak wspomniano, zauważyłem, że studenci często mylą podejście iteracyjne z przyrostowym. Na rysunku 4 znajdują się cztery ćwiartki, będące wynikiem poziomej linii przedstawiającej podejście przyrostowe lub jego brak oraz przecinającej ją pionowej linii reprezentującej podejście iteracyjne lub jego brak. Zobacz ten film na YouTube, aby obejrzeć bardzo prostą wersję tego rysunku.
Rysunek 4: Macierz przedstawia różne podejścia do tworzenia oraz wskazuje, czy członkowie zespołu stosujący te podejścia muszą iterować i/lub pracować w przyrostach.
Dolna lewa ćwiartka
W lewym dolnym rogu widzimy podejście, w którym nie ma ani iteracji, ani przyrostów. Jest to podejście kaskadowe. Wszystkie działania (projektowanie, analiza, budowanie, testowanie i wdrażanie) są wykonywane raz dla całego projektu.
W tym przypadku widzimy jednokrotne dostarczenie produktu końcowego na podstawie stałego zakresu. Wartość dla klienta może zostać osiągnięta dopiero po dostarczeniu produktu końcowego. Jednym z kluczowych celów tego podejścia jest zarządzanie kosztami.
Dolna prawa ćwiartka
W prawym dolnym kwadrancie widzimy podejście przyrostowe bez iteracji. Jest to etapowe lub przyrostowe dostarczanie mniejszych części produktu. Wszystkie działania dla danego etapu (projektowanie, analiza, budowa, testowanie i wdrażanie) są wykonywane jeden raz.
W ramach danego etapu zakres jest stały, ale cały produkt opiera się na bardziej dynamicznym lub elastycznym zakresie. Wartość dla klienta można osiągnąć po każdym dostarczeniu produktu. Jednym z kluczowych celów tego podejścia jest szybkość dostarczania.
Lewy górny kwadrant
W lewym górnym kwadrancie widzimy podejście spiralne lub iteracyjne bez przyrostów. Jest to pojedyncze dostarczenie, w ramach którego produkt końcowy powstaje poprzez kilka iteracji. Dobrym przykładem tego podejścia jest myślenie projektowe. Na wykresie widzimy sekwencję działań obejmujących określanie ram, analizę, generowanie pomysłów, realizację i refleksję.
Sekwencja ta jest wykonywana wielokrotnie lub iteracyjnie, dzięki czemu w każdej iteracji zbliżamy się do ostatecznego, poprawnego lub wymaganego produktu. W wielu przypadkach tym produktem końcowym jest prototyp lub model. W tym podejściu spiralnym mamy dynamiczny lub elastyczny zakres. Wartość dla klienta można osiągnąć dopiero po dostarczeniu produktu końcowego. Jednym z kluczowych celów tego podejścia jest poprawność rozwiązania.
Prawy górny kwadrant
W prawym górnym kwadrancie widzimy podejście zwinne, które wykorzystuje przyrosty i metodę iteracyjną. Dobrym przykładem tego podejścia jest Scrum.
Na końcu każdego przyrostu, często nazywanego sprintem lub oknem czasowym, dostarczany jest przyrost produktu. Przyrost ten jest wynikiem wielu iteracji mających na celu opracowanie małych, ale poprawnych części produktu, często nazywanych historyjkami użytkownika lub elementami rejestru produktu. Końcowy projekt iteracyjny będzie dostarczany etapami.
W tym zwinnym podejściu mamy dynamiczny lub elastyczny zakres. Wartość dla klienta można osiągnąć po każdym dostarczeniu produktu. Jednym z kluczowych celów tego podejścia jest dostarczanie wartości klientowi poprzez częste dostawy i informacje zwrotne od użytkowników.
MVP czy MMP?
Na rysunku 4 można również znaleźć akronimy MVP i MMP. MVP oznacza minimalnie opłacalny produkt i jest wersją nowego produktu lub usługi, która pozwala zespołowi zebrać maksymalną ilość wiedzy o klientach oraz uzyskać walidację przy minimalnym nakładzie pracy. MVP usługi Dropbox było prostym filmem. Oznacza to, że P w MVP może oznaczać produkt całkowicie różny od tego, który ostatecznie stanie się produktem końcowym.
Przykład ilustrujący MVP i MMP
Często posługuję się następującym przykładem nowego produktu finansowego. Entuzjastyczny kierownik sprzedaży ma świetny pomysł dotyczący nowego produktu finansowego. Uważa, że można sprzedać co najmniej 100,000 takich produktów.
Wspólnie z kilkoma ekspertami finansowymi projektuje produkt w ciągu kilku miesięcy. Zostaje przydzielony zespół programistyczny, któremu opracowanie produktu zajmuje 4 miesiące. Równolegle przygotowywane są broszury reklamowe, a produkt zostaje wprowadzony na rynek podczas dużego wydarzenia.
Niestety produkt kupuje tylko kilka osób. Jeśli zastosujemy podejście MVP, możemy przyjąć założenie, że 10% użytkowników ich strony internetowej jest zainteresowanych tym produktem. Następnie opracowalibyśmy MVP, aby przetestować tę hipotezę.
W tym przypadku MVP mogłoby być prostym przyciskiem na stronie głównej. Po kliknięciu pojawiałby się ekran z komunikatem dotyczącym tego nowego produktu oraz opcją dodania adresu e-mail, jeśli użytkownik byłby zainteresowany. Załóżmy, że przycisk nacisnęło mniej niż 1% odwiedzających — produkt nie zostałby opracowany, a firma zaoszczędziłaby wiele ograniczonych zasobów.
Jeśli przyjrzymy się bliżej rysunkowi 4, zobaczymy potencjalne zastosowanie MVP we wszystkich kwadrantach. W przypadku podejścia kaskadowego można utworzyć MVP w pierwszej fazie projektowania oprogramowania, aby sprawdzić, czy projekt ma uzasadnienie biznesowe.
To samo można zrobić w pierwszej fazie pierwszego przyrostu przy etapowym dostarczaniu. W niektórych przypadkach wynikiem podejścia opartego na myśleniu projektowym może być MVP. MVP może być również korzystne na początku podejścia zwinnego.
Wiele osób postrzega pierwszy produkt dostarczony na końcu dostarczania etapowego jako MVP. Może tak być, ale w większości przypadków nie jest to MVP, lecz MMP. MMP, czyli minimalny produkt możliwy do wprowadzenia na rynek, to najmniejszy produkt, który może przynieść wartość klientowi.
Jak wygląda dostarczanie zwinne?
Teraz, gdy jest już jasne, że modele przyrostowe i modele iteracyjne nie są tym samym oraz rozumiemy zastosowanie MVP i MMP, możemy dokładniej przyjrzeć się temu, jak wygląda dostarczanie przyrostowe i iteracyjne.
Prawdopodobnie widzieliście słynny przykład Jeffa Pattona przedstawiający Mona Lisę, w którym obraz powstaje kawałek po kawałku (dostarczenie etapowe). Innym sposobem jest rozpoczęcie od pierwszego przyrostu, w ramach którego powstaje jedynie szkic, a następnie dodawanie kolejnych szczegółów do szkicu w każdej nowej iteracji, aż ostatecznie powstanie gotowy obraz (dostarczanie przyrostowe i iteracyjne lub zwinne).
W pierwszej sytuacji trzeba już mieć szczegółowe wyobrażenie o produkcie końcowym, natomiast w drugiej wystarczy zarys na wysokim poziomie, ponieważ wprowadzanie zmian jest znacznie łatwiejsze. Jeśli spojrzymy na rysunek 5, zobaczymy mapę historyjek dla nowego produktu o nazwie ABC.
Rysunek 5: Przykład mapy opowieści dla konkretnego przykładowego produktu.
Właściciel produktu przewidział siedem funkcji dla tego produktu. Pierwsze cztery funkcje są niezbędne. Funkcje 5 i 6 są pożądane, a ostatnia funkcja jest opcjonalna. Wielu nazwałoby to ustalaniem priorytetów MoSCoW (elementy niezbędne, pożądane, opcjonalne oraz takie, z których można zrezygnować).
Każdą funkcję można podzielić na mniejsze części. Na rysunku widać funkcje lub historyjki użytkownika oznaczone jako niezbędne, pożądane i opcjonalne. Funkcja może być niezbędna, ale nie oznacza to, że wszystkie leżące u jej podstaw historyjki użytkownika również są niezbędne. Funkcja może też być pożądana, ale podczas jej implementacji niektóre historyjki użytkownika mogą być niezbędne, a inne pożądane lub opcjonalne.
Aby zaimplementować ten produkt ABC, można wyróżnić pięć przyrostów lub wydań. Pierwsze z nich to minimalny produkt możliwy do wprowadzenia na rynek. Ten MMP składa się z dwóch pierwszych niezbędnych historyjek użytkownika funkcji 1 oraz pierwszych niezbędnych historyjek użytkownika funkcji 2 i 3.
Wydanie 2 zawiera kolejne dwie niezbędne historyjki użytkownika funkcji 1, 2 i 3 (rozwój iteracyjny). Rozwój produktu jest kontynuowany poprzez implementację kolejnych wydań. Z każdym wydaniem wzrasta wartość dla klienta.
Po wydaniu 5 właściciel produktu przestaje implementować historyjki użytkownika. Informacje zwrotne od klienta pokazały mu, że produkt ABC jest „odpowiedni do celu”, dlatego uwzględnia on zasadę prostoty z Manifestu Agile i kończy dalszy rozwój.
Miniwebinar: rozwój iteracyjny i przyrostowy
Oto szczegółowy webinar na temat iteracyjnego i przyrostowego tworzenia oprogramowania.
Końcowe przemyślenia
Czy zespół tworzący oprogramowanie dobrze rozumie rozwój iteracyjny i przyrostowy? Jak stosujecie go w swoich metodykach zwinnych lub kaskadowych?
Dajcie nam znać w komentarzach lub dołączcie do programu członkowskiego DPM i porozmawiajcie z innymi członkami na naszym ekskluzywnym forum!
