#noestimates równie dobry jak #yolo

Żródło https://www.pinterest.com/sabinacosmina/grumpy-cat-/

#noestimatespojawia się jako broń ostatecznej zagłady w rozmowach i sporach na temat szacowania w Agile oprócz dysputy abstrakcyjne jednostki (np. Story Points) kontra jednostki czasu, która jest zawsze na czasie. Kiedy to napisałem przypomniało mi się użycie broni Holy Granate w grze the Worms. W dyskusji na temat szacowania pojawią się zawsze dwie pozorne skrajności. Z jednej strony będą osoby nalegające na szacowanie tasków (po polsku zadań) w godzinach i skupieniu się na dokładności estymat (po polsku oszacowań) i nie wiadomo dlaczego są to zazwyczaj PMowie (kierownik projektu) albo podobne osoby z tego kręgu cywilizacyjnego. Z drugiej totalni hipisi, dzieci kwiaty, które twierdzą, że szacowanie jest passé i w ogóle nie powinno się szacować niczego. W tym drugim przypadku pada określenie #noestimates. Niektórzy idą już nawet dalej, bo pojawiło się już określenie #nobudgeting jako podeście odrzucające budżetowanie. Jednak większość osób korzystających z #noestimates jako pozwolenia na brak oszacowań nie ma pojęcia jak bardzo się myli. Czas rozprawić się z tym mitem i wyjaśnić sobie o czym na prawdę chodzi w podejściu #noestimates i z czym to się wiąże. Dla niektórych każda wymówka jest dobra, żeby nie szacować. Czyli najlepiej byłoby pracować sobie, dłubać coś w zaciszu na zamrożonych wymaganiach i jak coś będzie zrobione, to będzie, więcej nie wiem. #noestimates tego nie obiecuje. Podobnie używane jest określenie #yolo, czyli You Only Live Once rozumiane jako w życiu należy wszystkiego spróbować. Często jednak dotyczy to narkotyków i amatorskiego porno, a rzadko fizyki kwantowej i chemii molekularnej.

“Remember that #NoEstimates is not about no estimation ever, but about the minimum amount of estimates that will do, and then look carefully at ways to reduce that need even more.” — Ángel Medinilla

Jeśli chodzi o nazwę samą w sobie to, #noestimates ma takie same szanse jak XP czyli Extreme Programming. Pamiętam jak dziś kiedy managerowie w dużej korporacji powiedzieli mi, że nie chcą XP, bo nie będą robić nic ekstremalnego. Normalne metody im wystarczą. Sprawcą całego zamieszania jest Vasco Duarte, konsultant i Agile Coach z doświadczeniem w zarządzaniu projektami. W tej chwili ciężko jest znaleźć dokładne źródło. Jak łatwo domyślić się patrząc na nazwę pomysł zrodził się na Twitterze w ramach dyskusji na temat oszacowań. Natępnie w 2011 i 2012 były wystąpienia na konferencjach oraz pojawił się na blogu Vasco post Story Points Considered Harmful — Or why the future of estimation is really in our past…. Niedługo później pojawiła się książka Vasco Duarte “No Estimates. How to measure project progress without estimating”. Na jej podstawie mam wiedzę na temat podejścia #noestimates i będę ją traktował dalej w tym tekście jako źródło. Jako wehikuł do sprzedania nowego podejścia została użyta historyjka super PMki Carmen, która jako specjalista od dowożenia projektów dostała projekt, który jest bardzo duży, dla bardzo ważnego klienta i bardzo ważny dla jej firmy. Można by się tutaj zatrzymać i zastanowić, czy to jest tak naprawdę projekt niezwykły i czy jako super PM, Carmen nie miała już takich projektów, ale nie ma co się czepiać. Książka zawiera elementy humorystyczne na przykład spotkanie, gdzie klient jest informowany, że projekt dojedzie gdzieś pomiędzy 12 miesięcy do 4 lat od teraz. Najważniejsze, że wszystko będzie dobrze. Zgadnijcie drogie dzieci, kto zostanie bohaterem? Uwaga, spoiler alert! Bingo! #noestimates Samą historią Carmen nie będziemy się tutaj zajmować. Zainteresowanych odsyłam do źródła.

#noestimates — o co chodzi?

Zacznijmy może od tego czym jest #noestimates i skąd w ogóle ten pomysł.

