Podejście iteracyjne oraz przyrostowe [agilestarter]

Podczas wielu rozmów, które przeprowadziłem, rekrutując Scrum Masterów, bardzo często wchodziłem w dyskusje na temat różnic i podobieństw podejścia iteracyjnego oraz przyrostowego. Pomijając fakt, że do dzisiaj eksperci nie są zgodni co do tego, które podejście jest które, dosłownie tylko kilka razy odniosłem wrażenie, że kandydat zna oba modele i potrafi, niezależne od przyjętego słownictwa, wytłumaczyć różnice. Z czego wynika tak duży procent “mglistych” odpowiedzi? Nie wiem. Jestem natomiast przekonany, że po przeczytaniu tego artykułu dołączysz do grona osób, które potrafią rozróżnić oba podejścia. Zacznijmy więc.

No właśnie, które podejście jest które?

Świat ekspertów podzielił się dwie grupy: Alistair Cockburn, Jeff Patton oraz Mike Cohn utrzymują, że podejście iteracyjne oznacza stopniowe udoskonalanie, zmienianie oraz przerabianie elementów produktu, często wielu na raz, tak aby pracować i skupiać się na całościowym obrazie tworzonego systemu. Natomiast podejście przyrostowe oznacza dodawanie do produktu skończonych, gotowych kawałków, często będących tylko częścią większej całości.

Z kolei m.in. Ken Schwaber, Craig Larman czy Frederick Brooks uważają dokładnie odwrotnie: podejście iteracyjne nazywają przyrostowym, a przyrostowe – iteracyjnym.

Na potrzeby tego artykułu trzymam się tej pierwszej definicji, głównie ze względu na to, że takie określenie tematu bardziej do mnie przemawia. Drugi powód jest prozaiczny: odkąd pamiętam tak właśnie rozumiałem iteracyjność oraz przyrostowość.

Chciałbym też zwrócić uwagę, że w artykule tym słowo “przyrost oznacza po prostu efekt pracy w podejściu przyrostowym. Nie oznacza Przyrostu w rozumieniu definicji zawartej w dokumencie Scrum Guide, który definiuje go jako “suma wszystkich elementów Backlogu Produktu zakończonych podczas Sprintu i wszystkich Sprintów poprzednich”.

Przykład

Aby lepiej zrozumieć różnice, przyjrzymy się trzem popularnym podejściom do rozwijania oprogramowania:

  • podejście kaskadowe (zwane potocznie “waterfall”),
  • podejście przyrostowe,
  • podejście iteracyjne.

W artykule będę posługiwał się bardzo prostym przykładem produktu, by lepiej zobrazować czym różnią się wyżej wymienione sposoby pracy. Wyobraźmy więc sobie, że budujemy sklep internetowy, oferując możliwość zalogowania się, przeglądnięcia dostępnej oferty oraz zakupienia wybranych produktów.

Podejście kaskadowe

Budowa sklepu w tym modelu jest podzielona na kilka faz, z czego każda odpowiedzialna jest za dostarczanie innego rodzaju rezultatów. Aby zbudować finalny produkt, konieczne jest przejście przez kilka etapów:

  • analizy (lista wymagań do zrealizowania)
  • projektowania (architektury, interfejsu użytkownika oraz konkretnych funkcjonalności)
  • implementacji (na podstawie danych zebranych w fazie analizy i projektowania)
  • testów (sprawdzenie, czy implementacja nie zawiera błędów)
  • wdrożenia (sklep staje się dostępny dla użytkowników)

Konsekwencje podejścia kaskadowego

