poniedziałek, 26 grudnia 2016

Zwinne, ale co?



W ramach kolejnej nowej świeckiej tradycji rodem zza oceanu, zwanej „black friday", zostałem uszczęśliwiony internetową superatrakcyjną ofertą na szkolenie certyfikujące z inżynierii wymagań jednej ze szkół analizy biznesowo-systemowej. Dla zachęty mogłem pobrać materiały dydaktyczne, w tym przykładowe testy egzaminacyjne. Jako że duszę już dawno zaprzedałem innej, konkurencyjnej szkole (i w tej dziedzinie panuje plemiennizacja), wiedziony ciekawością co do różnic w doktrynie zacząłem z zapałem rozwiązywać test. Choć do testu dołączony był klucz, wcale nie szło mi jak z płatka, bo im dalej, tym bardziej dyskusyjne wydawały mi się jedynie słuszne odpowiedzi. Każda szkoła opiera się na systemie prawd jedynie słusznych, ale prawdy mojej szkoły są „mojsze”, tym samym „słuszniejsze”. Podejrzewam, że wyznawcy każdej "innej" szkoły rozumują dokładnie tak samo, w myśl maksymy:

"Bo nie ważne, czyje co je. Ważne to je, co je moje!"


jak śpiewał niegdyś niezapomniany Kazimierz Grześkowiak.

Męczyłem się strasznie. Prawie każde pytanie, a raczej odpowiedź, otwierało kolejne pole do dyskusji. Przypomniał mi się wtedy pewien epizod, który może być dobrym komentarzem do sytuacji.

Jakiś czas temu postanowiłem zdobyć prawo jazdy kategorii „A”. Jako że już od kilkudziesięciu lat byłem kierowcą samochodowym i od paru motocyklistą bez cenzusu, wydawało mi się , że będzie to czysta formalność. Egzamin teoretyczny zaliczyłem z marszu. Tzw. manewrówkę na placu także. Jazdę uliczną oblałem. Nie popełniłem w zasadzie żadnego wykroczenia, ale w opinii egzaminatora zbyt krótko jechałem prawym pasem na 3. pasmowej jezdni. Kodeks w ówczesnym brzmieniu nie definiował jak wystarczająco długo tym pasem jechać trzeba, więc tylko egzaminator wiedział co znaczy „wystarczająco”. Wdałem się w dyskusję, próbując wykazać, nie dość, że nie popełniłem żadnego błędu formalnego, zachowałem się wielce racjonalnie z punktu widzenia sztuki prowadzenia pojazdów w ruchu ulicznym, bo na podstawie mojego bogatego doświadczenia kierowcy i znawcy zasad ruchu… itd, itp. Pan egzaminator grzecznie przerwał mój wielce uczony, gęsto przeplatany intensywną gestykulacją wywód i usłyszałem zupełnie bezinteresownie przepełnioną jado-satysfakcją radę:

„Panie! Pan nie masz myśleć! Pan masz zdać egzamin!”



Łatwo powiedzieć! Przyzwyczajenie to druga natura człowieka. Po 3. nieudanej próbie zaliczenia jazdy zmuszony byłem przejść kurs doszkalający. Zgłosiłem się do instruktora, który na dzień dobry zadał standardowe pytanie:

"Pan chce się nauczyć jeździć, czy zdać egzamin?"

Długo nie mogłem się zdecydować, więc zdałem dopiero za 7. razem.


Wróćmy jednak do naszych baranów, czyli do testu certyfikacyjnego. Już na wstępie trafiłem na z pozoru niewinne, ale rozwiewające wszelkie wątpliwości co do jedynie słusznej linii szkoły pytanie o to,

co wskazuje, że kaskadowe podejście (Waterfall) do wytwarzania systemów nie jest właściwe?


Możliwe były 4 odpowiedzi, w tym jedna prawidłowa. Drogą eliminacji zgadłem, że waterfall jest niewłaściwy bo

