Wracamy do naszego trochę zapomnianego agile’owego słowniczka. Dzisiaj rozprawiamy się z dwoma słowami i zastanawiamy się, co to znaczy „iteracyjny”, a co „przyrostowy”. A może już wiecie?
Iteracyjna praca
Z etykietką „iteracyjny” w kontekście naszej typowej pracy deweloperskiej rozprawialiśmy się już w tekście „Dlaczego iteracyjne wytwarzanie oprogramowania?” Niestety, my również wpadliśmy w semantyczną pułapkę, opisaną przed wielu laty przez Jeffa Pattona.
W opublikowanym w 2008 roku tekście pod tytułem „Don’t Know What I Want, But I Know How to Get It„, Jeff Patton rozprawia się ze znaczeniem słów „iteracyjny”, „przyrostowy”, a nawet „potencjalnie wdrażalny”. Ponieważ robi to właśnie w agile’owym kontekście, to jest to świetny wstęp do tego, o czym my chcielibyśmy dziś przypomnieć (i sprostować) w odniesieniu do kilku naszych starszych tekstów.
Przede wszystkim, jeżeli myślimy o iteracjach, to mamy na myśli wykonywanie jakiegoś procesu wielokrotnie, w sposób powtarzalny. Patrząc od strony programistycznej, powiedzielibyśmy, ze „iteracyjny”, to taki, który wykonywany jest w pętli. I co prawda poszczególne przebiegi mogą różnić się szczegółami, ale co do zasady cały czas robimy mniej więcej to samo.
Przykładem iteracyjnego algorytmu jest Sprint w Scrum. Ma on pewne określone ramy i zasady, ale też znaczną dowolność. Jednak każda iteracja (zwana Sprintem) jest podobna i na pierwszy rzut oka widać, że co jakiś czas robimy „to samo”. Oczywiście, szczegóły są różne i nigdy nie wykonujemy dokładnie tych samych czynności, ale powtarzamy pewien proces.
Z kolei w kontekście tworzonego produktu, iteracyjna budowa to ciągłe przeprowadzanie zwinnych eksperymentów, dopracowywanie naszego rozwiązania, szukanie rozwiązań i dochodzenie do finalnego rozwiązania metodą prób i błędów. W przypadku Scruma powiemy, że naszą pracę weryfikujemy wypuszczając produkt na rynek bądź oddając go do użytku klientowi.
Przyrostowy Inkrement
We wspomnianym artykule Jeffa Pattona, jako przykład pracy iteracyjnej służy praca artysty. Malując obraz zaczyna on od szkicu, potem dodaje detale, kolory, kolejne warstwy farby, próbuje różnych rozwiązań, niektóre zostawia, a inne zamalowuje, aż w końcu powstaje finalne dzieło.
Dla kontrastu, pracą przyrostową będzie po prostu malowanie mieszkania. Najpierw jedna ściana, potem druga, potem sufit, itd. Każdy etap jest zamkniętą całością, a w trakcie jego powstawania nie odkrywamy nowych możliwości, ani nie modyfikujemy założeń. (Jeff jako przykładu użył po prostu kolorowanek.)
Produkt tworzony przyrostowo, to po prostu coś, co budowane jest po kawałku. Problem z tym podejściem jest taki, że aby dobrze podzielić produkt na niezmienne kawałki, musimy go bardzo dobrze znać. A więc wracamy do waterfalla i marnowania czasu nad szczegółową analizą, która i tak się zmieni.
Czyste podejście przyrostowe to nie tylko malowanie Mona Lisy kawałek po kawałku (od razu z wszystkimi detalami). To także górny wiersz słynnego rysunku Henrika Kniberga, który opowiada o MVP.
Czy to znaczy, że proces przyrostowy nie ma sensu?
Przyrostowo, ale mądrze
Każdy fragment naszego powstającego przyrostowo produktu może również być budowany iteracyjnie. I zwykle tak się dzieje, przynajmniej jeżeli myślimy o zwinnych metodykach i metodach.
Taka hybryda jest dla nas wszystkich najbardziej intuicyjna i jest też powodem, dla którego te dwa słowa powodują trochę nieporozumień. Trudno jest bowiem zastosować „czyste” rozwiązanie.
W Scrumie Inkrement powstaje, zgodnie z nazwą, przyrostowo. Ale sam proces tworzenia naszego produktu jest iteracyjny. Stąd też typowym działaniem Zespołów Scrumowych jest podział dużych funkcjonalności na mniejsze. Przyrostowo z kolei traktowane są Epiki. To znaczy, że zwykle rozwijamy od jednej do kilku gałęzi czy obszarów.
Na wysokim poziomie mamy zdefiniowane „grube klocki”, którymi zajmujemy się po kolei. Jeżeli zaś chodzi o każdy z nich, to realizujemy go iteracyjnie. To, jakie dokładnie funkcje będzie zawierał dany obszar i jak będą one wyglądały, wychodzi w trakcie pracy.
Wracając do artykułu Pattona – przyrostowo budujemy naszą kolekcję obrazów, każdy z nich malując iteracyjnie.
Iteracyjny i przyrostowy w praktyce
„Dlaczego iteracyjne wytwarzanie oprogramowania?” to typowy przykład na to, jak można namieszać, próbując unikać powtórzeń. Trudno jest napisać kilkaset słów na jeden temat, unikając przy tym nadmiernego powtarzania pewnych sformułowań. Może więc warto byłoby go przeredagować?
I znów, odnosząc się do tematu dzisiejszego tekstu, można by powiedzieć, ze nasz agile’owy blog powstaje iteracyjnie. W końcu tydzień w tydzień publikowane są na nim dwa teksty. Proces pisania i publikowania postów jest stały i powtarzalny. Wypisz, wymaluj – iteracyjny.
Z kolei nasze szkolenia Scrum i agile powstają przyrostowo. Każdy przeprowadzony warsztat czy szkolenie kończy się wprowadzeniem drobnych usprawnień do materiałów czy wypróbowaniem nowego podejścia lub zmianą któregoś z ćwiczeń.
Trudno jednak powiedzieć, żeby te programy powstawały iteracyjnie. Proces nie jest ściśle opisany ani powtarzalny, zaś częstotliwość zmian jest różna. Czasami zjeździmy pół Polski bez zmiany nawet literki, a czasami nowe pomysły pojawią się między pierwszym, a drugim dniem warsztatu.
Tak samo nie przejdzie mi przez gardło (ani klawiaturę) stwierdzenie, że teksty na blogu powstają przyrostowo. O ile tekst nie dołącza do top 10 najpopularniejszych wpisów, to zwykle już do niego nie wracamy. Nie jest on udoskonalany, ani nie dopisujemy kolejnych przemyśleń. Po prostu, tak jak dzisiaj, piszemy kolejny.
Aczkolwiek tym razem mam nadzieję, że różnicę pomiędzy iteracyjnym, a przyrostowym mamy z głowy już na zawsze i kolejne odsłony nie będą potrzebne.