Pomimo, iż na pierwszy rzut oka podejście to wydaje się logiczne oraz poukładane, w kontekście budowania produktów posiada bardzo dużo wad, takich jak:

  • brak możliwości zebrania informacji zwrotnej na temat naszego produktu – możemy wprawdzie pokazać użytkownikom efekt analizy (np. w formie dokumentu tekstowego), czy projektowania (np. makiety), jednak aby usłyszeć wartościową informację zwrotną, trzeba by pokazać chociażby “klikalną” namiastkę działającego sklepu. Taką możliwość mamy dopiero pod koniec fazy rozwoju (faza testów), co powoduje, że ryzyko zbudowania produktu, który nie spełnia oczekiwań użytkowników, jest wysokie,
  • brak możliwości otrzymania produktu wcześniej niż planowano – wyobraźmy sobie sytuację, w której z jakiegoś powodu musimy zredukować budżet projektowy i chcielibyśmy zakończyć rozwój produktu wcześniej, zadowalając się uboższą wersją naszego sklepu. Zakładając, że fazy mają podobną długość, gdybyśmy chcieli zredukować budżet o 50%, to zatrzymamy się w okolicach środka fazy implementacji. Powoduje to, że produkt znajduje się w stanie niezdatnym do przekazania go do użytkowników końcowych (trwająca implementacja, brak testów),
  • możliwość zarabiania na produkcie dostępna dopiero po wdrożeniu ze względu na fakt, iż rezultatem konkretnej fazy nie jest działające oprogramowanie, a tylko pewien pół-produkt, nasz sklep pozwoli nam zarobić pierwsze pieniądze dopiero po wdrożeniu całościowego efektu, będącego sumą wszystkich zrealizowanych już faz. Musimy więc wydać cały zaplanowany budżet, aby otrzymać produkt, który jest gotowy do komercyjnego uruchomienia,
  • wysokie ryzyko techniczne – pierwsze fazy w modelu kaskadowym są mocno teoretyczne (analiza, projektowanie), co powoduje, że pewne ryzyka mogą zmaterializować się dopiero w późniejszych, bardziej praktycznych fazach (implementacja, testowanie). Nie wszystkie problemy jesteśmy w stanie przewidzieć oraz odpowiednio obsłużyć z wyprzedzeniem, co wynika ze złożoności materii tworzenia oprogramowania,
  • wysokie ryzyka biznesowe – walidacja założeń biznesowych staje się możliwa, gdy produkt nabierze faktycznego kształtu, co jest wykonalne dopiero po wdrożeniu. W przypadku projektów, które trwają wiele miesięcy, a czasem nawet i lat, dodatkowym problemem jest starzenie się rozwiązania, które w skrajnych przypadkach może okazać się przestarzałe i nie adekwatne do rynku, kiedy już zostanie wdrożone produkcyjnie.

Podejście przyrostowe

Przyrostowe wytwarzanie oprogramowania opiera się na zdecydowanie odmiennych założeniach w porównaniu do modelu kaskadowego. Podejście to wymaga posiadania jasnej wizji produktu, której realizacja prowadzona jest w powtarzalnych, krótkich krokach o stałej długości, trwających najczęściej 1 lub 2 tygodnie. W dużym uproszczeniu, każdy taki krok składa się z małego kawałka analizy, projektowania, właściwej implementacji oraz testów – oczywiście w bardzo okrojonym zakresie, dotyczącym konkretnej, niedużej funkcjonalności. Efektem pojedynczego kroku jest drobny, działający i skończony przyrost produktu.

Pomocna w zrozumieniu modelu przyrostowego może być analogia do pracy rzeźbiarza: gdyby pracował przyrostowo, podzieliłby swoje dzieło (np. postać boga greckiego) na wiele małych przyrostów (np. twarz, dłoń, klatka piersiowa) i rzeźbiłby każdy z nich po kolei, aż do osiągnięcia jego wyglądu ostatecznego. Raz przygotowany przyrost dzieła (np. twarz) jest już jego “ostateczną wersją” i rzeźbiarz nie wraca już do niego w kolejnych krokach realizacji.

Przykład wykonania rzeźby w modelu przyrostowym

Przykład wykonania rzeźby w modelu przyrostowym

