#NoEstimates – ten hashtag potrafi wywołać u ludzi zajmujących się wytwarzaniem produktów skrajne uczucia – zwykle negatywne. Czy słusznie? O co chodzi z tym #NoEstimates? W tym artykule spróbujemy rozwikłać największe zagadki kryjące się pod ideą pracy bez estymat.
Velocity w liczbie historyjek na Sprint ponad liczbę Story Pointów na Sprint
Estymaty, z punktu widzenia popleczników #NoEstimates są stratą. Ciężko się z tym nie zgodzić (technicznie rzecz biorąc) – estymowanie samo w sobie nie przynosi żadnej wartości biznesowej odbiorcy końcowemu, a dodatkowo zwykle jest błędne, więc niepotrzebnie wprowadza chaos i nieporozumienia na linii development-biznes przy wytwarzaniu produktu. Czysty “waste” z punktu widzenia Lean.
Rozwiązaniem dla tego problemu, zamiast estymacji w Story Pointach zakresu przewidzianego na Sprint, miałoby być estymowanie liczby historyjek możliwych do realizacji w trakcie Sprintu.
Na dowód skuteczności takiej metody, zwykle pokazywane są burndown charty konkretnych projektów, wskazujące różnice między trzema typami sposobów wyceniania w Story Pointach, w różnych skalach:
- Używane wartości Story Pointów to: 1-3-5, czyli zwykły zmodyfikowany ciąg Fibonacciego zaczerpnięty z Planning Pokera, wykluczając duże wartości (od 8 włącznie wzwyż)
- Używane wartości Story Pointów to: 1-2-3 – wzrost liniowy, czyli inaczej niż w poprzednim punkcie, gdzie ciąg rośnie wykładniczo,
- Używane wartości Story Pointów to tylko 1 – każda historyjka ma taką samą wartość, co w praktyce sprowadza się do tego, że po prostu liczymy te historyjki – czyli podejście #NoEstimates w praktyce
Vasco Duarte, jeden z ojców i twarzy ruchu, prezentuje w swojej książce #NoEstimates: How to Measure Project Progress Without Estimating, a także na wielu konferencjach branżowych, przykłady, w których można zobaczyć, że projekcje daty ukończenia konkretnych, realnych projektów za pomocą wszystkich trzech metod, zawierają się w przedziale trzech tygodni przy około siedmiomiesięcznym projekcie (ok. 8% maksymalnej różnicy). Przy ogromnej niepewności na przestrzeni siedmiu miesięcy wydaje mi się, że trzy tygodnie to naprawdę niewiele.
Zrobiłem więc to, co każdy rozsądny człowiek zrobiłby na moim miejscu i sprawdziłem to na projekcie, w którym ówcześnie pracowałem. Zespół był zgrany, pracował nad produktem już od długiego czasu, a historyjki w tym zespole były zwykle podobnej wielkości (3-5-8, czasem mniejsze lub większe). W tamtym momencie prowadziłem już kwartalny burndown chart dla wypalonych SP zespołu, w którym pracowałem (pracowaliśmy w ramach struktur, które wymagały od nas estymat na kwartał do przodu). Wyglądał on dokładnie tak:
- Remaining SP – dokładna liczba Story Pointów pozostała do “zamknięcia” zaplanowanego Scope
- Linear (Ideal) – trend pokazujący idealny wykres spalania
- Linear (Remaining SP) – trend pokazujący przewidywane spalanie Story Pointów
Tak więc, zgodnie z przewidywaniami, Scope powinien być zamknięty 26 listopada. To czysta matematyka.
Na potrzeby tego artykułu postanowiłem zbudować analogiczny wykres, ale używając jedynie liczby historyjek dla tego samego produktu (czyli licząc każdą historyjkę jako 1 SP).
Od razu zaznaczę, że nie spodziewałem się takiego wyniku wyciągając dane z systemu zarządzania zadaniami.
- Remaining – dokładna liczba historyjek pozostała do “zamknięcia” zaplanowanego Scope
- Linear (Ideal) – trend pokazujący idealny wykres spalania
- Linear (Remaining) – trend pokazujący przewidywane spalanie historyjek
Przewidywany koniec developmentu historyjek w tym ujęciu następuje… 26 listopada. Dokładnie tego samego dnia, który był przewidywany na wykresie, który używał Story Pointów.
Oczywiście jest to wynik z jednego projektu więc nie jest decydujący, jednak można powiedzieć, że jest obiecujący.
Slicing historyjek użytkownika ponad Planning Pokera
Zakładając, że podejście to ma prawo zadziałać w określonych warunkach, pierwszym minusem, jaki widzę patrząc na #NoEstimates, to tracenie ogromnej wartości z powodu braku dialogu, który wywiązuje się między uczestnikami Planning Pokera. Pytania w stylu “dlaczego tak wysoka estymata?” lub “dlaczego wydaje Ci się, że to takie proste?” wywołują dyskusję, w wyniku której cały zespół zyskuje tę samą wiedzę na temat historyjki – jakie mogą być przeszkody, lub jakie skróty możemy zastosować.
W #NoEstimates odbywa się to inaczej – ponieważ nie ma Planning Pokera, nie ma też tej dyskusji nad wielkością zadania. Teoretycznie – okazuje się, że #NoEstimates sugeruje substytut Planning Pokera. Jest to tak zwany Story Slicing, czyli dzielenie historyjek na równe “kawałeczki”.
Teoria jest taka – jeśli wszystkie historyjki są równe, to nie ma potrzeby ich estymować, bo wszystkie mają ten sam rozmiar, ergo – wystarczy je liczyć (a jeśli ktoś się mocno uprze na estymaty – możemy im wszystkim nadać jeden rozmiar – np. 1 Story Point). Pozwoli to na przejście z estymowania w Story Pointach na prognozowanie w liczbie historyjek.
Jednak samo podzielenie historyjek na równe bloki pracy, pamiętając o tym, by spełniały kryteria INVEST (definicja w wikipedia.org) nie jest już takie proste i wymaga… Dyskusji. Zespół wspólnie, na przykład na sesjach Refinementów, zastanawia się jak podzielić historyjki w ten sposób (jednym z proponowanych kryteriów jest dzielenie historyjek tak, by każda miała przypisany jeden test funkcjonalny) i bang! – mamy dyskusję i wymianę wiedzy.
Projekcje ponad Estymacje
Estymatę można zdefiniować jako “najlepsze przypuszczenie na temat czasochłonności lub/i pracochłonności na podstawie tego, co wiemy w czasie tworzenia estymaty“ lub “zgadywanie na podstawie najlepszej wiedzy” – warto szczególną uwagę zwrócić na słowa “przypuszczenie” i “zgadywanie”.
Przypomnijmy: wyestymowanie Scope na najbliższe np. 3 miesiące wymaga wycenienia, czyli dokonanie “zgadywania na podstawie najlepszej wiedzy” całego zakresu pracy. Wynikiem takiej estymaty jest zwykle lista historyjek, które powinny być wykonane do zadanej daty. Zwolennik #NoEstimates zapytałby zapewne czy czujemy się komfortowo opierając nasz biznes na zgadywankach i przypuszczeniach.
#NoEstimates zamiast tego proponuje przeprowadzić pierwszą iterację, sprawdzić, ile pracy wykonaliśmy, ile nowej pracy wyszło w trakcie developmentu i zestawić to z liczbą historyjek w Scope. Weźmy dla przykładu wykres z wcześniejszej części artykułu:
Na wykresie widać okresy spadku liczby funkcjonalności (a), a czasami wzrosty i stagnację liczby funkcjonalności (b) (w tym szczególnym wypadku stagnacja występowała w weekendy – to w sumie chyba dobrze?).
Na tej podstawie możemy sporządzić projekcję daty zakończenia prac – mamy już większą wiedzę jakim (mniej więcej) ryzykiem obarczone jest całe przedsięwzięcie i jak wygląda faktyczna prędkość wypalania zakresu. A to wszystko bez estymat.
Można się oczywiście spierać na temat tego, jak faktycznie działają Story Pointy w takich wypadkach – one też mogą być miarą projekcji – przecież śledzimy nasze Velocity (w SP/Sprint) i na podstawie tego szacujemy, ile wykonamy na zadaną datę lub kiedy zakończymy budowanie produktu.
Jednak czy mogąc osiągnąć ten sam efekt (może nawet lepszy) bez estymowania pojedynczych historyjek, nie powinniśmy wybrać metody mniej pracochłonnej? Ciężko jest przecież od razu estymować każdą pojedynczą historyjkę, która wchodzi do Backlogu Produktu.
Warunki minimalne
Wydaje mi się jednak, że zdecydowanie która metoda (#NoEstimates czy Story Points) jest “mniej pracochłonna” zależy od wielu czynników i nie można stanowczo stwierdzić, że jedna jest lepsza niż inna.
Gdzie zatem moim zdaniem #NoEstimates może napotkać przeszkody? Gdzie może się sprawdzić?
- #NoEstimates raczej nie zadziała w nowym, tworzącym się zespole. Wymaga od niego pewnej dojrzałości i odpowiedzialności.
- Product Owner, podobnie jak zespół, powinien mieć już pewne doświadczenie. Samo dzielenie historyjek na równe części wymaga od niego zaawansowanej znajomości biznesu i do pewnego stopnia również technologii.
- Story Slicing jest również czasochłonną aktywnością. Na początku na pewno będzie sprawiać zespołowi kłopoty. Należy uważnie obserwować, czy Slicing nie zajmuje więcej czasu niż wycena w Story Pointach.
#NoEstimates wydaje się naturalnym wyborem dla zespołów, których historyjki użytkownika są już podobnej wielkości (np. przeważają historyjki mające 3-8 Story Pointów). Wtedy taka zmiana wymaga minimalnego wysiłku ze strony zespołu i faktycznie może oszczędzić zespołowi dużo czasu.
Z tego powodu też powstał koncept 7 kroków do #NoEstimates, który zaproponował Vasco Duarte:
- Zacznij używać Story Pointów,
- Przestań estymować podzadania [chodzi o taski deweloperskie, na które rozbija się historyjkę – przyp. red],
- Ogranicz trwanie dla historyjek i feature,
- Ogranicz skalę dopuszczalnych estymat (na przykład tylko 1, 2, 3 i 5),
- Śledź swoje dane,
- Użyj swoich danych,
- Po prostu zacznij liczyć historyjki.
Co myślę o #NoEstimates?
Metoda naukowa polega w uproszczeniu na tym, że hipotezę trzeba zweryfikować i sprawdzić, zanim stanie się teorią, dlatego z chęcią rzucę się w wir dyskusji na ten temat i dorzucę swoje trzy grosze.
Rewolucyjne pomysły zawsze spotykały się z ogromnym oporem – można wziąć przypadek naszego rodaka, Mikołaja Kopernika, który w swoim dziele O Obrotach Ciał Niebieskich dowodził, metodą naukową, na podstawie obserwacji o eliptycznym ruchu planet, że Słońce jest w centrum naszego Układu Słonecznego – pewne społeczności jednak uznały to za… nazwijmy to delikatnie, rzecz wysoce niewłaściwą.
Podobnie było (jest?) ze zwinnością – często mówi się, że tego nie da się zrobić, bez sensu, a w ogóle to jakaś nowomowa i skok na kasę.
Ja widzę tutaj pewną analogię. Możliwe, że #NoEstimates to rewolucja w prowadzeniu projektów, na którą czekaliśmy. Możliwe, że zadziała do większości, połowy lub nielicznych projektów, możliwe też, że nie działa nigdzie (choć istnieją dowody, o których wspominam wcześniej, na to, że w pewnych warunkach działa).
Czy jestem przekonany, o racji którejś ze stron? Raczej nie. Uważam, że w prowadzeniu projektów nie ma rozwiązań, które zadziałają wszędzie. Mam jednak przeczucie, że #NoEstimates może być ciekawą, lżejszą alternatywą dla prowadzenia estymacji w niektórych projektach i taką hipotezę będę chciał, przy sprzyjających warunkach i ogólnej zgodzie sprawdzić.
Może Wy macie negatywne bądź pozytywne doświadczenia w tej materii? Może chcielibyście się podzielić swoimi przemyśleniami? Gorąco zachęcam do dyskusji!
***
Jeśli estymaty są Ci bliskie, zajrzyj do innego artykułu autora na ten temat.
Zostaw komentarz