Estymaty w Scrum

W historii świata mieliśmy do czynienia z kilkoma „odwiecznymi” walkami. Walka dobra ze złem. Walka prawicy i lewicy. Walka o estymaty godzinowe i abstrakcyjne. Można by pomyśleć, że życie to walka. Najgorsze (albo najlepsze) w tym wszystkim jest to, że w niektórych sporach obie strony mają rację – „nothing is true, everything is permitted”.

Historia z życia wzięta

Gdy jeszcze chodziłem do szkoły podstawowej, pod blokiem miałem boisko, które otoczone było przez kilka drzew – taka zielona wyspa pośród betonowych budynków. Kiedy komputery nie były jeszcze tak popularne jak dzisiaj, to właśnie na boisku (lub w jego okolicy) spędzało się większość czasu w wakacje – czy to grając w piłkę, wspinając się po drzewach, czy po prostu huśtając się i rozmawiając z kolegami na trzepaku.

Uczucie swobody było cudowne. Było tylko jedno ale: „Pamiętaj, żeby wrócić o 19:00, bo będzie kolacja!”.

Oczywiście, zwykle nie psuło mi to zabawy – jak graliśmy mecz między rywalizującymi ze sobą blokami, to nie mogłem po prostu zejść z boiska punktualnie o 19:00 i zostawić kolegów na murawie (czy też ziemi, bo murawa dawno zniknęła, wydeptana naszymi stopami). Już nawet nie chodziło o to, że mało kto miał zegarek ?

Finał był taki, że mecz był rozegrany z lepszym lub gorszym wynikiem, jednak człowiek miał poczucie dobrze spełnionego obowiązku. W domu jednak przyjście ubrudzonemu 15 minut po „dedlajnie” skutkowało szybką, ale wyraźną reprymendą, umyciem się (a przynajmniej rąk) do stołu i zjedzonym w samotności, zimnym posiłkiem (przecież reszta już zjadła). Ani moja mama, ani ja nie byliśmy zadowoleni z takiego stanu rzeczy.

Wiele tęgich głów spędziło noce w oparach kawy, zastanawiając się, jak poprawić estymaty. Nie obiecuję, że na łamach tego artykułu problem zażegnamy, ale mam nadzieję, że pozwoli on Wam spojrzeć na zagadnienie ze świeżej perspektywy.

Estymata estymacie nierówna

Estymowanie pracy w godzinach sprowadza lub sprowadzało się zwykle do tego, że zespół dostaje zadanie/wymaganie/historyjkę w zestawie z pytaniem „na kiedy?”. Następnie deweloperzy zastanawiają się, ile czasu zajmie im dana funkcjonalność (lub jej część). Rozkładają ją na części pierwsze i biorąc pod uwagę złożoność systemu, swoją wiedzę lub jej brak, testy, nieprzewidziane sytuacje, przerwy na kawę, prądy morskie, sytuację polityczno-gospodarczą na Bliskim Wschodzie, migracje łososia oraz prawdopodobieństwo opadów deszczu w Birmie, a na koniec, dodając 30% bufor, podają „na oko”, że zajmie to im X godzin.

Znacie prawo Hofstadtera?

Wszystko zawsze zajmuje dłużej niż planujesz, nawet jeśli weźmiesz pod uwagę prawo Hofstadtera.

Rezultaty zwykle są do przewidzenia – z resztą, nie jest to nic niezwykłego i coraz częściej traktowane jest to jako coś naturalnego.

Czas, czas, czas, czas, czas, czas… Czas wciąż goni nas

Czemu więc mogą służyć estymaty czasowe? A czemu nie powinny służyć? Jak ich używać? Jak to bywa – teoria jest prosta, a praktyka trudna.

Pamiętajmy zawsze po co tak naprawdę estymujemy w Scrum. Przede wszystkim robimy to, żeby wiedzieć, ile możemy „włożyć” do Sprintu – na podstawie dostępności członków zespołu i czasu, jaki potrzebują na wykonanie zadania.

