Do przeczytania książki „No Estimates” dojrzewałem od dłuższego czasu. Złożyło się na to kilka okoliczności:
1. Prowokacyjny hashtag #noestimates, przez wiele osób traktowany zbyt dosłownie, wyświetlał się na moim twitterze od dłuższego czasu i rozbudzał moją ciekawość tematu.
2. Słucham od czasu do czasu podcast Scrum Master Toolbox Podcast, którego jednym z autorów jest Vasco Duarte, więc miałem okazję zapoznać się z jego poglądami przy okazji rozmów z gośćmi, których zapraszał do audycji (nie tylko zadaje pytania, ale potrafi celne podsumować wypowiedź lub dodać coś od siebie).
3. Miałem okazję posłuchać prezentacji Vasco na żywo podczas konferencji Agile Prague oraz podczas warszawskiego Agile By Example 2015 i można powiedzieć, że wtedy „mnie kupił”.
4. Dużo czasu poświeciłem w tym roku na przygotowywanie różnorakich prezentacji oraz warsztatów, stąd coraz bardziej czekałem na spokojną jesień, kiedy będę mógł zacząć czytać wybrane książki, które z różnych powodów wrzuciłem na swoją wish list na amazon.com.
Gdybym miał przekazać główną myśl książki jednym zdaniem, to było by to coś takiego: estymowanie samo w sobie nie przynosi wartości, dlatego postaramy się ograniczyć je do minimum.
Co zatem przynosi wartość? Już prędzej działający software. Pomysł jest taki: zaakceptujmy, że dwa z trzech boków klasycznego trójkąta projektu będą stałe, czyli czas oraz koszt. Jednocześnie akceptujem, że zakres jest zmienny i to nim będziemy głównie sterować w trakcie realizacji projektu.
"Fix the hardest constraints (time and people plus resources) while letting uncertainty be managed through a variable scope" #noestimates
— Jacek Wieczorek (@jacekwieczorek) November 11, 2015
Oczywiście zakresem możemy sterować tylko jeśli podzielimy go na małe, działające kawałki, z których każdy dostarcza wartość dla klienta. Z punktu odpada zatem podejście kaskadowe, dzielące projekt na fazy takie jak analiza, projektowanie, implementacja czy testowanie. Idąc dalej, podział po warstwach systemu (np. frontend, backend) również nie jest wystarczająco dobrym algorytmem dekompozycji wymagań.
Jak zatem skutecznie dzielić wymagania? Otóż dzielić na User Stories, z których każde story spełnia wymagania INVEST. Tego rodzaju granulacja pozwala na w miarę przewidywalne dostarczanie małych, wartościowych funkcjonalności, co z kolei pozwala na szybkie pozyskiwanie informacji zwrotnej od klienta, a w konsekwencji zmniejsza ryzyko niepowodzenia inicjatywy.
Przy okazji: jeżeli szukasz pogłębionej wiedzy na temat sposobów dzielenia pracy na mniejsze części, to sprawdź webinar o dekompozycji elementów Backlogu Produktu, który przygotowałem z Kubą w ramach działań pod szyldem „Porządny Agile”.
Kiedy już mamy nasz produkt podzielony na małe zadania (wg. Vasco – od 0,5 do 1 dnia), w praktyce okazuje się, że są one podobnej wielkości (podobnie małe). To, co pozostaje do zrobienia, jako główna część procesu deweloperskiego, to regularnie układanie zadań wg. wartości biznesowej. Powoduje to, że zamiast skupiać się na estymowaniu, zaczynamy skupiać się na priorytetyzowaniu, czyli de facto na dyskusji nie o koszcie dostarczenia (estymata), tylko na tym, co przyniesie największą wartość dla klienta. Proste i genialne zarazem, prawda?
Gdy z kolei jesteśmy skupieni na wartości, używamy dostępnych danych dotyczących przepustowości zespołu („n” zadań per okres czasu, np. tydzień), aby prognozować jak może układać się w czasie dalszy rozwój produktu. W efekcie klient dostaje realną prognozę przyszłości opartą na danych pochodzących z procesu i może na tej podstawie planować kolejne działania.
Oczywiście wszystko, co opisuję tutaj w dużym skrócie, jest bardzo mocno pogłębione w książce. Interesujących wątków jest więcej i są bardzo dobrze wytłumaczone.
Chociaż pozornie Vasco nie pisze o nowych pojęciach (w sensie: branża zna już pojęcia, o których wspomina w swojej książce), to muszę przyznać, że świetnie udało mu się poskładać w jedną całość istniejące i dostępne klocki, które głęboko rozumie i potrafi stworzyć z nich spójną kompozycję. Wychodzi daleko poza dostępne metody i frameworki, odkrywając nowe sposoby realizacji zadań, co jest punktem wyjścia oraz esencją Manifestu Agile. I to moim zdaniem pokazuje dojrzałość i poziom wiedzy autora.
Absolutnie rekomenduję każdemu, kto zawodowo zajmuje się tworzeniem oprogramowania.
Plusy:
+ cała masa badań oraz faktów związanych z problemem estymacji
+ dużo gotowych rozwiązań, które można użyć od zaraz we własnych projektach
+ jest uniwersalna, nie odnosi się do konkretnej metody pracy czy frameworka
Minusy:
– przez całą książkę przewija się fabularna historia Project Managerki o imieniu Carmen, która uczy się #noestimates na bazie projektu, który dostała do zrealizowania. Osobiście nie przepadam za takim sposobem przekazywania wiedzy i wyobrażam sobie, że niektórzy mogą również mieć na to alergię.
Moja ocena: 5
PS. Zachęcam też do przeczytania mojego artykułu „Rozwijanie produktów bez szacowania ich rozmiaru? #NoEstimates” na portalu agile247.pl