biznes jest nieprzewidywalny (business is volatile).

Rozumiem, że gdyby biznes był przewidywalny, Waterfall byłby jak najbardziej „ok.”, ale jako że każdy biznes – jak i wszystko zresztą – z istoty swej jest nieprzewidywalny, Waterfall z definicji nie może być „ok”, co przecież wszyscy wiemy, bo miliony nie mogą się mylić.
Miałem z tym testem więcej problemów tego pokroju, ale przypomniałem sobie mądrą radę pana egzaminatora od prawa jazdy i test zaliczyłem w mig. Na podstawie pozostałych pytań (nawet nie odpowiedzi) szybko wywnioskowałem, że jedynie słusznym jest podejście Agile, choć zabrakło tego kluczowego, stawiającego kropkę nad „i” pytania :

co wskazuje, że podejście Agile do wytwarzania systemów jest właściwe?


Przecież coś wskazywać musi, skoro tak jest, a miliony nadal się nie mylą!


Pal sześć Waterfall - i tak już powieszono na nim wszystkie możliwe psy świata - ale co ma wspólnego nieprzewidywalność z jakąkolwiek metodyką czegokolwiek? Niebezpieczeństwo poznawcze samego pytania testowego, jak i odpowiedzi, polega na tym, że sugeruje, iż istnieją jakieś cudowne podejścia, które rozwiązują problem nieprzewidywalności. Wystarczy je tylko poznać (podejście) i zastosować. Drogi adepcie sztuki inżynierii wymagań. Mam złą wiadomość. Nie ma aż tak sprytnych podejść, które mogą nas zupełnie wybawić od skutków nieprzewidywalności, albowiem nieprzewidywalność, w tym biznesu, jest immanentną cechą rzeczywistości, a nie brakiem umiejętności przewidywania. Mam również dobrą wiadomość - bez nieprzewidywalności rzeczywistość nie mogłaby funkcjonować. Z nieprzewidywalnością jest jak z grawitacją - wydaje się, że utrudnia życie, ale strach pomyśleć jak świat wyglądałby bez niej.
Oczywiście, zawsze zachodzą jakieś okoliczności, które sugerują, że w danych konkretnych warunkach jakieś podejście wydaje się lepsze niż inne, ale to jeszcze nie powoduje, że wybór tego lepszego jest gwarancją sukcesu przedsięwzięcia. Podejmując dzisiaj decyzję o wyborze opcji na przyszłość, nie mamy żadnej wiedzy, czy ten wybór okaże się właściwym. O tym dowiemy się dopiero wtedy, gdy ta przyszłość zmaterializuje się. To jest tzw. „paradoks strategii”.


„Największe sukcesy odnoszą strategie oparte na tych trwałych wyborach dokonanych dziś, które są najlepiej dopasowane do warunków jutra. Ale nikt nie wie, jakie będą te warunki, bo przyszłość jest nieprzewidywalna.” ( M.E Raynor)


Jak rozwiązać ten paradoks? Wyznawcy Agile sugerują, by nie dokonywać trwałych wyborów na dłuższą metę (unikanie, o ile to możliwe, działania "na zapas"). Inni, by wkalkulować w koszty porażkę, uprzednio odkładając „coś” na czarną godzinę, by pokryć skutki złego wyboru (ubezpieczenie). Są i tacy, którzy chcą w ogóle wyeliminować nieprzewidywalność kreując z góry zaprojektowaną, czyli w pełni przewidywalną rzeczywistość. Wydaje się to niewykonalne. Nieprawda. To kwestia relacji kosztów do zysków i możliwości technicznych. Możliwości już są, a koszty, nawet kosmiczne, opłaca się ponieść w imię równie kosmicznych zysków.

