Czysty agile

Czysty Agile. Powrót do podstaw
Robert C. Martin
Helion 2020, (org. 2019)
3 out of 5 stars

Czysty Agile była chyba najbardziej wypatrywaną książką w tematyce zwinności w 2019 roku. Oczekiwania były bardzo wysokie, co nie dziwi, bowiem Robert C.Martin (w branży lepiej znany jako Wujek Bob), programujący od 1970 r., od dawna należy do najbardziej poczytnych autorów książek o programowaniu (Czysty Kod, Mistrz czystego kodu czy Czysta architektura), jest charyzmatycznym prelegentem, promotorem ruchu Czystego Kodu, TDD, programistycznej odpowiedzialności (m.in. Przysięga programisty), a w końcu sygnatariuszem, współautorem Manifestu Agile (ba, jego plecy widać nawet na słynnym zdjęciu). Zapowiadał się zatem bestseller. Wielu liczyło na książkę o agile, po którą – w końcu – z zaciekawieniem sięgną programiści. Inni spodziewali się nowości, drugiej fali agile’owej rewolucji.

Niestety książka tych nadziei nie spełnia. Pewnie dlatego, że jest zupełnie inna, niż większość się spodziewała.

Znajdziesz tu moje osobiste wspomnienia oraz opinie powstałe w czasie 20 lat moich doświadczeń z agile – zastrzega na początku Martin, dodając później, że nie znajdziesz tu niczego zdumiewającego, wstrząsającego, rewolucyjnego, a na końcu podsumowując: napisałem tę książkę, ponieważ uznałem, że nadszedł czas, by ktoś wstał i zaczął krzyczeć o tym czym agile był i czym być powinien. Cytaty te doskonale charakteryzują całą książkę. A jej zawartość nie zdziwi nikogo, kto śledzi wystąpienia autora na konferencjach, ze słynnym The Land That Scrum Forgot z Norwegian Developers Conference z 2011 roku na czele.

Zaczynamy od stwierdzenia autora, że agile jest niewielką ideą dotyczącego niewielkiego problemu niewielkich zespołów programistycznych pracujących nad niewielkim rzeczami – i to hasło przewija się potem niemalże przez całą książkę. Martin z uporem to podkreśla i wielokrotnie do tego wraca. 

Od samego początku podkreśla też swoją złość, że gdzieś zagubiono pierwotną ideę agile. Wskazuje, że stała się ona ofiarą własnej popularności. Że została wykorzystana przez wielu, którzy po prostu chcieli na niej zarobić. Że pod agile podłączono wiele koncepcji nie mających nic wspólnego z jego pierwotną koncepcją (m.in. Lean, Kanban, LeSS, SAFe). Frustracja Boba jest widoczna w każdym zdaniu. Jest to jednak frustracja uzasadniona. Zwinne tworzenie oprogramowania nawet nie zbliżyło się do tego, czym mogłoby być  – podsumowuje to Kent Beck w zamieszczonej krótkiej recenzji.

Zaczynamy od skróconej historii podejścia do wytwarzania oprogramowania (najwięcej słów poświęcono oczywiście parodystycznie przedstawionemu waterfallowi – każdy kto ten rodzaj organizacji projektów przeżył, odnajdzie tu siebie), o tyle wartościowej, że autor sam w branży jest już niemalże pół dekady, wiele widział, wiele przeżył. Z właściwą sobie swobodą pióra i ironią kreśli zatem swoje wspomnienia. Nie brak tu zgorzknienia czy najstarszego sposobu odreagowania deweloperów, ucieczki w szyderczy humor (Świat zespołu tworzącego oprogramowanie to świat, w którym terminy są niezmienne, ale wymagania zmieniają się nieustannie). Jak twierdzi, w latach 70. bardzo zwiększyła się ilość programistów i wtedy narzucono ideę, że lepiej jest pracować w wielkich zespołach nad wielkimi projektami, zapominając o zdobytym przez wcześniejsze dwadzieścia lat doświadczeniu. Następne 30 lat zajęło nam przypomnienie sobie, że trzeba robić małe rzeczy w małych zespołach, co ostatecznie doprowadziło do Manifestu Agile. A i owszem, nie zabrakło historii słynnego spotkania w Snowbird (z ciekawym stwierdzeniem – nie pamiętam wiele z dwóch dni naszego spotkania. Inni mają z niego zupełnie inne wspomnienia). 