W przypadku naszego sklepu, takim przyrostem może to być np. strona logowania lub fragment widoku szczegółów produktu. Tak przygotowany przyrost jest kompletny i zespół nie wraca już do niego, chyba że w trakcie rozwoju produktu pojawi się wiedza, która znacząco wpłynie na stworzoną już funkcjonalność.

Konsekwencje podejścia przyrostowego

Pomimo iż model ten posiada zdecydowanie więcej zalet niż model kaskadowy, posiada pewne ograniczenia:

  • częściowa możliwość zebrania informacji zwrotnej na temat naszego produktu – jest lepiej niż w przypadku modelu kaskadowego, ponieważ efektem 1-2 tygodniowej pracy jest działające oprogramowanie, a nie tylko efekty analizy czy projektowania. Pozwala to pokazać działający kawałek produktu interesariuszom, zaprzyjaźnionym partnerom lub użytkownikom końcowym. Co ważne, możliwość taka występuje już na wczesnym etapie rozwoju produktu. W przypadku sklepu, moglibyśmy przykładowo pokazać skończoną, gotową stronę logowania z zastrzeżeniem, że póki co to wszystko, co jest na ten moment dostępne,
  • częściowa możliwość otrzymania produktu wcześniej niż planowano – w zależności od budowanego produktu oraz podjętych decyzji związanych z podziałem rozwoju produktu na odpowiednie kroki, możemy mieć lub nie mieć możliwość wcześniejszego otrzymania czegoś działającego. Przykładowo, jeżeli – nawiązując do przykładu naszego sklepu – wyprodukowane przyrosty produktowe to strona logowania oraz możliwość przeglądnięcia dostępnej oferty, może to oznaczać, że produkt nie jest na tyle funkcjonalny (nie można kupić produktu) aby zdecydować się na komercyjne wdrożenie aplikacji. Natomiast jeśli naszym produktem byłby edytor tekstowy (jak np. Microsoft Word), wypuszczenie aplikacji bez skomplikowanych, rzadko używanych funkcji mogłoby mieć sens,
  • częściowa możliwość wydania mniej pieniędzy, niż planowano – pomimo, iż zawsze istnieje pewna elastyczność jeśli chodzi o zakres, to co do zasady nasz sklep musi składać się z wszystkich zaplanowanych elementów: strony logowania, strony z listą produktów oraz strony umożliwiającej wykonanie płatności i sfinalizowanie zamówienia. Jeśli chcielibyśmy zakończyć pracę wykorzystując wyłącznie część budżetu, mogłoby się okazać, że wprawdzie strona logowania i lista produktów są wykonane perfekcyjnie i są skończone, to nadal nie dokończyliśmy kluczowej strony, a mianowicie tej, która umożliwia zapłatę za zakupione produkty. Przykład jest oczywiście lekko przerysowany – dużo w tym przypadku zależy bowiem od tego jak Product Owner poukłada wraz z zespołem roadmapę produktu. Zakładam, że świadomy, doświadczony biznesowiec ma aspekty związane z kolejnością i ważnością prac pod kontrolą, pamiętajmy jednak, że każdy kiedyś zaczyna, stąd sygnalizuję to jako potencjalne ryzyko,
  • częściowa możliwość obniżenia ryzyk projektowych – w tym przypadku jest o niebo lepiej niż w przypadku modelu kaskadowego. Mamy bowiem do czynienia z namacalnym, działającym oprogramowaniem, dostępnym po każdym kroku. Duża część ryzyk, dotychczas dostępnych na papierze, ma szansę się zmaterializować, dużą wartością jest również możliwość odkrycia ryzyk, o istnieniu których nie mieliśmy wcześniej pojęcia. W przypadku naszego sklepu, może się przykładowo okazać, że nakład prac dostosowujących wygląd sklepu do wyświetlaczy urządzeń mobilnych jest zdecydowanie większy, niż planowaliśmy. Jeżeli dowiemy się o tym na wczesnym etapie działań, mamy przestrzeń, aby odpowiednio zareagować.