Tak więc, praktyka z jaką się spotkałem jest taka, że historyjki użytkownika dzieli się na sub-taski deweloperskie, będące „checklistą” tworzoną przez deweloperów dla deweloperów. Deweloperzy po podzieleniu takiej historyjki nadają każdemu podzadaniu jakąś wycenę w godzinach. Suma czasu, jaki zostanie poświęcony na sub-taski, jest przypisana do całej User Story. Stąd wiemy, że skoro zespół ma do poświęcenia X godzin czasu w Sprincie, to do Sprintu zmieścimy User Stories, które mogą łącznie trwać… około 75%*X godzin, bo tyle w praktyce jesteśmy w stanie pracować efektywnie każdego dnia.

Zaletą godzin jest to, że godziny są znane. Można na ich podstawie wycenić (mniej więcej), ile zmieścimy do Sprintu. W mojej ocenie jest to metoda idealna dla początkujących zespołów lub takich, w których nastąpiły znaczące zmiany kadrowe.

Jak szacować prędkość w nowym lub zmienionym zespole?

Na początku pracy, czy to w nowym zespole, czy takim, który mocno się zmienił, ciężko się opierać na Story Points, czy jakiejkolwiek innej relatywnej jednostce miary. Spowodowane jest to tym, że nie mamy danych historycznych, na podstawie których moglibyśmy oszacować naszą prędkość.

(Dla osób, które dopiero zaczynają swoją długą i [prawdopodobnie] wyboistą drogę z estymatami – sens ostatniego zdania powinniście zrozumieć po zapoznaniu się z następnym rozdziałem.)

Wady podejścia

Takie podejście do estymat nie jest jednak wolne od wad, ponieważ:

• Zwykle nad ich wyceną pracuje jedna osoba, co powoduje, że mamy skłonność do niedyskutowania o ilości pracy potrzebnej do wykonania zadania. Powoduje to brak wymiany wiedzy, a czasami także sztuczne nadmuchiwanie wycen, gdyż nikt nie stara się ich kontrolować. A jak kontroluje, to z perspektywy deweloperów, jest to dowód na brak zaufania i podważanie ich specjalistycznej wiedzy, co negatywnie wpływa na morale zespołu i powoduje nieporozumienia.
• Każdego programistę „liczy się” jednakowo – czy jest seniorem, czy stażystą, zawsze jest to ~160h, a nie odzwierciedla to prędkości poszczególnych osób i ich możliwości.
• Szacowanie w godzinach, aby miało w miarę sensowną dokładność (dobre estymaty to takie, które są w granicach 25% właściwego rezultatu przez 75% czasu[1]) wymaga szczegółowego rozbicia historyjek/wymagań na mniejsze podzadania. Samo w sobie zabiera to dużo czasu, a nie przynosi wartości odbiorcy końcowemu (nie mówię tu o biznesie, który zwykle lubi Wykresy Gantta i Roadmapy, tylko o kliencie – użytkowniku produktu).
• Biznes traktuje estymaty czasowe podawane przez deweloperów jako zobowiązanie lub wycenę. Nieważne, jak długo i jak uparcie będziecie powtarzać, że jest to zgrubna estymata i czas realizacji może być dłuższy lub krótszy w zależności od wielu czynników. Biznes planuje wtedy swój kalendarz na podstawie tych estymat, a gdy estymaty się zmieniają lub okazują się nieprawidłowe… Cóż, nie prowadzi to do niczego dobrego.

No i nie ukrywajmy – estymowanie w czasie zostało przeniesione z poprzednich, kaskadowych modeli, dlatego lepiej się sprawdza w nich, niż w modelach zwinnych. Gdy przekraczamy czas w modelu kaskadowym – trudno. Wiadomo, że nie ma się z czego cieszyć, ale są jeszcze tzw. zakresy tolerancji, których zadaniem jest mitygacja takiego ryzyka. W Scrum nie ma tolerancji czasowej – Sprinty są stałej długości, więc nie możemy przedłużyć iteracji o 2 dni, bo „jeszcze coś trzeba dotestować”. Powoduje to często, że niedostarczenie funkcjonalności na koniec Sprintu odbierane jest przez niektórych jako wina braku planu i zarządzania.

