Blog

Nieustannie zaskakuje, ale i zasmuca mnie brak świadomości wielu Scrum Masterów, że iteracyjne i inkrementalne podejście do rozwoju oprogramowania nie wystarczy, by twierdzić, że działa się zwinnie. Ta iteracyjność i inkrementalność jest bowiem pochodną empiryzmu, który stanowi prawdziwą podstawę Agile. Jeśli Scrum Master, osoba zobligowana do dbania o zrozumienie i stosowanie Scruma w praktyce, nie wie albo nie rozumie, czym jest empiryzm, czy może działać skutecznie?

Całkiem niedawno wdałem się w ciekawą dyskusję na temat tego, czy w projektach informatycznych rzeczywiście Waterfall zupełnie się nie sprawdza, czy też jest to pochodną nieumiejętności jego stosowania. Teza rozmówcy była następująca: skoro podejście kaskadowe sprawdza się w projektach urbanistycznych, budowaniu statków lub dróg i mostów, równie dobrze można użyć jej do realizacji oprogramowania, jeśli tylko projekt jest powtarzalny, a domena techniczna i biznesowa dobrze znana.

Pozwoliłem sobie zupełnie się z tym nie zgodzić, bo choć analogie pomiędzy rozwojem oprogramowania a innymi dziedzinami, w których wytwarza się produkty, są kuszące, bardzo często wiodą nas na manowce.

Kiedy Agile, a kiedy Waterfall

Opowiadając o Agile na szkoleniach lub opisując to podejście w książkach, trenerzy często wskazują obszary, w których Waterfall się sprawdza, aby nie podsuwać słuchającym lub czytającym myśli, że jako propagatorzy Agile z definicji uważają tradycyjne predyktywne metody za wcielone zło. I rzeczywiście, jeśli budujemy most, raczej nie czynimy tego w sposób zwinny, tylko kaskadowo wytwarzamy najpierw projekt, potem tworzymy plan budowy, następnie realizujemy ten plan i poddajemy kontroli to, co udało się wytworzyć, zanim pozwolimy po moście komukolwiek przejść lub przejechać.

Z drugiej strony w czasie szkoleń oraz we wspomnianych książkach, wskazuje się na przyczyny, dla których podejście zwinne jest pożądane przy wytwarzaniu oprogramowania. Przyczyna leży w złożoności zarówno produktów, jak i celów, które chcemy osiągnąć, oraz środowiska, w którym software będzie wytwarzany, a potem używany. Czynników, które należy wziąć pod uwagę, jest ogromna liczba, większości z nich nie potrafimy nawet skutecznie mierzyć, nie mówiąc już o kontrolowaniu lub choćby przewidywaniu ich wpływu na powstający produkt.

Metody zwinne oparte są o empiryzm, co oznacza mniej więcej taki sposób postępowania: skoro wiadomych jest dużo mniej niż niewiadomych, zróbmy pierwszy krok (eksperyment), oceńmy co i w jaki sposób udało się wytworzyć, po czym podejmijmy decyzje, co dalej (kolejny eksperyment). W ten sposób małymi kroczkami dążymy do celu, którym jest jakaś wartość biznesowa. O ile znamy ten cel, prawie nigdy nie znamy drogi, jaka do niego prowadzi i poprzez serię eksperymentów (iteracji), odkrywamy tę drogę. Dopuszczamy przy tym, że sam cel może się zmienić, jeśli w trakcie zmierzania ku niemu pojawią się istotne ku temu powody.

Czy budowanie katedry to problem złożony?

Wróćmy zatem do pomysłu poszukiwania analogii między projektami budowlanymi a informatycznymi. Przyjmijmy, że projekt ma na celu wzniesienie ogromnej katedry. Taki produkt bez wątpienia jest niezwykle skomplikowany, równie skomplikowany będzie sposób jego wytwarzania, ponieważ trzeba zadbać o zaspokojenie wielu zasad, które wynikają z praktyk wypracowanych przez mistrzów budownictwa, ale też z praw fizyki. Czy aby na pewno budowanie katedry będzie kiedykolwiek zmaganiem się ze złożonością?

Zatrzymajmy się na moment przy obydwu określeniach: złożony i skomplikowany.