Podejście iteracyjne

W podejściu tym zespół posiada ogólną wizję produktu, która w odróżnieniu od modelu przyrostowego, nie musi być bardzo szczegółowa oraz dopracowana. Pracuje na zasadzie “od ogółu do szczegółu”: w pierwszym kroku powstaje bardzo ogólny szkielet całego produktu, który w kolejnych krokach jest doprowadzany do pożądanego poziomu szczegółowości. W trakcie pracy zespół wielokrotnie wraca do wcześniej napisanych fragmentów i stopniowo je rozbudowuje, dodając kolejne detale oraz funkcjonalności. To, co moim zdaniem wyróżnia to podejście i jest jednocześnie największym wyzwaniem, to całościowe myślenie o produkcie.

Używając analogi wcześniej wspomnianego artysty rzeźbiarza: gdyby pracował iteracyjnie, to w pierwszym kroku wyrzeźbiłby bardzo ogólną, surową i pozbawioną detali postać boga greckiego. W każdym kolejnym kroku dopracowywałby i ubogacał całościowo swoje dzieło dodając detale, aż do uzyskania satysfakcjonującego efektu. Każdy element rzeźby (np. twarz, dłoń czy klatka piersiowa) po każdym kroku wygląda nieco lepiej i zbliża artystę do stanu docelowego.

Przykład wykonania rzeźby w modelu iteracyjnym

Przykład wykonania rzeźby w modelu iteracyjnym

Wracając do przykładu naszego sklepu internetowego, w podejściu iteracyjnym chciałbym umożliwić zakup produktu już po pierwszym kroku. Aby do tego doprowadzić, zbudowałbym bardzo mocno uproszczoną wersję sklepu, która:

  • nie wymagałaby od użytkownika zalogowania się,
  • lista oferowanych produktów byłaby prostą tabelką (produkt + cena) bez żadnych dodatkowych funkcji,
  • zakup byłby możliwy tylko gotówką podczas odbioru osobistego.

Następne kroki ubogacałyby mój sklep o kolejne funkcjonalności, takie jak możliwość zalogowania zwykłego lub przy użyciu Facebook’a czy integrację z serwisami umożliwiającymi dokonanie płatności takimi jak PayPal czy PayU.

Konsekwencje podejścia iteracyjnego