Story Points – za 3 punkty!

Chyba najpopularniejszą metodą wyceny tzw. „historyjek” w zwinnym podejściu są Story Points. Opierają się na porównywaniu na podstawie złożoności i pracochłonności (w odróżnieniu od wyceny godzinowej, gdzie wycenia się tylko czas trwania pracy) „historyjek” do tzw. „historyjki referencyjnej” (mającej przeważnie wartość 5 lub 8 Story Pointów).

Zespół wspólnie zwykle na sesjach Planning Pokera wycenia wymagania porównując „wielkość” historyjki do historyjki referencyjnej w skali zmodyfikowanego ciągu Fibonacciego, zwykle przybierającego wartości 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? i ☕ (znak zapytania oznacza niezrozumienie historyjki, kubek – prośbę o przerwę).

Sama gra polega na tym, że po krótkim omówieniu przedmiotu wyceny, każdy z członków zespołu samodzielnie wybiera kartę z talii. Po dokonaniu wyboru przez wszystkich członków zespołu, jednocześnie odkrywa się karty. Wtedy, jeśli nie ma jednomyślności co do wyceny osoby, które podały najniższe i najwyższe wartości „bronią” swojej wyceny przed resztą zespołu deweloperskiego. Następnie nadchodzi druga tura głosowania… i tak aż do osiągnięcia konsensusu.

Zaletą Planning Pokera jest to, że jeśli któraś z osób w zespole widzi proste rozwiązanie problemu, którego nie widzi nikt inny – najprawdopodobniej da niższą wycenę, więc będzie musiała się wypowiedzieć na dany temat (czasami taka metoda „przymusu” jest jedyną opcją, by przekonać nieśmiałą osobę do podzielenia się pomysłem na implementację z resztą zespołu) lub w drugą stronę – ktoś może zauważyć ogromną przeszkodę na drodze implementacji. Sam niejednokrotnie byłem świadkiem sytuacji rodem z filmu „Dwunastu Gniewnych Ludzi”.

Podstawowym zadaniem Story Points jest ułatwienie zespołowi oszacowania zakresu Sprintu.

Znając nasze Velocity (prędkość wyrażoną liczbą SP realizowanych per Sprint), jesteśmy w stanie z grubsza oszacować, ile Sprintów zajmie wytworzenie wystarczającej ilości funkcjonalności na release lub ile mniej więcej funkcjonalności dostarczymy na datę release.

Zalety i wady Story Pointów

Do zalet Story Pointów należą:

• Jest to stosunkowo szybka metoda wyceniania historyjek (w porównaniu do np. wyceniania funkcjonalności w godzinach).
• Używanie Planning Pokera wspiera dyskusje na temat funkcjonalności, co pomaga w znajdowaniu optymalnych rozwiązań i wykrywaniu potencjalnych wyzwań.
• Jest to narzędzie do wymiany wiedzy, gdzie dyskusja wpływa na rozumienie całego systemu przez każdego członka zespołu.
• Uniezależniają estymatę od liczby i doświadczenia członków zespołu. Dla przykładu: funkcjonalność X jest bardziej skomplikowana od funkcjonalności Y cztery razy, bez znaczenia czy pracuje nad nią osoba z dużym czy z małym doświadczeniem – w przeciwieństwie do czasochłonności, gdzie jednej osobie historyjka zajmie 4 godziny, a innej 16 godzin.
• Zwraca uwagę w wypadku wysokiej wyceny – może ona wskazywać na niezrozumienie tematu, wymuszając dyskusję i dalszą (niezbędną) klaryfikację wymagań lub rozbicie historyjek na mniejsze elementy.
• Story Points dużo lepiej skalują się przy zmianach osobowych w zespole – zamiast doliczać 168h za każdego dewelopera, SP nadal wyciągane są z danych historycznych, więc z pewnością możemy stwierdzić, w jaki sposób dołączenie osoby do zespołu wpłynęło na Velocity.

Jak wszystko, także i Story Pointy mają swoje wady. Ich problemem jest nadal, niestety:

