Agile Development. Filozofia programowania zwinnego

Przyszedł czas na poruszenie tematów bardziej związanych z samym tworzeniem oprogramowania a nie tylko z samym opisem(modelowaniem) wymagań. Zaczniemy od omówienia książki „Agile Development. Filozofia programowania zwinnego”. Dotyczy, jak tytuł wskazuje, modnych ostatnio zwinnych procesów wytwarzania oprogramowania. Autorzy opisują metodyki agile w wydaniu Extreme Programming, chociaż opowiadają także ogólnie o filozofii agile.

Książka podzielona jest z 3 części, pierwsza z nich mówi o zasadach metodyk zwinnych, przyczynach i celu ich powstania, kilku istotnych zjawiskach dotyczących wytwarzania oprogramowania oraz podstawowych ideach będących podstawą każdej metodyki agile. Na zakończenie tej części autorzy robią krótkie wprowadzenie do XP, opisując cykl życia projektu, skład zespołu XP i role jakie pełnią jego członkowie oraz przedstawiają swoją propozycję wprowadzenia XP. Pozwala to na płynne przejście do następnej części, czyli katalogu praktyk XP. Wszystkie zostały pogrupowane w 5 głównych kategorii będących rozdziałami, a każdej z praktyk został poświęcony odrębny podrozdział. Łącznie opisano 37 praktyk XP. Główne rozdziały rozpoczynają się opisem wprawki, czyli sposobu przyzwyczajenia zespołu do omawianych praktyk. Ostatnia z części opowiada o doskonaleniu procesów XP i osiąganiu mistrzostwa w ich stosowaniu. Jest zdecydowanie bardziej ogólna niż część druga, będąc raczej zbiorem esejów, uwag i rozważań dotyczących wytwarzania oprogramowania. Dostarcza więc raczej wskazówek do kierunków w które można się udać zamiast konkretnych ścisłych rozwiązań.

Kluczową częścią książki są oczywiście prezentacje praktyk. Ocenie ich warto więc poświęcić trochę więcej czasu. Jak już wspomniałem, autorzy umieścili w książce aż 37 praktyk, wykazując się często sporą inwencją twórczą. Zostały opisane 3 całkowicie nowe praktyki, nie występujące w kanonicznym podręczniku do XP¹ a kolejne 13 zostało zidentyfikowanych (nazwanych), będąc albo technikami stosowanymi w rzeczywistości, ale nie zawartymi w podstawowej wersji XP, albo wyprowadzonymi na zewnątrz częściami już istniejących standardów działań. Omówienie praktyk ma zawsze podobny schemat, składający się z wstępu z wyjaśnieniem „o co właściwie chodzi”, dłuższego omówienia działania praktyki oraz podsumowania z krótkim „faq”, uzyskiwanymi efektami, przeciwwskazaniami, innymi możliwościami i listą dalszych lektur. Opis poszczególnych praktyk zajmuje od kilku do góra kilkunastu stron. Autorzy opowiadają o zasadach z praktycznego, pragmatycznego punktu widzenia. Posługują się raczej prostym językiem, który powinien łatwo dotrzeć do każdego. Czasem przedstawiają nawet krótkie opowiadania, przybliżające sposób działania praktyk i problemy które rozwiązują. Jednakże, z powodu pewnej ogólności, nie podają konkretnych technicznych rozwiązań. Nie znajdziecie w tej książce np. ścisłego przepisu jak zrobić kontrolę wersji i system automatycznej kompilacji, ale dowiecie się na zwrócić uwagę przy rozwiązywaniu tych problemów, dostaniecie generalne wytyczne i wskazówki gdzie macie szukać dalej, aby zastosować praktykę w waszym konkretnym przypadku.

