Blog
Metody Agile narodziły się w odpowiedzi na wdrożenia typu “wszystko na raz” metod kaskadowych. Ich główną bronią w walce z nimi jest iteracyjny model pracy. Praca w krótkich iteracjach jest sztandarową cechą Agile, czymś, co ludzie z miejsca rozumieją, nawet przy nieznajomości filozofii Agile. Jest ona też pierwszą praktyką, jaką przyswajają sobie zespoły. Z mojego doświadczenia wynika, że niezależnie jak nieliczne praktyki Agile zespół stosuje, zazwyczaj wykorzystuje iteracje.
A może jednak nie?
Jesteś pewien, że faktycznie iterujesz?
Iteracyjny kontra inkrementalny
Są dwa sposoby rozbicia pracy na ciąg mniejszych kroków: inkrementalny i iteracyjny.
Inkrementalny oznacza budowanie produktu kawałek po kawałku, z kompletnych, wykończonych elementów. Wyobraź sobie zestaw klocków Lego. Doczepiasz nowy klocek do poprzedniego, z każdym krokiem coraz bardziej kompletując swoją budowlę, ale nie cofasz się, aby przełożyć w inne miejsce czy zmienić kolor klocków, które już ułożyłeś.
Iteracyjny oznacza rozpoczęcie od zgrubnej formy produktu i stopniowe cyzelowanie go aż wyłoni się wersja ostateczna. Wyobraź sobie drewnianą rzeźbę. Najpierw odłupujesz duże kawałki drewna, odsłaniając ogólny kształt, z grubsza przypominający sylwetkę człowieka. W kolejnym przebiegu tworzysz ręce, nogi i głowę. Następnie nos, uszy i palce. W końcu rzeźbisz drobne detale, takie jak zmarszczki czy włosy.
Development wyłącznie inkrementalny
Z mojej obserwacji wynika, że wiele zespołów, twierdzących, że iterują, tak na prawdę wykorzystuje podejście całkowicie inkrementalne.
Rozpoczynają one zazwyczaj od ściśle zdefiniowanego zestawu wymagań lub szczegółowych makiet. Nierzadko oficjalnie zaakceptowanych. Następnie budują aplikację ekran po ekranie. Zgodnie z założeniami integrują, testują i przeprowadzają demo swojej pracy po każdej “iteracji”, jednak rzadko kiedy otrzymują jakikolwiek znaczący feedback ani nie ulepszają już zaimplementowanych funkcjonalności w żaden istotny sposób.
Brzmi znajomo?
To mimo wszystko o wiele lepsze podejście niż kaskadowe i niesie za sobą liczne korzyści:
- zdolność do wyliczenia prędkości (Velocity) zespołu, monitorowania postępu projektu i prognozowania daty jego zakończenia
- okazję do częstej integracji i wdrożeń
- możliwość priorytyzacji funkcjonalności i anulacji lub wydania produktu wcześniej w przypadku jeśli przekroczy budżet
- okazję do przeprowadzania retrospekcji i usprawniania procesu developmentu w regularnych odstępach czasu
Jednakże, wszystkie powyższe korzyści są związane wyłącznie z procesem. Takie podejście może pomóc Ci podnieść dokładność Twoich estymacji, jakość Twojego code review lub poprawić Twoją automatyzację wdrożeń, lecz nie zaowocuje żadnymi ulepszeniami produktu z punktu widzenia użytkownika końcowego.
Development inkrementalny pomaga ulepszyć jak produkt jest budowany, ale nie co jest budowane.
Development iteracyjny
Podejście iteracyjne skupia się dla odmiany na tym, co jest budowane.
Zespoły stosujące iteracyjny development zazwyczaj zaczynają jedynie od ramowych wymagań, najczęściej w formie User Stories, albo od bardzo zgrubnych makiet. Następnie wielokrotnie ulepszają lub nawet całkowicie przeprojektowują każdą z funkcjonalności, otrzymując istotny feedback i wcielając go w życie po każdej ze zmian.
Takie podejście rodzi znaczące korzyści:
- zdolność do wypuszczenia MVP (produktu o kluczowej funkcjonalności) i rozpoczęcia generowania dochodu i zbierania feedbacku od rzeczywistych użytkowników końcowych tak wcześnie jak to tylko możliwe
- bardziej zogniskowany, użyteczniejszy interfejs, nie zaśmiecony “martwymi” funkcjonalnościami i niepotrzebnymi “wodotryskami”
- funkcjonalności bazujące na faktycznych potrzebach użytkowników końcowych a nie na zgadywaniu
- bardzo ekonomiczny development; poprawa błędów designu i koncepcyjnych oraz wykluczenie niepotrzebnych funkcjonalności następuje wcześnie, gdy jest to jeszcze tanie
- zdolność do anulacji projektu lub dokonania “pivotu” bez poważniejszych strat
Poprawny proces jest iteracyjny ORAZ inkrementalny
Oczywiście nie istnieje coś takiego jak czysto iteracyjny development. Aby móc skutecznie iterować – otrzymywać częsty feedback i stale ulepszać produkt – musisz pracować małymi przyrostami.
Podejście inkrementalne i iteracyjne nie muszą stanowić przeciwności. Wyobraź je sobie jako piramidę z podejściem inkrementalnym u podstawy a iteracyjnym na szczycie.
Aby móc iterować, musisz najpierw wyśmienicie opanować proces inkrementalny. To jednak tylko pierwszy krok a nie cel. Twoi klienci są zainteresowani Twoim produktem a nie Twoim procesem. Jeżeli zbudujesz nie to co trzeba, ani trochę nie będzie ich obchodziło, jak efektywnie to zbudowałeś.
Zacznij od opanowania podstaw, ale nie utknij w połowie piramidy!
Na jakim poziomie jest Twój obecny zespół? Masz jakieś pomysły jak pomóc mu wspiąć się na wyższy poziom inkrementalno/iteracyjnej piramidy? Podziel się nimi w sekcji komentarzy poniżej!
