Czy twój Agile umył rączki?
- Tytuł: Czysty Agile. Powrót do podstaw
- Autor: Robert C. Martin (Wujek Bob)
- Rok: 2020
- ISBN: 978-83-283-6304-5
Z książkami Wujka Boba mam od kilku lat pewien problem. Z jednej strony pisze o ważnych rzeczach, które są kluczowe dla pracy programistów. Z drugiej strony niektóre jego koncepcje mają już swoje lata i wymagałby weryfikacji. To powoduje, że do książki o Agile podchodziłem z lekkim sceptycyzmem. Od kilku lat koncepcja „zwinnego” programowania jest poddawana krytyce. Szczególnie jej najpopularniejsza implementacja, czyli SCRUM. Krytycy wskazują, że metodyka ta nie sprawdza się w IT, bo jest „za dużo…” spotkań, procesów, papierologii itp. Jednocześnie jak posłucha się ludzi, którzy tego SCRUMa wdrażają i mają na tym polu sukcesy, to nie wygląda to aż tak źle. Tutaj chcę wspomnieć naszą wrocławską SCRUM Mamę, czyli Agatę Sobek-Kreft, która kilka lat temu zaliczyła Tour de JUG z tematem spotkań w SCRUMie:
I teraz w moje ręce trafia książka, która jest cieniutka objętościowo (180 kilka stron) i już na wstępie autor zaznacza, że nie chce uczyć Agile, ale przedstawi swoją opinię na jego temat. Cała historia zaczyna się od historii powstania Agile Manifesto. Jest to o tyle ciekawe, że Wujek Bob uczestniczył w jego tworzeniu, choć jak sam zaznacza pamięć już nie ta i opisuje tamto spotkanie ze swojej perspektywy. To chyba najfajniejsza część książki, jeżeli tylko interesujesz się historią IT.
Następnie mamy opis, czym Agile tak naprawdę jest i po co powstał. Jeżeli miałbym wskazać najważniejszy cytat z książki, to będzie definicja problemu, jaki agile miał rozwiązać:
Agile dotyczy małych i średnich zespołów. Kropka.
Jest to o tyle ważna część, że jasno powiedziane jest, że metodyka Agile ma dostarczać danych, które pozwalają na organizacje pracy. Sama organizacja pracy, zdaniem autora, opiera się o jasno zdefiniowane prawa i obowiązki po stronie biznesu jak i programistów. Co ciekawe większość tej części opisuje problemy z zarządzaniem w IT, a nie typowo techniczne wyzwania.
Kolejne rozdziały to omówienie praktyk biznesowych i technicznych, które pozwalają wdrożyć agile. Mamy więc omówione planowanie pracy i jak sobie poradzić z estymacją czasu wykonania (nie da się). O tym, czym są małe wydania z punktu biznesu. Jak prowadzić testy akceptacyjne i dlaczego nie zatrudnia się do tego testerów po stronie technicznej. Praktyki techniczne skupiają się na wykorzystaniu koncepcji programowania ekstermalnego. Pisanie testów, praca w parach czy refaktoryzacja. To wszystko łączone jest praktykami zespołu, które skupiają się na komunikacji, szczególnie na szybkim zgłaszaniu fakapów.
Dwa ostatnie rozdziały (jeden autorstwa Sandra Mancusa), to swoisty poradnik, jak stać się Agile w bardziej sformalizowany sposób. Mamy więc tutaj omówione różne cechy, które powinna mieć organizacja i ludzie w niej pracujący, by rozpocząć reformę. Omówione są też przypadki brzegowe np. działania mające sabotować zmiany. Jest też trochę o certyfikacji i formalizmach związanych ze SCRUM. Ważne jest jednak to, że autorzy (tak, tu wchodzi Mancus) wyraźnie podkreślają, że maja świadomość, iż wokół SCRUM narobiło się dużo syfu.
Na zakończenie, chcę powiedzieć, że ta książka jest dobra. Może nie jest wybitna czy rewolucyjna, jak w swoim czasie był „Czysty Kod”, ale jest dobra. Nie nauczysz się z niej Agile ani SCRUMa, ale dzięki niej łatwiej będzie ci zidentyfikować fakapy. Książka ta też demitologizuje Agile, jako uniwersalne narzędzie do zarządzania projektami. Zresztą:
Dlaczego nie próbowaliśmy rozwiązywać problemów wielkich zespołów? Wynika to z prostego faktu, że nad rozwiązaniem problemu wielkich zespołów eksperci pracują już od jakichś pięciu tysiącleci. Problem wielkich zespołów jest problemem związanym ze społeczeństwem i cywilizacją. A jeżeli mielibyśmy spojrzeć na naszą cywilizację, to wydaje się, że całkiem nieźle udało nam się poradzić sobie z tym problemem.
W jaki sposób zbudować piramidę? Najpierw trzeba rozwiązać problem wielkich zespołów. Jak wygrać drugą wojnę światową? Najpierw musisz rozwiązać problem wielkich zespołów. W jaki sposób wysłać ludzi na Księżyc, a potem bezpiecznie sprowadzić ich na Ziemię? Najpierw musisz rozwiązać problem wielkich zespołów.
Ale te wielkie projekty nie są jedynymi sukcesami wielkich zespołów, jakie mieliśmy okazję zobaczyć. W jaki sposób należy zbudować sieć telefoniczną albo sieć autostrad, albo internet, albo iPhone’a, albo samochód? Wszystkie te projekty wymagają rozwiązania problemu wielkich zespołów. Powstała infrastruktura i możliwości naszej globalnej cywilizacji są dowodem na to, że naprawdę rozwiązaliśmy problem wielkich zespołów.
Wielkie zespoły to problem, który został już rozwiązany.
Problem, który nie był jeszcze rozwiązany pod koniec lat 80. XX wieku, gdy rozpoczynał się ruch Agile, był związany z małymi zespołami tworzącymi oprogramowanie. Nie wiedzieliśmy, jak należy efektywnie organizować względnie małe grupy programistów, żeby te mogły działać skutecznie. I to był właśnie problem, którego rozwiązaniem są metody Agile.
To takie proste ;)