Zdrowe i trochę zdystansowane podejście do całego światka IT, chociaż to ostatnie akurat nie do końca – to jest chyba najfajniejsze w tej książce. Klimat o którym mówię można odczuć już w początkowych akapitach pierwszego rozdziału, gdzie autorzy się po prostu zbijają z systemów certyfikacji i przewidują pojawienie się „Certyfikowanych konsultantów agile”, co uważają za zaprzeczenie idei zwinnych metodologii. W tym samym rozdziale znajduje się zdanie, które chętnie widziałbym w każdym książce dotyczącej IT: „(…) zwinne wytwarzanie oprogramowania nie jest uniwersalnym rozwiązaniem”. Według mnie świadczy to o racjonalnym podejściu do omawianych zagadnień, umiejętności krytycznego spojrzenia i zwykłego myślenia o tym co się robi.

Kolejnym plusem książki są przedstawione rozważania i uwagi dotyczące celu budowy oprogramowania. W podręczniku opowiadającym o wytwarzaniu oprogramowania, istotne jest określenie – po co właściwie zajmujemy się pisaniem tego kodu, do czego ma to ostatecznie prowadzić. Autorom udało się ująć istotę tego zagadnienia, chociaż siłą rzeczy efekt jest dość ogólny. Stwierdzili, że miarą powodzenia projektu nie jest zmieszczenie się w zakładanych kosztach, czasie i specyfikacji lecz zrobienie w dobry sposób, przy zadowoleniu uczestników, czegoś pożytecznego. Może brzmi to trochę enigmatycznie, ale opis w książce jest zdecydowanie bardziej rozbudowany. Przedstawione informacje skupiają się na praktykach a nie na zasadach, regułach, wartościach i innych mambo-jambo typu „Business people and developers do joint work”. Takie hasła fajnie brzmią i każdy oczywiście się z nimi zgodzi. Tylko jak je zrealizować? Właśnie ten problem jest kluczowym elementem każdej metodyki – czyli odpowiedź na pytanie „jak?” a nie „co?”. W omawianej książce, autorzy postępują dość rozsądnie: przedstawiają manifest agile, opowiadają o co w nim mniej-więcej chodzi i przechodzą do konkretów, prosto, bez zbędnego filozofowania „czy to są reguły, czy zasady czy coś innego” oraz „jak mądrze zapisać że oprogramowanie ma być dobrej jakości i spełniać oczekiwania zamawiających”.

Na koniec jeszcze drobna ale ważna zaleta książki – bibliografia i silne „podpieranie się” nią. Rzecz której w pracach naukowych na studiach nie doceniałem, ale tu widzę istotę tego narzędzia – „chcesz wiedzieć więcej – przeczytaj to i to”. Do tego autorzy nie rzucają swoich stwierdzeń tak po prostu tylko podpierają się cytatami z innych książek, w których można znaleźć dowód. Przykładowo, mówiąc o wzroście wydajności przy programowaniu w parach wskazują na dokumentację badań, które to potwierdzają.

