Dlaczego iteracyjne wytwarzanie oprogramowania? A dlaczego nie! Pójdźmy dalej – wszystkie złożone problemy dużych rozmiarów powinniśmy rozwiązywać iteracyjnie czyli inaczej mówiąc – etapami.
Iteracyjny czyli jaki?
Opisywałem już problemy, na jakie napotykamy przy okazji używania słów metodyka i metodologia. Także i przy dzisiejszym temacie nie zaszkodzi mały wstęp filologiczny. Określając coś mianem „iteracyjny”, mamy na myśli „powtarzalny” i „wykonywany etapami”.
Jeśli przygotowując obiad mamy pokroić mięso w kostkę, zrobimy to właśnie iteracyjnie. Najpierw podzielimy duży kawałek na pół, a następnie każdą z połówek – ponownie na pół, stosując ten sam „algorytm”, aż do uzyskania zamierzonego efektu.
„iteracja – metoda w analizie matematycznej i programowaniu polegająca na wielokrotnym stosowaniu tego samego przekształcenia lub procedury; też: kolejne przekształcenie lub procedura” (SJP PWN)
Oczywiście, doświadczony kucharz nie będzie dzielił każdego zbyt dużego kawałka na dwa mniejsze, tylko zastosuje szybszą metodę. Może on na przykład najpierw pokroić mięso w plastry, a dopiero potem zabrać się za każdy z nich. Nikt nie powiedział, że algorytm w kolejnych iteracjach musi być dokładnie taki sam.
Na pewno jednak mierząc się z dużym zadaniem pracujemy iteracyjnie, a nie nad wszystkim na raz.
Podziel problem iteracyjnie
Wracając na chwilę do Cynefin frameworku, przypomnijmy przepaść dzielącą dwie domeny problemów – skomplikowane i złożone. W tych pierwszych istnieją widoczne związki przyczynowo-skutkowe, chociaż nie są one oczywiste. Pozwalają nam jednak wypracowywać dobre praktyki i przewidywać skutki naszych działań.
Problemy złożone są zbyt duże i zbyt trudne, żebyśmy mogli przewidywać skutki naszych działań. Możemy jedynie spróbować coś zrobić (przeprowadzić eksperyment) i na jego podstawie, patrząc wstecz, spróbować określić co się wydarzyło i dlaczego.
Każdy duży problem składa się z mniejszych, których stopień złożoności jest co najwyżej równy wyjściowej domenie. I tak problemy złożone będą zawierały w sobie inne (mniejsze) problemy złożone, skomplikowane i oczywiste.
Już sama ta dekompozycja często potrafi ujawnić prawdziwą naturę zagadnienia. Nie raz odkryjemy, że pozornie złożona kwestia tak naprawdę składa się z dużej liczby oczywistych problemów, których to rozwiązanie jest dobrze znane. Wystarczyło spojrzeć z innej perspektywy i przestać zajmować się całym problemem na raz.
Dekompozycja wymagań czy problemów i wynikające z niej lepsze zrozumienie tematu, a także upraszczanie zadań to tylko jedne z korzyści wynikających z takiego podejścia. Innym jest możliwość pracy iteracyjnej.
Jak zjeść słonia?
Ze problemem o uroczym tytule „jak zjeść słonia” mierzyliśmy się już na naszym kanale na YouTube. Porcjowanie problemu pozwala nam na wydzielanie z niego takich kawałków, które jesteśmy w stanie przełknąć za jednym razem i w konsekwencji – pracę iteracyjną.
Często słyszmy, że coś jest tak skomplikowane, że nie wiadomo nawet od czego zacząć. Zwykle jednak, gdy wypiszemy wszystkie poszczególne podzadania i etapy, to pojawi się jakiś naturalny kandydat na pierwszy ogień. Czasami nawet będzie ich kilka.
„Jak zjeść słonia? Po kawałku.”
Mając do dyspozycji wiele różnych składowych danego zagadnienia mamy większą dowolność co do kolejności, w jakiej będziemy je realizować. Tutaj istnieją dwie taktyki, wybierane przez różne typy ludzi.
Jedni mówią, żeby zacząć od najtrudniejszego zadania. W ten sposób dowiemy się o problemie najwięcej, rozpoznamy największe przeszkody i zweryfikujemy możliwość realizacji w założonym czasie. Nie ryzykujemy też zostawienia najbardziej pracochłonnego fragmentu na sam koniec, gdy terminy będą już bliskie. Pierwsza iteracja będzie najtrudniejsza.
Inni z kolei radzą, żeby zacząć od zadania najbardziej oczywistego. Dzięki niemu nabierzemy rozpędu, szybki sukces podniesie morale i zachęci do działania, a nauka zdobyta przy realizacji zadania spowoduje uproszczenie pozostałych fragmentów. Pierwsza iteracja będzie najprzyjemniejsza.
Ponieważ znajdujemy się w domenie złożonej Cynefin frameworku, nie znajdziemy tu „dobrych praktyk”. Musimy podjąć decyzję sami i sprawdzić, jakie przyniesie rezultaty w tym konkretnym przypadku. Na pewno jednak nie powinniśmy próbować uporać się ze zbyt dużym problemem na raz.
Agile, czyli iteracyjne wytwarzanie oprogramowania
Na naszym wystąpieniu na Agile Warsaw, którego fragmenty możecie zobaczyć na YouTube, wspominaliśmy o ludzkim braku umiejętności szacowania, o nieustannie zmieniającym się otoczeniu i o błędach poznawczych, które zaciemniają nam prawdziwy obraz sytuacji.
Brzmi to cokolwiek złowieszczo, ale w takiej rzeczywistości przyszło nam się obracać i zamiast na nią narzekać, powinniśmy się do niej dostosować. Możemy nawet próbować na niej skorzystać.
W sytuacji, gdy prawie nic nie jest pewne, a to co jest i tak może się szybko zmienić, nie ma sensu długoterminowe planowanie czy ścisły harmonogram. Musimy być przygotowani na ciągłe zmiany. Musimy umieć je wykorzystać.
Dobry plan jest po to, żebyśmy mieli co zmieniać.
Pracując nad małymi fragmentami większego zagadnienia, będziemy robić to etapami. Dzięki temu po każdym z nich będziemy w stanie zaktualizować nasze szacunki, zmienić drogę którą idziemy, a nawet zupełnie zaniechać pracy, która nie przyniesie nam korzyści.
Gdy każdy z etapów będzie miał taką samą długość, przyjęło się mówić, że pracujemy iteracyjnie. Korzyści płynących z takiego podejścia już chyba nie trzeba powtarzać. Jest to jedyny sposób, w którym dajemy sobie szansę na odpowiedź na zmiany i w pełni akceptujemy niepewność naszych przewidywań. Ograniczamy horyzont do tego, czego możemy być pewni.
Bo tylko tak, po kawałku, potrafimy rozwiązywać bardzo duże problemy. I wcale nie musimy się ograniczyć tylko do wytwarzania oprogramowania.