Pomimo, iż jest to dosyć wymagające podejście, charakteryzuje się wieloma pozytywnymi cechami, których trudno szukać w innych podejściach.

  • możliwość zebrania informacji zwrotnej na temat naszego produktu – właściwie co każdy krok jesteśmy w stanie otrzymać feedback dotyczący realizowanej inicjatywy. O ile w modelu przyrostowym jesteśmy w stanie co krok pokazać skończony, gotowy fragment produktu, tak w modeli iteracyjnym pokazujemy z kolei całościowy produkt, zbudowany jednak w dużym uproszczeniu. To, co zyskujemy, to możliwość otrzymania informacji zwrotnej na temat tego, jaki jest ogólny odbiór użytkowników, oraz wiedza, czy interakcje wewnątrz produktu są logiczne i zrozumiałe dla odbiorców. Każda kolejna iteracja jest zatem cenną lekcją dla zespołu z zakresu budowania rozumienia potrzeb użytkowników.
  • możliwość otrzymania produktu wcześniej niż planowanoLeonardo Da Vinci powiedział, że “wielkie dzieła nigdy nie są kończone, tylko porzucane”. Ostatecznie, wyłącznie artyści tworzący konkretne dzieło wiedzą, z czego zrezygnowali oraz co nie zostało zrobione, a nadal z perspektywy odbiorców to dzieło może być odbierane jako finalne i kompletne. Dzięki stosowaniu podejścia iteracyjnego mamy podobną jak artyści możliwość “porzucenia” inicjatywy niemal w dowolnym momencie. Wynika to z faktu, że od początku budujemy kompletne rozwiązanie (ang. end-to-end), czyli pewną uproszczoną ścieżkę podróży użytkownika, najczęściej bez przypadków brzegowych, zapewniającą jednak realizację celu, dla którego korzysta się z aplikacji. Z każdym krokiem rozwoju dodajemy kolejne elementy, funkcje oraz detale, które wpływają na całościową jakość rozwiązania. Operując na przykładzie sklepu internetowego, możemy zdecydować się udostępnić produkt użytkownikom bez możliwości logowania przy użyciu Facebooka czy też oferując wyłącznie jeden sposób płatności za produkt.
  • możliwość niewykorzystania całego budżetu – korzyść ta jest powiązana z poprzednim punktem: jeżeli możemy udostępnić użytkownikom produkt wcześniej, najprawdopodobniej będziemy w stanie oszczędzić pieniądze i zagospodarować je w inny sposób. Pomocny może być tutaj popularny wskaźnik ROI (ang. Return on Investment) – jeżeli kolejna iteracja zespołu nad produktem ma nas kosztować kilkadziesiąt tysięcy złotych a jej efektem miały by być mało znaczące funkcje, warto zastanowić się, czy jest sens wydawać na to pieniądze.
  • wczesne obniżenie ryzyk projektowych – całościowe, iteracyjne myślenie o rozwoju aplikacji powoduje, że bardzo wcześnie dotykamy różnych obszarów aplikacji, co ma wpływ na fakt, że bardzo szybko jesteśmy rozpoznać ryzyka i ocenić, jaki mogą mieć wpływ na rozwój produktu. Przykładowo, wczesne rozpoznanie tematu integracji z API dostawcy płatności w naszym sklepie może dostarczyć nam informacji (np. o bardzo słabej jakość dokumentacji API dostawcy), które mogą mieć wpływ na dalsze plany produktowe. Co ważne, jest szansa, że dowiemy się tego na początku rozwoju produktu, kiedy jeszcze możemy tę informację uwzględnić w naszych planach. Jeśli integrację z płatnościami zostawiliśmy na końcową fazę – możemy mieć kłopoty.

Z którego modelu zatem korzystać?

W dużym skrócie – z obu, w zależności od potrzeb oraz preferencji. Ogranicza nas wyłącznie potrzeba oraz wyobraźnia.

Przykładowo, po kilku krokach rozwoju produktu wykonanych w modelu iteracyjnym, można skupić się na wyłącznie na wybranym fragmencie i doprowadzić go do perfekcji. W przypadku naszego sklepu, może to być decyzja o skupieniu się na idealnym dopracowaniu strony płatności, zostawiając na dalszym planie rozwój pozostałych elementów sklepu.

Z drugiej strony wyobrażam sobie scenariusz, w którym po kilku krokach przyrostowych, decydujemy się na dalsze rozwijanie iteracyjne. Czyli mając idealnie przygotowaną stronę logowania oraz szczegółów produktu, w kolejnych krokach rozwijamy symultanicznie całość sklepu, a efektem każdego kroku jest po prostu trochę lepsza wersja produktu.

Dodatkowa literatura oraz materiały