W porządku, po zachwycałem się książką, teraz trzeba się zbliżyć do rzeczywistości i wymienić trochę wad. Pierwsza rzecz na którą zwróciłem uwagę to niezwykły entuzjazm autorów. Czytając książkę, można odnieść wrażenie, że w trakcie produkcji oprogramowania wszyscy się kochają, nie ma żadnych zgrzytów, polityki, różnic w celach i oczekiwaniach. Autorzy nawet nie zwracają na te sprawy uwagi, dają za to przekaz – XP rozwiąże wszystkie twoje problemy, jest fajne i elitarne, co prawda nie zawsze może zadziałać ale się tym nie przejmujmy. Brakuje mi także informacji o niektórych specyficznych problemach i wdrożeniach Extreme Programming, np. zespoły pracujące w outsourcingu. Z drugiej strony w książce znalazło się trochę wydumanych, mało konkretnych praktyk, które są w mojej opinii po prostu zbędne. Tu mała dygresja – XP ma opinię bardzo rozbudowanej, ścisłej (strict), wymagającej metodyki, składającej się z wielu, często wzajemnie powiązanych reguł. I właśnie ta liczba spraw o których trzeba pamiętać, ogranicza popularność tej wersji procesów agile. A tu autorzy dokładają kilkanaście nowych wytycznych, które trzeba realizować, o których trzeba pamiętać. Jednocześnie wiele z nich nie jest w zasadzie istotna lub jest bardzo mało konkretna. Dla przykładu iteracje, ciągła integracja są konkretne, nawet programowanie w parach jest konkretne, praktyki o nazwie „efektywna praca” czy „wizja” nie są konkretne, są raczej wypełniaczami. Jeżeli już autorzy chcieli wspomnieć o niektórych problemach, jak 60-cio godzinny tydzień pracy i wpływ takiego trybu pracy na wydajność, to mogli to opisać w innej części, przykładowo w informacjach na temat wymaganego środowiska i otoczenia. Z sposobem opisu praktyk wiąże się jeszcze jedna wada – brak zróżnicowania praktyk, brak wyróżnienia ważniejszych i mniej istotnych. Wszystkie są przedstawione w identyczny sposób, do tego w dziwnej wg mnie kolejności. Autorzy zaczynają od najtrudniejszych z nich, typu programowania w parach, jednocześnie kluczowe do działania XP, takie jak iteracje, ciągła integracja itp. znajdują się daleko dalej. Neofici agile mogą po prostu nie wiedzieć od czego zacząć, jadąc według kolejności zaproponowanej w książce, mogą rozpocząć od niewłaściwej strony, zajmując się na początku programowaniem w parach, bez którego można się w zasadzie obyć. Chociaż jest to flagowa praktyka XP, to jednak do zadziałania tej metodyki wymagane są inne reguły, dotyczące przede wszystkim zarządzania kodem. Pomimo sporej przystępności książki, informacje zawarte w książce mogą być niewystarczające przy wdrażaniu Extreme Programming na żywym organizmie. Nie obędzie się albo bez dużej liczby lektur uzupełniających lub zatrudnienia specjalisty od XP. Zresztą, autorzy sami to zaznaczają wprost, wielokrotnie powtarzając „hej, pamiętajcie też że musicie zatrudnić coatcha”, „jeżeli nie wiecie jak coś zrobić – spytajcie swojego coatcha”, „potrzebny wam ktoś z doświadczeniem i wiedzą, najlepiej coatch XP” – co chwilę poruszają temat niezbędności posiadania coatcha XP na stanie. Cóż nie jest to dziwne jeżeli się zauważy autorzy SĄ coatchami XP 🙂

Książka zrobiła na mnie ogólnie dobre wrażenie. Przedstawione wady nie są na tyle istotne aby zakwestionować ewidentne zalety książki. Jedynym poważnym problemem jest optymistyczna wizją działania XP, z którą się nie zgadzam. Autorzy przedstawiają XP i wdrażanie tej metodyki zbyt prosto mamy zespół, mamy „pokój do zabawy”, mamy podręcznik – więc alleluja i do przodu, na pewno jakoś to będzie. Sądzę że próba wdrożenia zespołu w metodykę XP od razu w całości, nawet gdy ludzie są na to przygotowani i pozytywnie nastawieni, skończy się sporym chaosem, przynajmniej przez kilka pierwszych iteracji, a być może kompletnym porzuceniem. Naprawdę trudno jest przestawić się na tak inną filozofię pracy, pamiętając jednocześnie o wszystkich 37 praktykach, pilnowaniu terminów i jakości. Na pewno należy także zwrócić uwagę na potencjalne problemy w działaniu tej metodyki, niestety trzeba poszukać

Podręcznik jest bardzo dobry dla kogoś, kto już używa jakiejś wersji agile i chciałby sobie usystematyzować wiedzę, być może ją poszerzyć lub zobaczyć jak robią to inni. Podoba mi się sposób przekazywania informacji oraz podejście autorów do tematu tworzenia oprogramowania. Sądzę, że książka będzie przydatna nawet dla tych osób, które nie stosują żadnej wersji agile ani nie planują. Zawsze warto poszerzyć sobie trochę horyzonty.

Ocena: 7,5/10