A jak działa Natura? Wiele wskazuje, że istnieje jakiś Master Plan (dla jednych są to prawa fizyki, dla innych prawa nie z tego świata), który nie pozostaje w sprzeczności z kwantową naturą rzeczywistości. Na pewnych poziomach Natura idzie czystym Watefall-em, wytwarzając głęboko przemyślane i zaprojektowane (przez kogo?) w najdrobniejszych szczegółach konstrukcje o ogromnych zdolnościach adaptacyjnych, gdzie projektem jest np. genom. Na innych - czysto Agile-owo: reaktywnie i iteracyjnie. Natura choć nie zawsze działa w Agile, wytwarza systemy o cechach agile, które mają umiejętność reagowania na zmienne warunki otoczenia nie poprzez przebudowę, a zmianę parametrów działania. Dopiero gdy zaburzenie jest zbyt duże lub długotrwałe, byty naturalne trwale zmieniają swą konstrukcję...albo giną.
Można to zilustrować za pomocą przebiegu cyklu poznawczo decyzyjnego (patrz post Analiza, czyli projekt, czyli decyzja).





A co z paradoksem strategii?


"Przyszłości nie da się przewidzieć, ale można ją zrozumieć.” (M.E Raynor)

Rozumiejąc przyszłość, bardziej opłaca się konstruować systemy ją antycypujące i elastyczne na tyle, by same radziły sobie ze zmiennością i nieprzewidywalnością w określonym zakresie, niż stale utrzymywać system w stanie permanentnej „nadążnej” budowy.

Należy jednak najpierw zainwestować w zrozumienie przyszłości.


Systemy sztukowane ad hoc z reguły mają krótki żywot, bo nigdy nie wiadomo, czy korekta, która sprawdza się dzisiaj, sprawdzi się jutro. Uczmy się od Natury (jakkolwiek ją rozumieć) lub… na przykład budowniczych miasteczek-centrów handlowych. Ostatnio często przejeżdżam w pobliżu takiej budowy i mam okazje obserwować postępy budowy. Taktyka budowniczych polega na tym, że cały docelowy teren przyszłego centrum zostaje na wstępie wytyczony, uzbrojony, pokryty siecią dróg, parkingów i inną infrastrukturą umożliwiającą sprawne dotarcie klienta do marketu i komunikację wewnątrz. Markety powstają później, iteracyjnie, na z góry wyznaczonych działkach, przeznaczenie których nie jest (nie musi być) z góry zdeterminowane. Najpierw Waterfall-owo (koncepcja, planowanie, projektowanie, budowa) wytworzono platformę, czyli teren miasteczka, by potem wypełnić ją już Agile-owo kolejnymi modułami, czyli marketami, których przeznaczenie w przyszłości może ulec zmianie, w zależności od potrzeb biznesowych, w reakcji na bieżące zapotrzebowanie inwestorów lub klientów. Podobnie powstają galerie handlowe. Waterfall-owo i Agile-owo jednocześnie.