Estimates w tym kontekście jest rozumiane jako szacowanie ceny i czasu trwania projektów. A, że projekty nie są dowożone na czas i w budżecie, to trzeba albo zwiększyć dokładność szacowania, albo przestać szacować. To pierwsze jest trudne, a dokładniej mówiąc praktycznie niemożliwe. No bo jak stać się lepszym w zgadywaniu przyszłości na podstawie zmiennych wymagań? Zatem pozostaje pomysł numer dwa. Trzeba go dobrze uzasadnić. I tutaj z pomocą przychodzi filozofia Lean, którą można uprościć do usuwania wszystkiego co jest zbędne z procesu produkcji. Skąd wiadomo co jest zbędne, albo stosując terminologię Lean, co jest stratą (ang. waste)? To proste, jeśli coś nie dodaje wartości z punktu widzenia klienta, ani nie przyczynia się do skrócenia czasu dostawy, to jest to strata. Prostym sposobem sprawdzenia czy aktywność albo artefakt są pożądane jest również spytanie “Czy chcemy tego więcej, na przykład 3 razy więcej?”. Oczywiście z punktu widzenia klienta szacowanie pracy nie jest wartością dodaną, zatem należałoby się tego pozbyć. Project Management też nie jest wartością dodaną i nikt nie powie,  że chciałby tego trzy razy więcej, ale o tym Vasco Duarte nie wspomina.

Pozbądźmy się zatem tych złych estymat. Co dalej? Klienci wewnętrzni czy zewnętrzni zgodzą się, że szacowanie w jednostkach czasu i stosowanie mniej lub bardziej jawnych buforów nie działa. Można też udowadniać, że zgodnie z prawami Parkinsona i Hofstadtera nie ma sensu tworzyć długofalowych planów opartych na oszacowaniu czasu trwania zadań. Nie zmieni to jednak tego, że nadal będą pytali co będzie na daną datę lub na kiedy coś otrzymają. Jak z tego wybrnąć? Posłużymy się prognozowaniem, czyli będziemy tworzyć forecast. Nawet prognozy pogody są oparte na jakiś danych. My też będziemy potrzebowali danych, na których możemy oprzeć nasze przewidywania. Będziemy patrzeć na to ile pracy zostało dostarczone do tej pory. Chwileczkę, ale to brzmi zupełnie jak korzystanie z Velocity w Scrum. Tak, ale potrzebowalibyśmy do tego oszacowanego Product Backlog, a mówiliśmy, że pozbywamy się szacowania, bo jest fuj. No to będziemy patrzeć na liczbę dostarczonych elementów. No tak, ale co jeśli elementy będą różnej wielkości? Wtedy dostarczenie dwóch większych może oznaczać tyle samo, co trzech mniejszych. No to trzeba zrobić tak, żeby elementy były mniej więcej równe, czyli w pewien sposób znormalizować. To znaczy, że jakiego rozmiaru mają być? I tutaj Vasco przychodzi nam z pomocą.

“With the #NoEstimates approach I advocate that Stories should be between 0,5 and 1 man-days of effort.”

“The long term rate of delivered RTS’s should converge to 1 RTS per team member per day.”

“If your project is several months long, then assessing progress every week may be enough and your Stories may be time boxed to a few days (say 2–3 days).”

Badum, Tss, .… Czar prysł. Wydaje się, że tak jak z doktora Bannera wychodził czasem Hulk, tak z Vasco wychodzi PM.

Aha, i pamiętaj o tym, że to nie jest oszacowanie, tylko przewidywanie albo prognoza.

Jeszcze raz i powoli. Dzielimy wszystkie User Story na równej wielkości szacowanej w MD, czyli roboczo-dniach i wtedy wystarczy mierzyć ilość User Story dostarczanych w stałej jednostce czasu. Nazywamy to #noestimates.
Wracając do rozmów z klientami. Ani mru mru na temat #noestimates

“It is our responsibility as professional and competent Project Managers to deliver the projects on time and under budget. #NoEstimates is our secret weapon to achieve that goal.”

Jak zacząć z #noestimates?

Jeśli nie czujesz “wewnętrznego fuj” i nadal postanowiłeś wejść w metodę #noestimates, to Vasco Duarte podaje przepis krok po kroku. W końcu w Scrum lubimy sprawdzać tezy, metody i narzędzia empirycznie, więc czemu nie. Proszę, zastanów się tylko co próbujesz osiągnąć i jak to zmierzysz.