• Ich niezrozumienie. Często przelicza się je na jednostki czasu lub wprost nadaje im się wartość tzw. „mendejów”. Jest to chyba najczęstszy błąd. Story Pointy to NIE SĄ jednostki czasu – mają odzwierciedlać stopień skomplikowania i wysiłku, a nie czasochłonności. Dla niektórych brzmi to absurdalnie, ale naprawdę to tak działa – całkiem zresztą nieźle – w wielu zespołach na całym świecie. Prawdopodobnie zadziała też w Twoim zespole.
• Story Points ulegają efektowi tzw. „erozji” – z biegiem czasu tracą one na wartości, tzn. naturalnym biegiem rzeczy, deweloperzy (świadomie lub nie) zawyżają wyceny, powodując efekt inflacji – za więcej pracy dostajemy mniej funkcjonalności.

T-shirt Sizes – czy nie za obcisła…?

Kolejną, popularną metodą estymowania wielkości zadań jest T-shirt Size. Słowo „wielkość” nie jest tutaj przypadkowe, gdyż opiera się na porównywaniu do siebie zadań pod kątem właśnie rozmiaru. W odróżnieniu od Story Points, skupia się to na nadawaniu historyjkom rozmiarów koszulek, zazwyczaj XS, S, M, L, XL.

Na początek wybieramy historyjkę, która jest typową, codzienną pracą deweloperską i nadajemy jej wielkość M. Reszta odbywa się przez porównanie – np. mniejsza będzie miała rozmiar S, dużo większy rozmiar XL.

Dalsza część może się różnić w zależności od zespołu. Zwykle polega to na przypisaniu wartości liczbowej rozmiarowi koszulki, np. S=100, M=200, L=400 itd. i na tej podstawie szacuje się, ile pracy możemy zabrać do Sprintu (również bazując na wartościach historycznych).

Oczywiście da się także robić estymaty „rękami” architekta rozwiązania. Dla niektórych może to być dobre rozwiązanie, jednak, jeśli chcemy z niego skorzystać, musimy być świadomi z jakich zalet wyceny za pomocą innych technik rezygnujemy.

Estimates or No Estimates – that is the question

Tematem, który wraca jak bumerang w świecie zwinnego software developmentu, jest ruch, który sam siebie nazywa „#NoEstimates”, moim zdaniem niepotrzebnie wprowadzając w błąd i budząc kontrowersje – no, ale „reklama dźwignią handlu”.

Wydaje mi się, że na polskiej scenie Agile nadal panuje zbyt mało zrozumienia dotyczące tego ruchu. Jest to temat na zupełnie inny artykuł, jednak postaram się przedstawić jego esencję.

Sama filozofia #NoEstimates opiera się na tym, że należy w końcu zaakceptować fakt, że estymaty są niedokładne i nie będą już dokładniejsze. W związku z tym, zamiast skupiać się na dokładnym estymowaniu, należy ograniczyć czas „marnowany” na estymowanie. Ale jak? Tutaj już pełnej zgody nie ma.

Ale o tym więcej w następnym artykule. Żeby podsycić Wasz apetyt zostawię tutaj tego tweeta od Rona Jeffriesa, jednego z twórców Extreme Programming:

I am not sure I invented story points but if I did I’m sorry now. ?

— Ron Jeffries (@RonJeffries)

21 grudnia 2017

Podsumowanie

Nie wiem, czy Story Pointy pozwoliłyby mi się lepiej dogadać z mamą – w końcu nie interesował jej wynik Sprintu (meczu), tylko to, żeby skończył się na czas.  

Mam nadzieję, że trochę Wam się rozjaśniło. Jeśli nie – cieszę się jeszcze bardziej. Nie ma nic lepszego niż konstruktywna dyskusja, do której zachęcam w komentarzach.  

Źródła

[1] Conte, S.D., Dunsmore, D.E. and Shen, V.Y. Software Engineering Metrics and Models, cytuję za: Dina S. Ahmed Is your project’s best estimation method Agile or conventional? [dostęp 20.02.2019] Dostępny w: https://www.ibm.com/developerworks/library/d-estimation-agile-or-conventional-trs/index.html