Jako że tu trafiliście, z pewnością interesuje Was jeden z aspektów dotyczących estymacji. Zdajecie sobie sprawę, że wynikiem poprawnej wyceny jest przyjemna, zwinna praca. Poszukujecie odpowiedzi na pytanie jak estymować, jak robić to lepiej, skuteczniej. A może zaczęliście się zastanawiać, dlaczego to w zasadzie robimy? Czasami, szczególnie w branży IT, a w ogólności w środowiskach praktykujących programowanie zwinne i adoptujących Scrum – tak się po prostu robi. Jeśli ta odpowiedź nie jest wystarczająca, zapraszam do lektury. Poniższy tekst powstał na podstawie webinarium, którego nagranie jest dostępne tutaj.
Spis treści
O estymacji słów kilka
Dlaczego estymować?
Dla klienta
Dla PO
Dla dewelopera
Jak estymować?
Sposoby na planowanie
Planning Poker
5 częstych błędów i wskazówek dotyczących Planning Pokera
Sugerowanie wycen i konformizm
Przekombinowanie estymacji
Brak punktu odniesienia
Zadania „zerówki”
Toksyczne porównania
Skala i jednostki
O estymacji słów kilka
Słowa estymacja, szacowanie czy wycena funkcjonują wymiennie. Rozumie się pod nimi proces określania kosztu pewnej czynności w oparciu o niepełne dane, różnego typu zakłócenia czy uproszczone cechy i parametry. Nie jest to jednak zwyczajne wyznaczanie tego kosztu. Wtedy byłoby znacznie łatwiej. Niestety musimy się pozmagać z nutką albo i całą symfonią tajemnicy i niewiadomych.
Szacowanie w nieco innym ujęciu rozumiemy również jako alternatywę. Załóżmy, że Product Owner zadaje nam, deweloperom, pytanie: „ile zajmie dodanie CAPTCHA w naszym formularzu?” Jeżeli nie chcemy uciekać się do mechanizmów losujących, kryształowych kul, a wiemy, że ownerowi zwykłe „nie wiem” nie wystarczy, wtedy jak na białym koniu wjeżdża estymacja.
Firmy w branży IT praktykują Scrum lub przynajmniej są na jakimś etapie jego adopcji. Na początku warto stwierdzić, że estymacja jest bardzo ważną częścią tego frameworka. W Scrum Guide występują zdania takie jak:
- „Elementy Backlogu Produktu posiadają następujące atrybuty: opis, kolejność, oszacowanie i wartość.”
- „Praca może być zróżnicowana pod kątem ilości lub szacowanej pracochłonności.”
- „W miarę jak praca jest wykonywana albo kończona, aktualizowane jest oszacowanie pozostałej do wykonania pracy.”
- „Wszystkie nieukończone elementy Backlogu Produktu są ponownie szacowane i zwracane do Backlogu Produktu.”
W oryginalnej angielskiej wersji językowej tej lektury słówko estimate występuje aż 9 razy, ale… nie estymujemy dlatego, albo wyłącznie dlatego, że tak jest w teorii. Prawdziwe pytanie jest następujące:
Dlaczego estymować?
Jaka jest siła wyceny i jakie może mieć konsekwencje? Podejmując próbę odpowiedzi na to pytanie, przyjrzyjmy się krótkiej anegdocie.
Jest 1 kwietnia 2019, wczesny wieczór, Toruń. Bohater opowieści o imieniu Jacek pojawia się w domu po dniu pełnym dobrej zabawy. Po godzinie wieczornego relaksu Jacek postanawia zamówić jedzenie na jednym z popularnych serwisów dowozowych. Zważywszy na wzmagający się głód, decyduje się na pierwszą z brzegu pizzerię Pikuś. Całkiem dobre oceny i przystępne menu. Przesądzającym jednak wybór czynnikiem jest krótki czas dostawy – do 30 minut.
„Biorę to!”, pomyślał Jacek, zamawiając Margheritę. Dwie minuty później na jego skrzynce mailowej wylądowała wiadomość o potwierdzeniu zamówienia z utwierdzeniem go w świadomości, że jego zamówienie zostanie zrealizowane w przeciągu pół godziny. Niestety, rzeczywistość szybko ostudziła entuzjazm Jacka. Lekko ponad godzinę od zamówienia granice cierpliwości naszego bohatera poczuły pierwszy odśrodkowy nacisk. Dostawcy nie było widać. Półtorej godziny później – nadal nic, zero, null. Po dwóch godzinach „bing!”, wiadomość na skrzynce mailowej. Tym razem okrutny żart maszyny, czyli zautomatyzowane „co sądzisz o swoim zamówieniu?”. Było to nawet uzasadnione, bo to przecież pierwszy kwietnia, ale z perspektywy czasu – najmniej ulubiony żart primaaprilisowy Jacka ever. Niespełna 3 godziny od rozpoczęcia zamówienia, ku uciesze naszego głodomora, dostawca pizzy zadzwonił do drzwi. Jacek oczywiście odebrał i Margheritę zjadł z apetytem, jednak niesmak pozostał. Niesmak po tym, jak zamówił pizzę z trzydziestominutową dostawą, a otrzymał z trzygodzinną. Jaki morał z tej historii? Estymacja jest istotna!
Dla klienta
To 30 minut to nic innego jak efekt pewnej estymacji – przybliżony czas realizacji zamówienia, będący jednocześnie jednym z głównych czynników odróżniających tę pizzerię od wszystkich pozostałych na liście. Nie wiadomo do końca, czy odpowiada za nią serwis, czy sama pizzeria. Wiemy jednak, że dla Jacka, jako klienta, nie ma to w zasadzie znaczenia. Liczy się efekt, który w tym przypadku nie był satysfakcjonujący z powodu błędu estymacyjnego. Zamawiając jedzenie z dowozem, najczęściej kierujemy się trzema czynnikami:
- Jakością – tutaj o subiektywnej różnicy może dla nas świadczyć na przykład smak pizzy.
- Kosztem – jesteśmy w stanie zapłacić więcej za lepszej jakości produkt, ale czasami nie chcemy (przekonani oszczędnością) albo nie musimy (bo czasami dobre jest też tanie).
- A także czasem dostawy.
Można więc dojść do wniosku, że my jako klienci kierujemy się kombinacją tych potrzeb w zasadzie w każdej dziedzinie życia. Inaczej podchodzimy do jakości w kontekście pizzy, a inaczej na przykład w odniesieniu do dostarczanego oprogramowania, ale pewne rzeczy pozostają uniwersalne i niezmienne – na przykład przewidywalność dostarczenia produktu czy usługi.
O ile koszt opóźnionej dostawy pizzy dla nas jako klientów nie wzrośnie, niedoszacowanie w modelu rozliczeń typu „time and material” może być naprawdę opłakane w skutkach. Szczególnie jeżeli w grę wchodzą setki tysięcy albo i miliony w kontraktach, bo takie kwoty w branży IT nie są rzadkością.
Podsumowując, nie lubimy złej estymacji. I choć nie możemy przepowiedzieć przyszłości, możemy starać się ją przewidzieć, by być może części takich nieprzyjemnych sytuacji komuś, a być może i naszemu klientowi, oszczędzić.
To jest właśnie odpowiedź na pierwsze dlaczego. Estymacja pomaga nam uzyskać i zachować przewidywalność. Ta nie powinna być celem samym w sobie, ale trudno byłoby wskazać branżę usługową, w której nie byłaby co najmniej pożądana.
Dla PO
Politykę zostawmy z boku, chodzi o Product Ownera. Szerzej jednak interpretując postać, możemy zaliczyć do tej grupy także innych przedstawicieli „biznesu”, którzy pełnią podobną do PO rolę w naszych organizacjach. Aby lepiej zrozumieć potrzebę tych osób, przyjrzyjmy się sylwetce prawdziwego PO.
Poznajcie Adama Marka. Adam Marek to PO pełną gębą, robota wręcz pali mu się w rękach, jest zabiegany od świtu do zmierzchu. Z jednej strony próbuje dowiedzieć się, co będzie największą wartością dla użytkowników jego aplikacji. Z drugiej stale zastanawia się jak zoptymalizować pracę zespołu deweloperskiego. A na dodatek do tego wszystkiego w zakresie jego obowiązków znajduje się także ogarnięcie backlogu produktu. Adam Marek całe dnie spędza jednak przede wszystkim na próbach znalezienia balansu pomiędzy wartością i kosztem. Żadna funkcjonalność, choćby nie wiadomo jak fajna, nie powinna się nie opłacać. Co zatem możemy zrobić, by pomóc biednemu Adamowi w podjęciu ostatecznej decyzji?
Rozpatrzmy konkretny przykład – nowa funkcjonalność, o którą klient bardzo się dopomina. Jej tytuł to „Dodanie możliwości logowania przy pomocy konta Apple”. Chodzi o taki przycisk, który pozwala zalogować się do aplikacji bez konieczności wymyślania i wpisywania hasła. Logowanie odbywa się przy pomocy loginu Apple, a wszystkie dane, np. kontaktowe zostaną pobrane z tego konta. Pytanie, które zadaje sobie Adam to czy i kiedy podjąć pracę nad tym zadaniem. Co może wpłynąć na odpowiedź?
- Feedback klienta końcowego. Uznany za bardzo ważny, ale bez szerszej analizy brzmi jak jednostkowa opinia.
- Liczba użytkowników. Aplikacja, nad którą pracuje zespół Adama, jest multiplatformowa. Wychodzi na Androida i iOSa. Dość istotną statystyką może być zatem stosunek użytkowników jednego i drugiego systemu.
- Współczynnik konwersji. Aplikacja Adama posiada opcjonalną usługę abonamentową i załóżmy dwa scenariusze. Co jeżeli współczynnik wynosi mniej więcej tyle samo dla obu platform, a co jeśli aż 1 na 10 użytkowników iOSów dokłada się do biznesu?
- Wiedza, ile wdrożenie takiej funkcjonalności będzie kosztowało klienta. W jednym przypadku 10 tysięcy to kropla w morzu wydatków, w drugim kwota na granicy budżetu, która może pogrzebać biznes klienta. Świadomość równowartości kosztu w walucie to bardzo ważna informacja.
- Czas. Tutaj może funkcjonalność nie jest aż tak sezonowa, ale bywa różnie. Różnica pomiędzy tygodniem a czterema jest dość znacząca.
Czy mając te dane przed oczami, Adam może z czystym sumieniem odpowiedzieć już na pytanie, czy i kiedy podjąć pracę nad tym zadaniem? Spróbujcie sobie zrobić taki eksperyment. Wyobraźcie sobie tę aplikację i sytuację, a także dylemat, który przed Wami stoi. Zastanówcie się, czy i o ile trudniejsze byłoby uzyskanie odpowiedzi na to pytanie, gdyby z Waszych oczu zniknęły dane oznaczone jako koszt i czas wytworzenia. A co byłoby, gdyby te dane były dostępne, ale nie były wiarygodne?
Na szczęście pośrednio informacje te można uzyskać za pośrednictwem estymacji i właśnie to zawiera się w drugim dlaczego. Estymujemy, bo estymacja pomaga nam planować i priorytetyzować pracę.
Dla dewelopera
Proces estymacji bywa niekiedy naprawdę uciążliwy dla deweloperów. Często można spotkać się z następującymi stwierdzeniami: „po co w ogóle to wycenianie, szybciej byłoby to po prostu zrobić…”, „strata czasu, same z tym problemy” czy „po co mam podawać jakieś głupie cyferki?”
Proces ten, przyłożony w odpowiedni sposób w odpowiednim miejscu, może jednak być dość sensowną odpowiedzią na innego typu problemy. Na przykład kiedy rzecz, która w zasadzie jest już zrobiona, w pewien magiczny sposób okazała się wymagać całego dnia przekopywania się przez kod?
Idąc dalej, rozważmy dwa konkretne przykłady, które zilustrują potencjalne zalety estymacji dla deweloperów. Przy pierwszym przykładzie załóżmy, że Product Owner przedstawia zespołowi wymagania dotyczące pewnego zadania. Dla uproszczenia, załóżmy, że celem tego zadania będzie stworzenie prostokąta. Product Owner ma nawet jakiś konkretny pomysł na ten prostokąt, jednak jaki dokładnie, wie wstępnie tylko on. Jeżeli zrozumienie celu zadania różni się w zespole deweloperskim, to istnieje spora szansa, że takie nieścisłości wypłyną, a następnie zostaną wyeliminowane na przykład podczas pytań o szczegóły zadania czy też wskutek wewnętrznej dyskusji. Estymacja w naturalny sposób wspiera bowiem wspólne zrozumienie tematu, które jest tak ważne zarówno na etapie wyceny, jak i realizacji zadania.
Drugi przykład dotyczy nowej funkcji. Od Product Ownera tym razem wpada pytanie o szansę na wdrożenie pewnej integracji dotyczącej płatności w czasie następnego sprintu. Gdyby odpowiedzi miał udzielić tylko jeden, pierwszy z brzegu deweloper, to odpowiedź uzależniona byłaby od ograniczonego zasobu wiedzy tej konkretnej osoby. Próba oszacowania takiego zadania skupia jednak uwagę wszystkich wykonawców w danym kontekście, dzięki czemu znacznie łatwiej wyłapać nie tylko to, czy zadanie, kolokwialnie mówiąc, zmieści się do sprintu, ale także czy nie istnieją inne zależności lub ryzyka, które należy wziąć pod uwagę.
Te sytuacje i aspekty obrazują trzecie i ostatnie już dlaczego. Estymujemy, bo estymacja pomaga nam lepiej zrozumieć wymagania i zminimalizować ryzyka.
Jak estymować?
Mówiąc o estymacji bardzo często uciekamy się do mówienia o czasie. Nasze wyceny, niezależnie od obranej metody czy skali, i tak w pewnym momencie sprowadzamy do minut, godzin, czy popularnych w korpoświecie mandayów. Może zatem nie ma się co bawić w jakieś story pointy i Fibonacciego, i po prostu szacować czasochłonność naszej pracy bezpośrednio w godzinach? No cóż… nie, zdecydowanie lepiej nie i lepiej uważać na takie próby. Jest ku temu jeden, aczkolwiek bardzo prosty powód. Jesteśmy słabi w planowaniu bezwzględnym.
W zasadzie to okazało się dawno temu i na przestrzeni wielu badań, i teraz wiemy, że stoi za tym zjawisko, tzw. planning fallacy. Złudzenie planowania to nic innego jak skłonność do niedoceniania czasu potrzebnego na ukończenie pewnego zadania. Obrazującym problem przykładem może być eksperyment z udziałem studentów. Poproszono ich bowiem o określenie, ile czasu zajmie im napisanie pracy magisterskiej. Wywiad wykazał, że średnia przewidywań to 33,9 dnia, natomiast faktyczny uśredniony czas ukończenia prac wyniósł 55,5 dnia. Dodatkowo zaledwie 30% studentów ukończyło swoją pracę w założonym czasie.
Rozjazdy tak duże zdarzają nam się przede wszystkim przy okazji szacowania zadań złożonych, skomplikowanych. Zadanie takie jak na przykład odśnieżenie metra kwadratowego chodnika jest oczywiście trudne i wymagające, ale nie jest złożone. Odśnieżenie drugiego metra powinno nam zająć mniej więcej tyle samo czasu, co pierwszego i już po odśnieżeniu paru jesteśmy w stanie stosunkowo dokładnie oszacować czas konieczny do odśnieżenia całego podjazdu o wielkości 10m2. Zupełnie inaczej sprawa ma się jednak w przypadku na przykład pracy programistycznej. Wiele złożoności technicznych przeplata się z zależnościami interpersonalnymi, przez co często nawet najprostsze zadania są ponadprzeciętnie złożone w realizacji. I w szacowaniu dokładnie tego typu zadań my, jako ludzie, jesteśmy raczej słabi. I mogłoby się wydawać, że tak po prostu jest i musi być. Nasza wrodzona ułomność przeszkadza nam w codziennej pracy i raczej nie zamierza przestawać – co możemy zatem zrobić?
Sposoby na planowanie
Na całe szczęście mamy jednak kilka sztuczek, którymi możemy się wspomóc, żeby zwykle niedokładne planowanie bezwzględne uczynić nieco bardziej dokładnym.
- Opinia eksperta. Osoby bardzo biegłe w danym temacie mają naturalnie większe szanse, by przewidzieć pewne zależności czy ryzyka i dzięki temu lepiej oszacować złożoność pewnego, znanego sobie typu zadania. To jest „jakieś” wyjście – sporo publikacji na przestrzeni lat pokazuje jednak, że jakkolwiek świetna nie byłaby ta ekspertyza – znacznie lepiej sprawdza się kolektywny wysiłek grupy osób – a jeszcze lepiej, dokładnie tych osób, które są odpowiedzialne za wykonanie danego zadania.
- Metoda porównawcza. Z grubsza polega ona na tym, żeby nawet nie starać się oszacować dokładnej złożoności czy czasochłonności danego zadania, a jedynie porównać je do innego i spróbować wskazać, czy jest prostsze, bardziej złożone czy mniej więcej takie same.
- Dzielenie wymagań na mniejsze. Wyobraźmy sobie na przykład aplikację mobilną jakiegoś sklepu internetowego. Gdybyśmy mieli oszacować pracochłonność związaną z jej wykonaniem, to nasze estymaty mogą diametralnie się różnić. Mnóstwo zależności umknie naszej uwadze i jeżeli sprowadzilibyśmy tę wycenę do czasu, to mogłoby nam wyjść coś pomiędzy miesiącem a sześcioma. W przypadku biznesów taka różnica może być jednak zupełnie nieakceptowalna, dlatego potrzebujemy większej granulacji. Z większą dokładnością będziemy jednak w stanie oszacować tylko funkcjonalność logowania albo koszyka, albo funkcji szybkiego kup teraz. Być może nawet podczas procesu dowiedzielibyśmy się, że część pracy, które uznaliśmy wstępnie za niezbędne, wcale nie jest konieczna do uruchomienia takiej aplikacji.
Mamy zatem trzy metody, z których każda ma naprawdę fajne zalety, ale żadna z nich nie może być kompleksowym rozwiązaniem wszystkich naszych problemów. Co stałoby się natomiast, gdybyśmy chcieli mieć je wszystkie – zamknięte w jednej metodzie? Nie musimy się zastanawiać, ktoś już to za nas zrobił.
Planning Poker
Jakiś czas temu ktoś wziął zalety opinii eksperckiej, mocne punkty metody porównawczej, a także wszystkie plusy praktyki dzielenia wymagań na mniejsze. Dodał do tego trochę abstrakcyjnych jednostek i skali i tak właśnie powstał znany i lubiany Planning Poker.
Poker to prawdopodobnie najpopularniejsza metoda wspomagająca estymację w zwinnych środowiskach wykorzystujących Scrum. Pierwszym etapem jest przedstawienie wymagań. W roli moderatora dyskusji występuje Product Owner, w naszym przypadku jest to Adam Marek. Adam przychodzi i kładzie na stół wymaganie zawarte wewnątrz takiego Jira ticketa – „Dodanie do formularza zabiezpieczenia Captcha”. Wymaganie przedstawiane jest zespołowi deweloperskiemu, a w głowach jego członków pojawiają się pierwsze przemyślenia. Zespół deweloperski ma teraz chwilę, by dopytać o szczegóły dotyczące zadania.
Następny etap to pierwsza runda głosowania. Przed głosowaniem proponowane wyceny powinny być weryfikowane w oparciu o inne zadania, by skorzystać z zalet metody porównawczej. Wszystkim uczestnikom musi być znana również jednostka oraz skala, z której zespół korzysta. Zespół w jednym momencie prezentuje swoje wyceny. Jeżeli mamy do czynienia z dużą rozbieżność pomiędzy opinią jednostki oraz reszty grupy, dobrą praktyką jest poddanie tego zadania dyskusji. Na tym etapie wyjaśniane są dodatkowe rozjazdy. Odzywa się na przykład deweloper, który ma doświadczenia z implementacją CAPTCHY i który ma także pewną świadomość problemów z nią wynikających. W ten sposób zyskujemy wgląd w opinie eksperckie. Dzięki dyskusji poznajemy także ryzyka oraz zależności, które, szczególnie jeżeli zostaną zapisane, ułatwią pracę wdrożeniową.
Po wygaszeniu dyskusji przechodzimy do kolejnego etapu jakim jest następna runda głosowania. W momencie kiedy Product Owner akceptuje wycenę, można przejść do estymacji następnego zadania.
Przyjrzeliśmy się zatem Planning Pokerowi jako alternatywie dla klasycznego planowania bezwzględnego i… czy jest to alternatywa idealna? Absolutnie nie. Metoda ta, choć prosta, skuteczna i ma swoich wiernych fanów, ma też wielu zagorzałych przeciwników. Planning Pokerowi tak jak wszystkiemu można oczywiście sporo zarzucić, ale mam tezę, że część z nich nie byłaby zasadna, gdyby jej użytkownikom udało się uniknąć kilku popularnych błędów i pułapek.
5 częstych błędów i wskazówek dotyczących Planning Pokera
Sugerowanie wycen i konformizm
Zacznijmy od częstego błędu sugerowania wycen i związanego z tym konformizmu. Posłużę się dla tego przykładu prawdziwym klasykiem Internetu. Przypomnijmy sobie zatem, jak przebiegała legendarna już partia Familiady.
Absolutnie cudowne odpowiedzi i ta zabawna sytuacja obrazują jednak dość smutną właściwość nas, ludzi oraz zjawiska, którym często ulegamy. Konsternacja na twarzy tej drugiej pani sugeruje, że nie jest ona szczególnie przekonana do odpowiedzi „lama”, prawda? Całkiem prawdopodobne, że pani ta odpowiednio zrozumiała zadane przez Karola pytanie już za pierwszym razem, ale uległa chęci dostosowania się do cudzej opinii. Na pewno nie pomogło w tym wypadku, że pani odpowiadająca jako pierwsza wypowiedziała „owca” z dużą pewnością siebie. Wobec tak przedstawionego komunikatu przekonanie tej starszej pani – niestety – przestało mieć znaczenie. Zdecydowała się zrezygnować ze swojej wiedzy na rzecz dopasowania się. To zjawisko występuje również w bliższym nam środowisku. Podczas sesji Planning Pokera, kiedy przykładowo ktoś zasugeruje wycenę podczas dyskusji, bądź wcześniej odkryje swoją kartę. Jakie jest rozwiązanie? Proste. Odkrywajcie swoje karty jednocześnie i nie sugerujcie wycen w trakcie dyskusji.
Przekombinowanie estymacji
Wykres, który widzicie, pobrałem z książki „Agile Estimating and Planning” autorstwa Mike’a Cohna. Wskazuje on na uogólniony stosunek wysiłku do dokładności w kontekście estymacji. Wróćmy do prostego przykładu z odśnieżaniem podjazdu. Dla uproszczenia załóżmy, że mamy do odśnieżenia zaledwie jeden metr kwadratowy. Śniegu jest na oko tak do kostek, więc potrzebujemy to zrobić. Do tego zadania możemy podejść na bardzo wiele sposobów, jednym z nich i najbardziej także intuicyjnym wydaje się po prostu wzięcie łopaty do ręki i machnięcie kilka razy. Zajmie nam to max parę minut i z grubsza załatwi problem. Możemy jednak również zaopatrzyć się w specjalistyczny sprzęt i odśnieżyć ten podjazd na poziomie niemal cząsteczkowym. Możemy drobnymi szczotkami wymiatać poszczególne drobinki, resztki topiąc, ale istnieje spora szansa, że bardzo się przy tym narobimy, a różnica, ta zauważalna dla zwykłego Kowalskiego, będzie niemal niewidoczna.
Podobnie sprawa ma się z estymacją. Można dążyć do pewnych standardów mając to zjawisko na uwadze. W większości przypadków jedna sesja dyskusji i dwie tury głosowania wystarczą, by dojść do zadowalającego konsensusu. (PS. Chcecie dowiedzieć się więcej o dochodzeniu do konsensusu? Koniecznie obejrzyjcie nagranie z webinarium Sławka).
Brak punktu odniesienia
Kolejnym częstym błędem jest pozbawianie się punktu odniesienia. Wracamy do momentu, w którym moderator sesji prosi o ujawnienie swoich głosów, a zespół po prostu to robi. Problemy mogą się pojawić, jeżeli pokazana wycena nie została oparta o żadne porównanie. Zwykle wydaje się nam, że pamiętamy, ile mniej więcej złożoności rozumiemy jako ósemkę lub trójkę, nasza pamięć działa jednak dość selektywnie i pamiętamy jedynie część pełnego obrazu. W efekcie, jeżeli nie zweryfikujemy swojego przeczucia, możemy mimowolnie zmierzać z estymatami w niepożądanym kierunku – tu znów, samodzielnie pozbawiając się jednej z największych zalet Planning Pokera, czyli metody porównawczej.
Jak sobie z tym radzić? Spojrzenie na inne elementy backlogu może pomóc. Alternatywnie możemy też przygotować sobie tabelę referencyjną, w którą wrzucimy kilka historyjek, aby później, patrząc na nią, każdorazowo skorzystać z całego dobrodziejstwa metody porównawczej.
Zadania „zerówki”
Kolejna wskazówka i dość kontrowersyjny temat, dlatego nie uznaję go za błąd jako taki. Chodzi jednak o zadania z estymacją równą 0 – dotyczy oczywiście skali liczbowej lub, jeżeli korzystamy z innych jednostek, to zadanie zostałoby po prostu nieoszacowane.
Osadźmy się jeszcze raz w kontekście sesji Pokera. Product Owner przychodzi z wymaganiem, aby zmienić podpis w mailu. Chodzi o jakąś drobnostkę, dosłownie zmianę kilku zdań, ewentualnie drobne poprawki stylistyczne. Deweloper odpowiada: „po co o tym w ogóle gadamy? Już dawno byśmy to zrobili” Brzmi znajomo?
Nie mogę nie zgodzić się, że zadania tak trywialne się zdarzają i od tej zasady również istnieją wyjątki. Jednak głęboko wierzę, że choćby minimalny wkład w proces estymacji nawet pozornie prostych zadań może nas uchronić przed wieloma takimi przypadkami. Moja propozycja rozwiązania tego problemu jest prosta: zrezygnujcie z zerówek. Spróbujcie działać ze swoją skalą w ten sposób, żeby ten minimalny zakres prac, minimalna złożoność, miała jakiś swój, niezerowy odpowiednik w estymacji.
Toksyczne porównania
I ostatni błąd i wskazówka. Tutaj puszczam trochę oko szczególnie do przedstawicieli biznesu. Chciałbym skierować te słowa do wszystkich osób, które szukają jakiejś metryki do optymalizacji właśnie na przykład wśród story pointów. Próba porównania liczby punktów, które zawierają się w pojedynczym sprincie niepowiązanych ze sobą zespołów jest zgubna. Takie słowa można z pewnością usłyszeć w wielu organizacjach: „dlaczego robimy tylko 20 punktów w sprincie? Tamten zespół robi 60 w tym samym czasie.”
Oczywiście może być tak, że jeden zespół pracuje w jakimś tam kontekście wydajniej, ale absolutnie nie wynika to z takiego porównania. Te punkty w ogóle nie są porównywalne. To są zupełnie różne skale, których nawet nie ma sensu synchronizować. Rozwiązanie? Nie starajmy się też porównywać zespołów, które wydaje nam się, że mają podobną skalę. Jeżeli nie estymują razem, to nie mają, naprawdę. Trudno dostrzec w tym wartość, może poza jakąś taką siermiężną, staromodną motywacją pracowników i wjeżdżaniem na ich ambicje.
Skala i jednostki
Jak podejść do kwestii skali i jednostki wyceny? Rozwiązań jest kilka i tak naprawdę nie ma rozwiązania idealnego.
Najpopularniejsza z dostępnych opcji to ciąg Fibonacciego. Praktycznie każdy go zna, dzięki rosnącym przerwom pomiędzy kolejnymi wartościami zyskujemy ważny bufor estymacyjny dla zadań, które są naprawdę złożone. Jednym z zarzutów kierowanych do estymacji liczbowej jest natomiast tendencja do sprowadzania story pointów koniec końców i tak na przykład do dniówek. Jeżeli macie z nimi jakieś doświadczenia, to być może nawet słyszeliście takie głosy „że na przykład no ta jedynka to jest dla nas manday”. I to trochę zaburza tą oryginalną ideę, to fakt.
Proponowaną przez przeciwników story pointów w postaci ciągu Fibonacciego alternatywą jest estymacja w rozmiarach koszulek. W naszej skali znajdują się wtedy XS, S, M, L itd. Jeszcze w innym ujęciu czasami stosuje się na przykład rasy psów, np. „to zadanie to typowy labrador.” Obie te metody mają trochę sensu, stoi za nimi jakiś zamysł i próba rozwiązania konkretnego problemu. Korzystanie natomiast na przykład z ras psów niesie ze sobą jeszcze inny problem, a mianowicie dodatkowy narzut pracy w celu zaplanowania jakiegoś okresu. Tam gdzie królują liczby, ładnie się sumują, a w dłuższej perspektywie i uśrednieniu pozwalają także zespołowi poczuć się komfortowo i przewidywalnie. Velocity wyrażone natomiast na przykład w 4 mopsach… Cóż, często za tymi psami kryją się i tak po prostu kolejne wartości wybranego ciągu. Czy jest więc sens generować sobie podwójną pracę?