Czy można budować systemy IT w myśl powyższej zasady? Oczywiście, że można. Przykładem niech będzie Android i wszystko to, co dzieje się wokół niego. Właśnie dlatego, że trudno przewidzieć (nieprzewidywalność) indywidualne potrzeby poszczególnych użytkowników, mają oni do dyspozycji szerokie możliwości konfigurowania i parametryzowania swej „prywatnej” wersji środowiska w miarę ewolucji potrzeb (zmienność). Android jako środowisko powstawał Waterfall-owo, bo jest to poważna, kosztowna, strategiczna inwestycja, ale apki na smartfony powstają Agile-owo. Innym przykładem produktów skali desktopowej niech będą projekty typu reach-client-platform (RCP). A czymże są serwery aplikacji, szyny usług, platformy procesowe? Praktycznie wszystkie rozwiązania „chmurowe”, czy „platformowe”, tak właśnie są budowane: najpierw powstaje gruntownie przemyślana, dokładnie zaprojektowana i wykonana platforma o znaczeniu strategicznym - a jakże, Waterfall-owo, bo pomyłka na tym etapie może wywrócić przedsięwzięcie - a później aplikacje, moduły, wtyczki itp. drobnica, słowem to wszystko, co jest reakcją na bieżącą dynamikę otoczenia i może, czasami wręcz musi, być dostarczane "zwinnie". Technologie wspierające powyższe podejście z nurtu component-based-development (proszę nie mylić z object-oriented-development, bo to kompletnie dwie różne historie) już od dawna są powszechnie dostępne i to za względnie małe pieniądze. Kiedyś (kilkanaście lat temu) rzeczywiście były luksusem dostępnym jedynie zamożnym branżom (telekomy, banki, ubezpieczenia). Dzisiaj trafiły pod strzechy i są stosowane nawet w lokalnych rozwiązaniach. „Ino chciało się chcieć” je wykorzystać. Za takim podejściem przemawiają również względy ekonomiczne. Przy kalkulacji, co bardziej się opłaca, warto jednak posłużyć się metodyką liczenia TCO (Total Costs of Ownership) zamiast prostą kontrolą budżetu projektu Agile-owego.


Branże produkujące dobra materialne stosują paradygmat „zwinności produktowej” od dawna. Nam, informatykom, przychodzi to z trudem, choć możliwości technologiczne są na wyciągnięcie ręki. Trzeba przełamać stereotyp, że jedynym sposobem rozwiązania problemu biznesowego przy pomocy produktów IT jest „wyszydełkowanie” nowego kodu, a „zwinność” zespołu wytwórczego rozwiąże problem zmienności i nieprzewidywalności biznesowej. Może i rozwiąże, ale na krótko. Lepiej niech biznes najpierw przyłoży się do postawienia problemu nieprzewidywalności biznesowej na poziomie strategicznym. My, informatycy i para-informatycy nie kreujmy natomiast fałszywego wrażenia, że przy pomocy jakichś „czary mary metodyk" jesteśmy w stanie zdjąć ten problem z ich pleców. Technologia i organizacja nie zastąpią strategii, choć mogą ją wspierać. Jeśli „biznes” nie jest w stanie sformułować wymagań co do swej „zwinności” biznesowej, to "IT" z pewnością w tym go nie wyręczy. Powiedzmy to uczciwie - ani Agile, ani Waterfall, ani żadna inna metodyka.


Dylemat "to be Agile, or not to be Agile" jest stary jak świat. Kiedyś - w czasach zamierzchłych, gdy autorzy Manifestu Agile jeszcze robili babki z piasku - był znany jako wybór pomiędzy podejściem prognostycznym (ang. predictive) a podejściem adaptacyjnym (ang. adaptive) i dotyczy de facto stopnia tolerancji biznesu na ryzyko (czy w warunkach nieprzewidywalności lub braku informacji/wiedzy podejmować przedsięwzięcie). Taktyka iteracyjna (ang. iterative) znana była nawet budowniczym piramid (kwestia organizacji pracy w czasie i przestrzeni). Jeśli tak na to spojrzymy, to okazuje się, że z perspektywy inżynierii oprogramowania nie ma sprzeczności pomiędzy jednym i drugim podejściem, zatem można je z powodzeniem stosować jednocześnie w ramach jednego projektu. Pewne elementy architektury można / trzeba wytwarzać w podejściu prognostycznym (np. platformy), a inne w podejściu adaptacyjnym (np. plugin-y). Autorzy Manifestu widać nie czytali dzieł "starych mistrzów" i byli przekonani, że wymyślają koło po raz pierwszy. Słowem natomiast nie zająknęli się o ryzyku. Ogłaszając Manifest nie zrobili nic poza złożeniem deklaracji, iż preferują podejście "adaptive & iterative" bez względu na tolerowany przez biznes poziom ryzyka. Ryzyko to zmartwienie biznesu, a nie programistów - zdaje się głosić Manifest.