Dla osób zainteresowanych zgłębieniem tematu polecam następujące materiały:

  • Agile and Iterative Development: A Manager’s Guide (Craig Larman) – książka współtwórcy LeSS’a, która mocno ukształtowała moje spojrzenie na tzw. IID (ang. iterative and incremental development). Jest to bardzo wartościowa pozycja dla każdego, kto miałby ochotę spojrzeć na świat szerzej niż tylko z perspektywy Scrum Guide’a,
  • Mapowanie historyjek użytkownika. Przepis na produkt idealny (Jeff Patton) – autor bardzo popularnej metafory modelu iteracyjnego oraz przyrostowego bazującej na słynnym obrazie “Mona Lisa”. Sama książka opisuje technikę mapowania historyjek użytkownika (ang. Story Mapping), która pomaga budować wspólne zrozumienie produktu w zespołach odpowiedzialnych za jego wytworzenie. Jeff jest praktykiem, warto przeczytać jego książkę od deski do deski i czerpać inspirację z jego 20-letniego doświadczenia w branży. Zachęcam też do przeczytania wpisu na moim blogu, gdzie na konkretnym przykładzie opisuję, jak wykorzystać Story Mapping w praktyce
  • The forgotten promise of agile development (Jacek Wieczorek) – prezentacja dotycząca podejścia iteracyjnego oraz przyrostowego, którą przygotowałem w 2015 roku na konferencję STX Next Summit. Artykuł, który właśnie czytasz, jest kolejną iteracją, w której próbuję uchwycić ten temat. To, co jest moim zdaniem warto prześledzić w materiale video, to bardzo szczegółowe przykłady pokazujące, jak praktycznie może wyglądać rozwój produktu w zależności od przyjętych metod pracy. Udostępniłem również same slajdy, które w odróżnieniu od materiału video, są dostępne w języku polskim.