Złożony to taki, w którym niewiadomych jest więcej niż wiadomych, wiele elementów i powiązań między nimi będziemy odkrywać, gdy tylko zaczniemy złożonym problemem się zajmować. Wiemy, że problemy złożone da się rozwiązać (bo ktoś już to robił przed nami), ale my sami nie mamy doświadczenia ani ekspertów, którzy potrafiliby to zrobić bez eksperymentowania i poszukiwania dobrych (skutecznych, a zarazem ekonomicznych) rozwiązań.

Skomplikowany to taki, w którym jest wiele niewiadomych, ale wciąż więcej jest rzeczy znanych. Tak, jest mnóstwo elementów, o które trzeba zadbać, jest wiele zależności między nimi – ale znamy te zależności, znamy te elementy, potrafimy przy mniejszym lub większym wysiłku nad nimi zapanować. Eksperymentowanie będzie potrzebne z rzadka. Nie tylko wiemy, że problem skomplikowany da się rozwiązać, ale dysponujemy ekspertami, którzy wiedzą, jak to robić – oni poprowadzą pozostałych przez ten proces za rękę.

Jeśli zatem popatrzymy na budowanie katedry i samą katedrę przez pryzmat tego, jak bardzo złożona jest sama budowla i jak złożony jest proces jej wytwarzania, odkryjemy, że złożoności tam niewiele. Nie będzie jej w prawach fizyki, wytrzymałości materiałów, zasadach statyki budynku i tak dalej – bo te są niezmienne, znane od lat, mierzalne; wszystko da się wyliczyć i zaprojektować w sposób bezpieczny. Katedra nie przemieszcza się, więc nie będzie narażona na nieprzewidywane dynamiczne siły. Będzie stać na gruncie, który możemy starannie przebadać. I tak dalej.

Jeśli przy budowaniu katedry pojawia się jakiś obszar złożoności, dotyczy on przede wszystkim ludzi: błędów, jakie popełniają, realizując procedury i niedoróbek lub oszustw, jakich się mogą dopuścić. Przemyślany proces, ze ściśle zdefiniowanymi procedurami kontrolnymi, oraz precyzyjny plan realizowania inwestycji, pozwala przewidzieć i zadbać właściwie o wszystko, a przy obecnie stosowanych technologiach i materiałach nawet zmiany pogody nie mają większego wpływu na przebieg prac.

A to oznacza, że dziś budując katedrę, niekoniecznie musimy eksperymentować.

Jeśli istnieją skomplikowane projekty informatyczne…

…wtedy bez wątpienia można realizować je bardzo efektywnie w sposób tradycyjny (kaskadowy). Zrobić dogłębną analizę, projekty, wszystko pięknie rozplanować, dołożyć mechanizmy kontrolne i rozpocząć realizację. Podobnie jak z katedrą, powodzenie niemal gwarantowane.

Co więcej, ku zaskoczeniu niektórych, można w tym modelu działać jak najbardziej iteracyjne i inkrementalnie. Planując, możemy przecież założyć, że realizacja odbywać się będzie etapami – na przykład dwutygodniowymi – w ramach których będziemy dodawać coraz to nowe funkcjonalności do produktu. Prawie jak w Scrum, czyż nie?

Różnica jest jednak zasadnicza, bo brak w tym empirycznej kontroli procesu. W opisanym powyżej podejściu wciąż działamy predyktywnie, czyli dokładnie wiemy, co chcemy zrealizować, nie poszukujemy najlepszych rozwiązań i nie potrzebujemy eksperymentów. Podział na iteracje i inkrementalne rozwijanie oprogramowania w ten sposób jest jedynie strategią realizacji, opisaną planem. Efekt działań jest z góry określony i znany.

Kaskadowe podejście, nawet jeśli wyznacza jakieś iteracje i przyjmuje, że oprogramowanie tworzone jest przyrostowo, w ogóle nie zakłada, a często nawet nie dopuszcza zmienności wymagań lub modyfikacji celu, do którego zmierzamy. Nie ma też możliwości korzystania z lepszych rozwiązań, jeśli zidentyfikujemy je w trakcie realizacji projektu, ponieważ plan opisuje nasze postępowanie od początku do końca. A zatem zupełnie inaczej niż w Scrumie.