Agile - czyli podejście adaptacyjno-iteracyjne - powinien być stosowany wtedy, gdy biznes a priori, w założeniach strategii, godzi się (najlepiej na piśmie, bo pamięć bywa ulotna) na wysokie ryzyko nietrafienia w rynek (jakkolwiek go rozumieć) z produktem o czasie i gdy musi mieć możliwość szybkiej taktycznej korekty. Gdy w reakcji na zmiany otoczenia musi działać "szybciej niż myśli", by nie utracić pozycji rynkowej. Gdy wysokość premii za „zwinność” uzasadnia relatywnie wysokie ryzyko nieuzyskania zakładanego efektu, przekroczenia terminu lub budżetu.

Przypomnijmy sobie w jakich okolicznościach został ogłoszony Manifest. Rok 2001 - był to szczytowy okres boomu dot-comm-ów. Stawką były miliony zielonych płynące z gry akcjami. Wielu programistów było współwłaścicielami firm IT lub premie mieli wypłacane w opcjach na akcje. Wielu z nich zostawało milionerami w weekend. Kto nie miał „działającego kodu” na czas, wypadał z gry. Struktura firmy, procedury, procesy, udokumentowane know-how itp. nie miało dla nakręconych inwestorów i tzw. rynków żadnej wartości. Liczył się tylko działający kod „tu i teraz”, bo to dawało nadzieję na szybkie i wysokie zyski z gry akcjami. Nie o produkty IT szło, a pozycję firm IT na rynku, a dokładnie cenę ich akcji. Taką sytuację można było ogarnąć tylko przy pomocy „zwinnego” podejścia do biznesu, jakim było wytwarzanie oprogramowania w myśl Manifestu, a nie do wytwarzania oprogramowania, jako działalności stricte inżynieryjnej.

Manifest Agile odnosił się do działalności biznesowej w obszarze "produkcja oprogramowania", a nie inżynierii.

Zasady inżynierii od czasu Manifestu nie uległy zmianie. Zmienił się natomiast biznes. Dzisiaj najważniejszym aktywem firm jest know-how - zarówno technologiczne, jak i marketingowe - w stanie "zbywalnym" i umożliwiającym prawną jego ochronę przed zakusami konkurencji ( i tej uczciwej, i tej nieuczciwej). Działający kod już nie jest taki najważniejszy z biznesowego punktu widzenia, bo nie stanowi o przewadze konkurencyjnej, gdyż trudno go uchronić przed zhakowaniem. Patenty, prawa autorskie, znaki towarowe - to decyduje o wartości firmy i jej pozycji na rynku. Zaczynają to rozumieć i respektować nawet Chińczycy. Kto ma know-how i zagwarantowaną prawnie wyłączność do niego, ten rozdaje karty.

Czasy dot-com-boomu dawno minęły. Pora przemyśleć, co dziś oznacza być „Agile”.

Wasz M.





Diagramy zamieszczone w niniejszym tekście zostały wykonane przy użyciu notacji ArchiMate®.
ArchiMate® jest znakiem zastrzeżonym The Open Group.