Jaki jest zatem czysty agile według Roberta C.Martina?

Myślę, że wielu praktyków może się poczuć co najmniej zaskoczonych, a może i dotkniętych niektórymi stwierdzeniami autora. Może najbardziej tym, że z miejsca, bez ceregieli sprowadza całą ideę na ziemię, pozbawiając jej wszelkich powstałych przez lata nadbudówek czy nazbyt górnolotnych stwierdzeń. A przecież agile to prosta technika, która ma zapewniać dane potrzebne do podejmowania decyzji (Zwinny zespół programistów uzyskuje dokładnie te informacje, których menedżerowie potrzebują do podejmowania decyzji). Z wielkim hukiem pękają pompowane od lat balony: w agile nigdy nie chodziło o to, żeby pracować szybko, ale o to, żeby jak najwcześniej się dowiedzieć jak wielkie mamy kłopoty, żeby móc zarządzać w tej sytuacji.

Niektórych zdziwi też waga przykładana do wykresów spalania. Ba, Wujek Bob niektórych purystów może doprowadzić do palpitacji serca, kiedy ci dotrą do takich wątków jak iteracja zerowa, demonstracja czy – o zgrozo –  spotkanie na stojąco. 

To co chyba jest tu najważniejszą, najmocniejszą tezą, wybrzmiewa w rozdziale o praktykach technicznych. Bez TDD, refaktoryzacji, prostego projektu i (owszem) programowania w parach Agile staje się tylko nieskuteczną wydmuszką i karykaturą tego, czym miała być. Uzasadnienie? Agile bardzo skutecznie pozwala wytworzyć ogromny bałagan i bez odpowiednich praktyk technicznych nie będzie możliwe zachowanie odpowiedniej jakości i produktywności.

Stąd opisy BDD (Behavior-Driven Development) w kontekście wymagań i DDD (Domain-Driven Design) w kontekście kodu. Stąd olbrzymi nacisk autor kładzie na wyraźnie faworyzowane przez niego XP (eXtreme Programming) – jego zdaniem najlepiej zdefiniowane, najpełniejsze i najmniej zaśmiecone spośród zwinnych procesów. Martin nie byłby sobą, gdyby nie skorzystał z okazji, żeby po raz kolejny promować profesjonalizację branży i podkreślać jak wielkie znaczenie ma praca programisty, jak wielka odpowiedzialność leży w jego rękach i jak kiepsko nam to wszystko idzie – pod kątem gotowości i szybkości zmian, pod kątem szybkiego starzenia się i erozji wartości kodu czy w końcu jakości rozwiązań. Przytacza mało znane – a szkoda –  prawa klienta i programisty, będące pewnym odpryskiem opracowania manifestu, wskazuje, że stosowanie TDD powinno być wręcz… wymuszone prawnie. Po drodze pokazuje wartość snu, krytykuje nadgodziny, wskazuje jak ważne jest zrównoważone tempo pracy.

O technicznych problemach związanych z agilem poczytamy też w końcowym rozdziale autorstwa Sandra Marcuso (skąd dodatkowy autor, o tym dalej), który bez ceregieli mocno peroruje:

Dzisiejsi nauczyciele agile (jak się domyślam, tłumaczenie Agile Coach, dop. M.W.) nie mają wielkich (o ile mają jakiekolwiek) umiejętności technicznych, przez co nie mogą przekazać programistom wiedzy w postaci praktyk technicznych. Co więcej, bardzo rzadko poruszają tematy inżynieryjne. Przez lata programiści zaczęli traktować nauczycieli agile jak kolejną warstwę w strukturze menedżerskiej – jak ludzi mówiących im, czym mają się zająć, a nie pomagającym im lepiej wykonywać swoją pracę.