Złożoność w projektach informatycznych

Niestety, najprawdopodobniej nie istnieją projekty informatyczne, które byłyby proste lub skomplikowane, ale nie złożone. Czynników, których nie sposób kontrolować i przewidywać jest całe mnóstwo, począwszy od ludzi zaangażowanych w proces, poprzez technologię, jakiej używamy, do samych wymagań.

Zastanówmy się po raz kolejny nad problemem budowania katedry. Dlaczego nie jest ona dobrą analogią „przewidywalnego projektu informatycznego”? Ponieważ w projektach informatycznych tym, co zmienia się najszybciej i najczęściej są wymagania. Jeszcze nie ucichnie stukot klawiatury, na której spisaliśmy specyfikację produktu, a wymagania już stają się w jakimś stopniu nieaktualne. W czasie realizacji projektu co rusz odkrywamy, że coś trzeba zrobić inaczej, że czegoś zrobić się nie da, że założenia były błędne…

Poszukiwanie analogii do budowania katedry jest zatem nieuzasadnione. Bo przecież tam wymagania się nie zmienią w sposób istotny – na przykład nie wymyślimy w połowie realizacji, że jednak trzeba całość obrócić o dziewięćdziesiąt stopni i budować z kamienia zamiast cegły, a w ogóle to będzie port lotniczy zamiast kościoła. Niezmienne też będą prawa fizyki, grunt nie zmieni się z kamiennego w bagno z dnia na dzień, klimat też się nie zmieni drastycznie w krótkim czasie.

Zwinni budowniczy katedr

Należy uczciwie przyznać, że przed wiekami, gdy powstawały gotyckie katedry, a ludzkość uczyła się pokonywać kolejne wcześniej nieprzekraczalne bariery, budowanie kościołów było procesem nad wyraz zwinnym. Znany był cel: postawić budowlę ku chwale boga. Był jakiś projekt, ale dbano przede wszystkim o piękno, nie potrafiono w świadomy sposób projektować ścian czy stropów. Posługiwano się dobrymi proporcjami, wzorowano się na innych budowlach i… eksperymentowano. Wiele katedr runęło, doskonałym przykładem jest katedra świętego Piotra w Beauvais (Francja). Budowle takie powstawały iteracyjnie i przyrostowo, często rozrastały się w trakcie realizacji, bo projekt był nieustannie modyfikowany i upiększany.

Dzisiaj tak właśnie (zwinnie) tworzymy złożony software, przy czym raczej nie ma co sobie robić dużej nadziei, że za jakiś czas ta domena stanie się prosta lub choćby skomplikowana. Tak stało się w budownictwie, ponieważ eksperymentowanie pozwoliło na poznanie praw fizyki, zasad projektowania stabilnych konstrukcji, zmierzenie wytrzymałości materiałów, wypracowanie metod obliczeniowych i technologii, która to wszystko wspiera. Choć zajęło to wiele setek lat, dziś już więcej wiemy, niż jest niewiadomych.

W rozwoju oprogramowania nie ma niczego, co byłoby choćby w przybliżeniu ekwiwalentem praw fizyki, redukujących złożoność. Przy budowaniu systemów informatycznych w praktyce brak ograniczeń. Wysyp start-upów, które najczęściej kończą bankructwem, pokazuje, że nawet kryterium opłacalności przedsięwzięcia niekoniecznie stanowi dziś barierę limitującą wyobraźnię. To oznacza, że domena ta stawać się będzie raczej coraz bardziej złożona i nigdy nie ulegnie uproszczeniu.

Jeśli jesteś Scrum Masterem

Ponieważ istotą tej odpowiedzialności jest zapewnienie, by korzystający z metody Scrum czynili to świadomie, każdy Scrum Master musi rozumieć, czym jest empiryzm. To pozwoli przede wszystkim odpowiedzieć na pytania, dlaczego w Scrumie są takie, a nie inne zdarzenia oraz takie, a nie inne artefakty. To też pozwoli podejmować świadome działania w każdym przypadku, w którym Scrum Guide nie dostarcza gotowej odpowiedzi na pytanie, co należy zrobić, by być Agile.