2 komentarze:

  1. Bardzo spodobał mi się ten artykuł :) Nie spotkałam się z tak szerokim podejściem do zagadnienia. Czytało się jednym tchem i nie dało się powstrzymać od śmiechu z humorystycznych akcentów :)

    Kiedy pisano manifest agile dla mnie komputer był jedynie narzędziem do pisania na Gadu-Gadu :) W każdym razie miałam okazję porozmawiać z jednym z jego twórców. Odniosłam wrażenie, że jest to reakcja na projekty gubiące się w biegunie przesady z formalizmem, które zapominają, że przede wszystkim wytwarzają oprogramowanie, które ma pomagać w biznesie. Każda przesada bywa niebezpieczna i rodzi skrajne reakcje.

    Rzeczywiście warto pamiętać, żeby bardziej cenić:
    Ludzi i interakcje od procesów i narzędzi
    Działające oprogramowanie od szczegółowej dokumentacji
    Współpracę z klientem od negocjacji umów
    Reagowanie na zmiany od realizacji założonego planu.

    To sensowne i racjonalne. Bardziej cenić oznacza jednak to, co oznacza - bardziej cenić a nie uciekać w drugą skrajność.

    Koncepcja się bardzo spodobała i przyjęła. W końcu prostota, łatwość, szybkość. OK, to są cenne wartości. Przechodzenie na agile w wielu miejscach poprawia komunikację, motywację, poczucie, że każdy wnosi wkład, że praca posuwa się naprzód, że dostarczamy często małe rzeczy, które już biznesowi pomagają. Super.

    Na drugim biegunie mamy przeświadczenie, że wszystko musi się nazywać agilowo, dokumentacja i formalizmy to zło.

    Wokół popularnego pomysłu rośnie biznes. I OK, jeśli pokazujemy coś co potrafi pomóc, to czemu nie.

    Dla mnie to jednak narzędzie do czegoś. I jako narzędzie to moim zdaniem trzeba traktować - wyciągać wtedy, kiedy jest potrzebne i stosować tak, aby pomogło w konkretnej sytuacji. Narzędzie a nie cel sam w sobie.

    OdpowiedzUsuń
    Odpowiedzi
    1. Droga Haniu.
      Jeśli dziwisz się co tak dudni, to tłumaczę – właśnie biję się w piersi i niniejszym proszę o przebaczenie (jeszcze klęczę na grochu, ale to słabo słychać). Okazałem się gamoniem, który nie umie prawidłowo skonfigurować bloggera. Dopiero teraz wyświetlił mi się Twój komentarz.

      Dziękuję za zainteresowanie tematem i ciekawy returm. Mam podobne zdanie.
      Problem w tym, że agile w programowaniu (bo można uprawiać go w różnych sferach życia) - a w szczególności jego najpopularniejsza odmiana , scrum - przeistoczył się w sposób na życie. Niektórym tak głęboko zapadł w świadomość, że z rodziną kontaktują się tylko raz dziennie na standupach, a od wielkiego święta na retrospektywach. Mnie uczono, że watefall, spirala, V i VV to tylko metody w inżynierii oprogramowania. Agile to jednak zjawisko kulturowe. Pracowałem w zespołach waterfallowych i o dziwo, tam też ceniono kod (za coś płacili nam przecież, choć mało) i kontakty międzyludzkie (czasami do późnych godzin wieczornych). Jako że było to bardzo dawno, bo „za komuny”, a obowiązywała wtedy gospodarka planowa i nikt nie myślał o zaspakajaniu zmieniających się potrzeb klienta wewnętrznego i zewnętrznego, to z powodów oczywistych biznes był bardzo przewidywalny, więc nie było potrzeby stosowania agile.
      Wbrew pozorom nie tylko w przypadku programistów wykonywany zawód, a raczej sposób jego uprawiania, wytwarza jakąś subkulturę. Górnicy, marynarze i rybacy, wojskowi i policjanci, posłowie, aktorzy i cyrkowcy, oraz inne profesje wytworzyły swoje subkultury, które manifestują się poprzez liczne rytuały i mitologie. Dlaczego programiści mieliby być gorsi?
      Z agilem w programowaniu mam jednak pewien problem. Ostatnio przeczytałem, że w projekcie softu dla Boeinga 777 doliczono się ok. 300 tys. wymagań. Domyślam się , że zgodnie z zasadą Pareto ok. 60 tys. dotyczyło podstawowego problemu w projekcie, czyli latania. Ciekaw jestem jaką metodyką robiono ten soft? Poważnie rozważam opcję, czy w kolejną podróż do Stanów nie wybrać się pociągiem.

      Usuń