1. Przejdź na Story Points. Chwileczkę? Czy nie Vasco nie pisał w swoim poście, że szacowanie w Story Points to zło? Chodzi tutaj o oderwanie się od szacowania w jednostkach czasu. Przechodząc na Story Points powinieneś też zacząć myśleć o ryzyku i niepewności jako czynnikach wpływających na ostateczne oszacowanie.
2. Przestań szacować zadania Vasco zakłada, że są zespoły, które rozbijają każde User Story na zadania, szacują zadania i sprawdzają czy suma oszacowań zadań jest równa oszacowaniu User Story. Powiem szczerze, ze od 2010 nie spotkałem takiego zespołu ani o takim nie słyszałem. Jak już to zdarza się szacowanie zadań w godzinach. I tutaj zgadzam się, że o ile rozbicie User Story na zadania pozwala lepiej zaplanować pracę, to z szacowania zadań zwykle jest mało pożytku.
3. Ogranicz czas trwania Funkcjonalności i Story No i tutaj powracamy z jednostkami czasu i kroimy User Story tak, żeby ich wykonanie zajmowało 1–2 dni. O ile mogę się godzić z tym, że szybkie zamykanie User Story w Sprincie jest dużo lepsze niż czekanie do końca, to oczywiście szacowanie w dniach zaprzecza całemu pomysłowi z punktu 1. Co to Funkcjonalność (ang. Feature)? Vasco grupuje Story w Funkcjonalności. Zwykle nazywamy to Epikiem lub Tematem.
4. Jeśli już korzystasz ze Story Points, usuń niektóre karty z Planning Poker Logika podpowiada, że skoro tutaj dotarliśmy, to punkt 1 wykonany. Zostaw tylko 1, 3, 8. W ten sposób ograniczysz rozmiary User Story. Hej, ale czy w poprzednim punkcie nie zrobiliśmy czegoś podobnego w poprzednim punkcie?
5. Zbuduj histogramy Żeby określić średni czas trwania Story i Funkcjonalności, zapisuj czas rozpoczęcia i ukończenia.
6. Korzystaj ze średniego czasu trwania cyklu dla User Story Biorąc pod uwagę histogram i średnią ilość User Story ukończonych per Sprint możesz tworzyć prognozy.
7. Ostatecznie pracuj z User Story tak jakby miały taki sam czas trwania Czyli zawsze po prostu prognozujemy ile User story powinno zostać dostarczone biorąc pod uwagę ilość User Story dostarczanych w poprzednich Sprintach.

Podsumowanie #noestimates

W podsumowaniu postaram się odnieść za równo do metody jak i do książki, którą przeczytałem. #noestimates to tak naprawdę #nocommitment, czyli ogólnie dobry pomysł na to, żeby promować prognozowanie zamiast zobowiązań i dostarczania wszystkiego na określony czas. Skupianie się na dostarczaniu wartości i wcześniejszych wydaniach to też dobry pomysł. Wprowadzenie do podstaw lean management, dzielenia User Story, modelu INVEST głownie rozpychają książkę, ale dla niektórych mogą być nowością.

w #noestimates w oczy rzuca się ogromna niespójność i wykorzystywanie pojęć związanych z Agile w sposób mocno dowolny. W oczy kłuje też to, że w sumie User story są szacowane w zwykłych “chamskim mendejach”. W jaki sposób mamy pokroić na małe kawałki elementy Product Backlogu znajdujące się nisko? Przecież mogą się zmienić (Agile) i są mocno niedookreślone. Zaskakujące i przerażające jest dla mnie w jaki sposób korzystając tych samych argumentów co Mike Cohn w swoich prezentacjach można dojść do przekonania, że Story Points bazują na przyszłości i nie da się w nich szacować. To co mnie uderzyło w książce, to brak transparentności i korzystania z wiedzy zespołów. Kluczowe fragmenty dzieją się w siedzibie lub na spotkaniach dostawcy, klient jest tylko informowany. Decyzje łącznie z tymi o cięciu zakresu podejmuje PM i nawet sam ten zakres wycina. Przesłanie książki oprócz kreowania wizerunku wszechmocnych super PM, którzy ratują projekty jest mniej więcej takie: oszacuj byle co, podejmij się projektu typu fix, powiedz klientowi, że to nie wyjdzie, keep calm and #noestimates. A jak wpłyną zmiany na Product Backlog na całe przewidywania? Przecież można nie robić niektórych elementów, nowe dochodzą, inne się zmieniają. Przecież wtedy prognoza na kiedy będzie X powinna się zmienić.

Czy nie lepiej Scrum?

Dzisiaj podczas pisania tego posta zadałem sobie ciekawe pytanie. Jak można inaczej zrealizować to co Vasco obiecuje przy #noestimates?

1. Product Ownerowi posortuje Product Backlog po wartości biznesowej.
2. Zespół oszacuje wielkość elementów Product Backlog, a nie czas trwania.
3. Mierz Velocity
4. Planuj wydania, nie tylko iteracje/Sprinty.
5. Prognozuj na podstawie Velocity. Możesz używać nie tylko średniej, ale też minimalną i maksymalną.
6. Nie traktuj oszacowań i planów jako twardych zobowiązań, ale jako prognozy.
7. Przeglądaj efekty i Product Backlog z interesariuszami i porządkuj go

Podsumowując powyższe punkty

Jak już zbudujesz zaufanie, to przejdź z klientem na model współpracy time & material lub jego wariat zamiast fixed time & scope.