Tworzenie oprogramowania w 30 dni

Tworzenie oprogramowania w 30 dni
Ken Schwaber, Jeff Sutherland
Helion, 2013 (org.2012)

Po tę książkę sięgałem z wielkim zaciekawieniem. Co też panowie Schwaber i Sutherland – twórcy Scruma – mają do powiedzenia o swoim opus magnum, w jaki sposób zachęcają do jego używania, jak rozwijają myśli zawarte w Przewodniku po Scrumie…

I chyba równie wielkie jak to zaciekawienie, było moje rozczarowanie po lekturze całości.

Każdy, kto czytał “Przewodnik po Scrumie” wie jak specyficznym językiem jest on napisany. Trochę amerykańskiego snu i sukcesu, trochę zdań stylistyką i przekazem budzących skojarzenia z manifestami komunistycznymi. Z reguły pierwsze wrażenia są – nie oszukujmy się – średniawe. To specyficzny dokument, który trzeba przeczytać kilkukrotnie, bacznie zwracając uwagę na każde zdanie, aby dokładnie go zrozumieć. Tekst, który zyskuje po czasie, kiedy nabierzemy już nieco praktyki. Tekst, zdaje się, cyzelowany wielokrotnie, słowo po słowie, zdanie po zdaniu.

Zupełnie inaczej jest z tą książką, która sprawia wrażenie pisanej na kolanie, w pośpiechu, po łebkach. Kiepski, chaotyczny styl, wielokrotnie powtarzanie tych samych informacji, nieznośne uproszczenia, często wręcz nachalny marketing – to wszystko mocno przeszkadza w lekturze.

Swoje zrobiło – który to już raz – fatalne tłumaczenie Heliona. Przykładowe kwiatki? Mistrz młyna obsługuje właściciela produktu na kilka następujących sposobów… (sic!) Zespół deweloperski może również zaprosić innych ludzi do uczestnictwa w zebraniu, by zyskać poradę techniczną lub profesjonalną.

Właściwie do kogo autorzy kierują tę książkę? Oddajmy im głos: do liderów w organizacjach, których przetrwanie i przewaga nad konkurencją w dużej mierze zależy od właściwego oprogramowania. (…) którym przy tworzeniu oprogramowania zależy na szybkości, odpowiednich przyrostach oraz wysokim zwrocie z inwestycji. I dalej: (…) posłuży też prezesom, dyrektorom i menedżerom wyższego szczebla do tworzenia lepszego oprogramowania w krótszym czasie, za mniejsze pieniądze, przy większej przewidywalności i mniejszym ryzyku.

Innymi słowy – to książka dla “poziomu C”, menedżmentu, szefostwa, mająca, jak się łatwo domyśleć, przekonać do Scruma. Jest zatem dosyć krótka (wiadomo jak to z czasem “ważniaków”), ale niestety – autorzy wyraźnie chcąc przekazać temat w pigułce – prześlizgują się dość pobieżnie przez wiele tematów, mocno je upraszczając. Często też przykłady z rzeczywistych firm prezentowane są tak, że w zasadzie to Scrum naprawił z miejsca wszystkie problemy i… żyli długo i szczęśliwie.

Pierwsza część tłumaczy nam dlaczego warto pracować w Scrumie. Zaczynamy od tradycyjnego porównania z waterfallem, bazując na najbardziej oklepanych przypadkach (projekt Sentinel FBI, raport CHAOS Standish Group z 2011 r., wykres Staceya)… Doprawdy – brakuje tylko słynnego rysunku z huśtawką (“co klient chciał” vs “co dostał”). W opozycji do tego mamy przedstawionego Scruma, który wydaje się panaceum na wszelkie zło w wytwarzaniu oprogramowania. Na marginesie, jako, że książka wydana była w 2012 roku, mamy do czynienia jeszcze z pewnymi Scrumowymi wprawkami, które nieco zweryfikował czas (ot, chociażby, jak widzimy w samym tytule – preferowana długość sprintów to 30 dni).

Część II i ostatnia to już zasady wprowadzania Scruma w organizacji. Ciekawe co przeciwnicy wszelkich Scrum, but… powiedzą na proponowaną przez autorów metodę “Scrum pro re nata” i zdanie Dopuszcza się modyfikacje metody w przypadku, gdy pojawiają się nowe możliwości lub konieczne jest zażegnanie kryzysu. Kontrowersje narastają, gdy czytamy rozdział o pracowni oprogramowania – zespołu mającego wprowadzać w organizacji Scruma i metodach jego działania. Oraz kontynuujący ten wątek dodatek C – napisany od 2005 (i wyraźnie nieaktualizowany) zestaw strategii jak zmieniać przedsiębiorstwo używając Scruma.

Warto z kolei zanotować fragment o tym, że zdaniem autorów większość organizacji, które wprowadzają metodę Scrum, potrzebuje kilku lat, by w pełni cieszyć się jej owocami. (…) W okresie transformacji do metody Scrum cała organizacja przechodzi gwałtowne zmiany, pracując w kontrolowanym chaosie przez kilka lat.

Mocno podkreślana jest też rola menedżera – inicjatora i lidera zmian w organizacji i jego determinacji, wpływowi na końcowy sukces. Oraz – oczywiście zmianę kultury organizacyjnej.

Nie próbowałbym przekonywać kogokolwiek do Scruma przy użyciu tej książki. Można wynotować parę ciekawych cytatów i tyle. Tematy tu poruszane znajdziemy podane w znacznie lepszy i ciekawszy sposób w innych pozycjach.

Traktuje ją wyłącznie jako ciekawostkę historyczną.

#Scrum