I potem:

Na początku XXI wieku większość nauczycieli agile miało dużą wiedzę techniczną, ale dzisiejszym nauczycielom tej wiedzy brakuje, przez co nie mogą nikogo nauczyć technik programowania ekstremalnego, ani porozmawiać z przedstawicielami biznesu na tematy inżynieryjne.

Wracając jednak do głównego nurtu i autora książki.  Co Robert C. Martin w kontekście agile zwalcza, w co nie wierzy?

Nie wierzy w kadrę zarządzająca średniego szczebla, która jego zdaniem, w przeciwieństwie do menedżerów firm i programistów, unika ryzyka i blokuje transformacje agile. A propo transformacji. Tu Martin uważa, że można tworzyć organizację pracujące agile, ale nie transformować, przekształcać istniejące.

Nie wierzy w rolę nauczyciela agile, a zatem: Scrum Mastera. Niespecjalnie wierzy też w Scruma, któremu trochę się tutaj dostaje. Generalnie radzi ignorować istniejące metody zwinne (poza XP), bo jego zdaniem i tak trzeba będzie zmieniać i dopasować cały proces do własnych wymagań.

Woli słowo iterację, niż sprint, bo projekt to dla niego maraton, a nie bieg z największą możliwą prędkością.

Bardzo mocno wyśmiewa certyfikację (to czysty dowcip i zbiór absurdów).

Nie wierzy w agile na dużą skalę (bo dotyczy przecież małych zespołów).

I – co więcej – uważa, że agile dotyczy wyłącznie oprogramowania.

To wszystko obrazuje nam z jak bardzo subiektywnym spojrzeniem na zwinność mamy tu do czynienia. I, że choć ciężko nie zgodzić się z głównymi tezami prezentowanymi przez Martina, spora część z nich mogłaby stanowić punkt wyjścia do niezwykle ciekawych polemik, gorących dyskusji. I to chyba główna zaleta tejże książki.

A jej wady? Dla mnie główną jest fakt, że całość nagle, dość gwałtownie się… urywa. I tak w pewnym momencie, w połowie rozdziału, nieoczekiwanie dostajemy tekst innego autora dotyczący narzędzi, potem kolejny autor i tekst dotyczący nauczania agile (przedstawiający poglądy zupełnie inne, niż Martina, co on sam zresztą wcześniej podkreśla), aż w końcu cały rozdział poświęcony rzemieślnictwu, czyli ruchowi software craftmanship. Nie sposób nie wspomnieć tu o niedbalstwie wydawcy, który autorów tychże tekstów (a także epilogu) prezentuje na okładce jako autorów przedmów… I tak w sumie 30 stron ze 180 stronicowej książki jest autorstwa kogoś innego. Treści te wstawione są dość dziwnie, bez większych komentarzy autora, pisane innym stylem, sprawiają wrażenie umieszczonych trochę na siłę, jako zapchajdziury, jakby autorowi zabrakło już weny czy chęci. W pewnym momencie jego wywód po prostu się urywa i wraca na koniec w postaci bardzo zdawkowego podsumowania. Te obce treści są też niewątpliwie słabsze, niż cała książka.

Pewnym problemem jest też nierówny poziom całości i może nieuporządkowanie całego wywodu. Z pewnością większość czytelników z pewnym znużeniem przeczyta przydługie wprowadzenie do User Stories, Story Points czy INVEST. 

Dla mnie Czysty agile nie spełnia pokładanych nadziei. Owszem, Roberta C.Martina bez wątpienia wciąż warto czytać (niekoniecznie się z nim zgadzając), jednak – niestety – o wiele lepsze wrażenia miałem słuchając jego prelekcji o agile, aniżeli czytając tę książkę, mającą wszakże w pewien sposób to wszystko usystematyzować i uporządkować. Szkoda.

#agile