Komentarze do wpisu: “Podejście iteracyjne oraz przyrostowe [agilestarter]

  1. No to dorzucę kamyczek do ogródka. Dla zielonych lsitków można to zagadnienie przedstawić bardzo prosto. Iteracyjny model – czyli praca w iteracjach polega na tym, że proces wytwarzania jest podzielony na iteracje. Iteracja to po prostu odcinek czasu o stałej długości. Zazwyczaj każda iteracja dostarcza coś, ale nie koniecznie cześć produktu. Na przykłąd wynikiem iteracji mogą być spisane wymagania.
    W modelu przyrostowym tworzymy przyrosty produktu. Proces jest podzielony na etapy, po których mogę obejrzeć kolejną wersję produktu, która zawiera w sobie to co było do w wersjach poprzednich, plus nowe funkcjonalności. Czyli de facto można powiedzieć, że przyrost po iteracji to przyrost plus poprzednie przyrosty. Nic nam po zestawie unkcjonalności niezintegrowanych z resztą produktu.
    Teraz pacząc na Scrum. Mamy stałe iteracje zwane Spritnami, więc jest to podejście iteracyjne. Mamy także przyrosty produktu, więc jest to podejście przyrostowe. Zatem można powiedzieć, że Scrum to podejście iteracyjno-przyrostowe. Badum, tsss!

    Teraz można wdać się w dywagacje. Zółty listek? 🙂 Można mieć kaskadę w iteracjach albo kaskada może być pocięta na iteracje. A jakie są modele Rational Unified Process, Rapid Application Development, Spiral Model? Czy Kanban jest przyrostowy?

    Co do rysunków, to z obu wychodzi, że już od początku wiemy jak ma wyglądać produkt końcowy i nie ma na nich uzględnienia feedbacku, zmiany kierunku. A może jednak lepiej wyżeźbić gargulca albo Justina Bibera, bo nasi klienci tego chcą? W przyrostowym możnaby głowa, popiersie, półpostaci, ale głowa w inną stronę patrzy, no dobra, jednak musi mieć skrzydła itd.
    Czy jak zgodnie z ilustracją iteracyjnego pokażę zamawiającemu obłupaną bryłę, to dostanę feedback, czy raczej powie „Po co mi pokazuesz ociosany kamień? Zawołaj mnie jak będziesz coś miał”. Czy jak wyjdzie, że ręka ma być w innym geście, to coś z tym mogę zrobić?

    Tłuamczenie software development przy użyciu metafor z innych dziedzin jest wredne, bo my nie mamy takich ograniczeń jak rzeźbiarz czy architekt.

    PS. Kaskadowy można było dać w osobnym poście, bo tutaj trochę nie pasuje do tematu i rozwleka materię.

    • Jacek Wieczorek

      Dzięki Krystian za Twój obszerny komentarz.

      Podoba mi się sposób, w jaki opisałeś podejście iteracyjno-przyrostowe w Scrumie, w prosty i zrozumiały sposób.

      Zgadzam się, że metafora jest pewnym uproszczeniem, nie uwzględnia wprost feedbacku oraz zmian w finalnym wyglądzie rzeźby. Wołanie klienta, żeby pokazać obłupaną bryłę ma dla mnie mimo wszystko sens – klient nie widzi może konkretnie, co rzeźbimy, ale widzi na żywo rozmiar („chyba chciałem coś większego/mniejszego”), materiał („ten kolor kamienia na żywo jest inny niż sobie wyobrażałem”) i może podyskutować o dalszych krokach („chciałbym zobaczyć jego głowę”). Mam temat do przemyśleń, gdy będę przygotowywał kolejną iterację ujęcia tego tematu, a myślę, że prędzej czy później to zrobię – dzięki!

  2. Świetny artykuł Jacku 🙂 Zastanawiam się jednak, jak zastosować iteracyjne podejście w sytuacji „przepisywania” starego produktu, który jest używany przez setki użytkowników, do „nowszej wersji”.

    • Jacek Wieczorek

      Dzięki Justyna, cieszę się, że Ci się podoba.

      Co masz na myśli pisząc o przepisywaniu? Czy chodzi Ci o zmianę technologi (np. zmiana z PHP na Java), warstwy wizualnej (np. odświeżenie wizualne) czy może zmiana technologi a przy okazji dodanie/usunięcie konkretnych funkcjonalności? A może jeszcze coś innego?

      • Mam na myśli konieczność „przepisywania” starego na nowe, ze względu na:
        – nową technologię (bo w starej aplikacji już nie da się nic rozwijać),
        – potrzebę zmiany interfejsu (bo stara nieintuicyjna),
        – częściową zmiana funkcjonalności ( bo wcześniej powstało dużo rozwiązań customowych, a teraz chcemy być „bardziej generyczni i uniwersalni”),
        – poprawę jakości kodu (bo w starej aplikacji ze „spaghetti kodem” nikt nie widział testu jednostkowego) itd.

        • I tutaj przykład Krystiana, odnośnie klienta „który nie chce widzieć ociosanego kamienia, tylko gotową rzeźbę” jest bardzo trafny w przypadku, z którym ja się mierzę 🙂

          • W modelu przyrostowym można łatwiej zaprezentować klientowi zmiany, nowe funkcje w projekcie, zaplanować prace, ustawić milestone oraz zdobyć konkretny feedback do zrobionych funkcji. W podejściu iteracyjnym przy niezbędnych zmianach w projekcie można się spotkać ze stwierdzeniem od strony klienta „przecież to już było zrobione, zapłaciłem za to, dlaczego robicie to jeszcze raz?”. Dodatkowo praca zespołu może być odebrana jako słabej jakości. To podejście może wymagać silnej i jasnej komunikacji oraz zrozumienia od strony klienta a z tym bywa różnie 😉 temat rzeka.. wiele zależy od środowiska w jakim mamy realizować projekt.

        • Jacek Wieczorek

          Dzięki Justyna za rozwinięcie tematu.

          Gdy czytam, to co napisałaś, chodzi mi po głowie scenariusz będący miksem podejścia przyrostowego oraz iteracyjnego. Wybrałbym ze starej aplikacji kawałek do przepisania wg. jakiegoś ważnego dla Was kryterium (np. obszar produktu o najgorszej jakości technicznej) lub wybrał nowego ficzera i zaczął rozwijać go iteracyjnie, w nowej technologi, dbając od początku o pokrycie testami.

          Następnie, jeśli możecie, to stopniowo włączał bym produkcyjnie nowe klocki, stopniowo wygaszając stare. Czyli wraz z upływem czasu, coraz większa część produktu obsługiwana by była przez nowy kod, coraz mniejsza przez stary. Być może pewnych kawałków nie opłaca się przepisywać, trudno mi to ocenić z tej perspektywy. Coś podobnego już doświadczyłem na własnej skórze pracując z dużym, popularnym produktem webowym – był moment, że strona główna produktu była przepisana na nowo, natomiast reszta systemu działała „po staremu”. Następnie krok po kroku nowe „klocki” zastępowały stare.

          W tym co piszesz, sytuację komplikuje chęć jednoczesnej zmiany interfejsu – tutaj ze względu na potrzebę uzyskania spójności może nie być przestrzeni na stopniową, iteracyjną zmianę. A może wcale nie jest to problem? Kwestia indywidualnego przypadku.

          Nawiązując do Twojego komentarza poniżej – odnośnie klienta, który chce widzieć gotową rzeźbę – to brzmi mi to jak duża przestrzeń na wzajemną edukację, budowanie zaufania, wzmacnianie transparentności oraz praca nad obustronnym zrozumieniem. Czyli praca na kolejne miesiące, albo i lata 🙂 Powodzenia!

  3. Nie do końca się zgodzę z jedną rzeczą. Krystian piszę „(…)Zazwyczaj każda iteracja dostarcza coś, ale nie koniecznie cześć produktu. Na przykłąd wynikiem iteracji mogą być spisane wymagania.(…)” A co (patrząc przez pryzmat Scruma, czyli iteracji) z fundamentalnymi zasadami działającego software’u i kodu gotowego do potencjalnego wdrożenia?

    Dla mnie iteracyjne podejście to droga od walking skeleton do good enough, gdzie po drodzę uczymy się czym będzie dla klienta ten poziom w którym można powiedzieć ok – mamy to co nas satysfakcjonuję. Bardzo pasuję mi to też do technicznej strony, czyli nie pisania kodu „na gotowo” – co nie znaczy, że ma być on zły. Powinien umożliwiać dalszy, łatwy rozwój produktu. Trochę taka rosyjska matrioszka.

    Dzięki Jacku za syntezę podejść 🙂 Bardzo fajnie się to czyta.

    • Jacek Wieczorek

      Dzięki Łukasz za komentarz.

      Kawałek wypowiedzi Krystiana rozumiem jako ogólne, przykładowe stwierdzenie, że iteracja, to kawałek czasu w którym dostarczamy „coś”. Czyli dzielimy pracę na części i dostarczamy po kawałku. Patrząc przez pryzmat Scruma, tak jak wspomniałeś, również oczekiwałbym czegoś małego, ale potencjalnie zbywalnego.

      Trafia do mnie to co piszesz o podejściu od walking skeleton do good enough – podobnie patrzę na iteracyjne wytwarzanie.

  4. Bardzo ciekawy artykuł, dziękuję. Zastanawiam się nad możliwą wizualizacją podejścia kaskadowego, co mógłbyś też użyć jako infografiki. Czy byłby to rysunek:
    1. Szkic (makieta) rzeźby
    2. Kamień
    3. Gotowa rzeźba?

    • Jacek Wieczorek

      Dzięki Marek.

      Podejście kaskadowe mogłoby zostać przedstawione tak na napisałeś. Chodziłoby generalnie o pokazanie, że kolejne kroki to fazy, które dopiero kiedy zostaną zrealizowane w całości, dadzą oczekiwany produkt. W świecie tworzenia oprogramowania, często niekoniecznie ten, który klient miał w głowie, na moment kiedy zlecał prace.

  5. Jacek Wieczorek

    Dziękuję za Wasze komentarze – na wszystkie odpowiem, jak tylko wrócę z wyjazdu w góry. Jedyna zwinność, która mi w ostatnie dni w głowie, to ta na stoku 😉 #snowboarding


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x