Estymacje relatywne – jak i po co?

Napisano przez

Ile metrów ma budynek za oknem? Ciężko stwierdzić? A gdybym powiedział, że ten obok, wyższy ma 62 metry wysokości. A ten z drugiej strony, niższy ma 35 metrów. Czy wtedy byłoby łatwiej?

Na tym właśnie polegają estymacje relatywne. Na porównywaniu z czymś, co już znamy i określaniu na tej podstawie rozmiaru, złożoności, pracochłonności etc. Estymacje relatywne są bardzo popularne zwłaszcza w połączeniu ze zwinnymi metodykami tworzenia oprogramowania (jak np. Scrum).

Po co estymujemy?

Odpowiedź może wydawać się oczywista, ale mimo wszystko warto zadać to pytanie. Głównym celem estymacji jest poznanie szacowanej pracochłonności i złożoności zadania oraz wynikającego z nich czasu niezbędnego na jego realizację. Innymi słowy chodzi o „koszt” realizacji danego zadania, zwykle polegającego na zrealizowaniu określonych wymagań. Koszt jest niezbędną informacją służącą do podjęcia decyzji czy, a jeśli tak, to kiedy coś będzie realizowane.

Dodatkowym, nieco „ubocznym” skutkiem estymowania jest doprecyzowanie zakresu, jego omówienie i osiągniecie wspólnego zrozumienia pomiędzy interesariuszami. Są to pewne dodatkowe, pozytywne efekty procesu zespołowego szacowania wymagań i zadań, z których warto zdać sobie sprawę.

Jakich jednostek używać do estymowania?

Estymacje relatywne skupiają się na szeroko rozumianej „wielkości” danego zadania lub wymagania. Nie polegają na określaniu ilości czasu niezbędnego do jego realizacji. Zatem nie wykorzystują „wymiernych” jednostek jak godzina, dzień, czy tydzień pracy. I bardzo dobrze, bo z wyceną opartą na jednostkach czasu bywa dużo kłopotów. Jeśli wyceniamy w dniach lub godzinach to właściwie czyich? Najlepszej osoby w zespole czy tej o najniższych umiejętnościach? Osoby doświadczonej, czy nowicjusza, który dopiero dołączył do zespołu? Poza tym jak liczyć czas? Dzień pracy to 8h? Tyle chyba nie pracujemy bo mamy spotkania, przerwy i inne „rozpraszacze”. Ile więc godzin przyjąć?

Dodatkowym problemem jest zwyczajna trudność określania czasu potrzebnego na zrealizowanie dużych zadań lub ogólnych wymagań. O ile estymacja czasowa niewielkiego, prostego zadania wydaje się niezbyt skomplikowana to w przypadku wyceny większych „jednostek pracy” precyzyjna estymacja tego rodzaju bywa już trudna, a na pewno staje się czasochłonna i skomplikowana. Zwłaszcza jeśli w grę wchodzi pewne niedoprecyzowanie i wynikająca z niego niepewność.

Jak widać problemów jest sporo. Z tego właśnie powodu, estymacje bazujące na określaniu czasu niezbędnego na realizację są często „nietrafione”, a przez to mało wiarygodne.

Story point

Standardowo do estymacji relatywnych używa się jednostki zwanej Story Pointem. Nazwa ta związana jest z faktem, że wyceniane wymagania opisywane są bardzo często w formie Historyjek Użytkownika (ang. User Stories). Czym właściwie jest Story Point? Trudno powiedzieć, bo dla każdego zespołu deweloperskiego może on mieć inną wartość i reprezentować inną ilość pracy. Zależy to od wybranych referencji, o których mowa poniżej.

Ciąg Fibonacciego

Zwyczajowo do estymacji używa się wartości znajdujących się w ciągu Fibonacciego. Kolejne wyrazy tego ciągu są tworzone poprzez zsumowanie dwóch poprzednich. Mamy zatem: 1, 1, 2, 3, 5, 8, 13, 21 etc. Dlaczego używanie ciągu Fibonacciego jest wygodne? Bo jego kolejne wyrazy są od siebie coraz bardziej oddalone. Dzięki temu estymacje dość niewielkich zadań lub mało skomplikowanych wymagań mogą być dość precyzyjne, a wraz ze wzrostem estymacji, w sposób naturalny ich precyzja spada, co odpowiada coraz to większemu oddaleniu dostępnych wartości.

Relatywne estymacje – jak wybrać referencje?

Jak już wspomniałem we wstępie, wszystko polega na porównywaniu czegoś nowego, co ma być zrealizowane (zadań, wymagań) z czymś, co już znamy. Musimy określić referencje. Bywa to dość trudne, gdyż ustalenie referencji wymaga wypracowania konsensusu w ramach całego zespołu, który będzie ich używał. Wszyscy jego członkowie muszą się zgodzić, że dana „porcja” wyrażona np. w formie już zrealizowanych zadań lub wymagań, odpowiada ustalonej liczbie Story Pointów.

Istnieje kilka podjeść z tym związanych. Chyba najpopularniejsze z nich to te zaprezentowane poniżej.

Referecja na poziomie jednego Story Pointa

Popularnym podejściem jest ustalenie referencji na poziomie jednego Story Pointa, czyli najmniejszej realnej do wykonania pracy. Zespół w takim wypadku ustala, co jest lub mogłoby być najmniejszym realnym zadaniem do wykonania i przyjmuje to za wartość minimalną, odpowiadającą jednemu Story Pointowi.

Tego rodzaju referencje bywają jednak nieco kłopotliwe w użyciu. Trudne jest porównać duże i skomplikowane zadanie lub realizację złożonego i niebanalnego wymagania do czegoś bardzo małego i prostego. Ciężko w końcu oszacować wielkość drapacza chmur na podstawie porównania go ze stojącym obok pawilonem z warzywami. Jest wyższy 50 razy? A może 80, czy raczej 120 razy? Z tego właśnie względu jestem zwolennikiem metody doboru referencji opisanej poniżej.

Referencje na kilku poziomach

Efektywniejsze i wygodniejsze wydaje się być ustalenie referencji na kilku poziomach, np. na poziomie 3 i 13 Story Pointów. Mamy zatem, na przykład taką sytuację i dostępne wyceny:

  • 1 SP
  • 2 SP
  • 3 SP – na tym poziomie ustalamy referencje
  • 5 SP
  • 8 SP – na tym poziomie ustalamy referencje
  • 13 SP
  • 21 SP – to maksymalna dopuszczalna estymacja

Na poziomie 3 oraz 13 Story Pointów zespół ustalił pewne referencje (odniesienia) w formie już zrealizowanych zadań lub wymagań. Mogę one być opisane w formie User Story (lub dowolnej innej). Estymację równą 21 Story Pointów uznano za wartość graniczną. Jeśli zdaniem zespołu dane zadanie lub wymaganie wydaje się być „większe” to zgodnie z zasadami INVEST powinno być ono podzielone na mniejsze części, tak aby było możliwe do zrealizowania w ramach jednej iteracji (Sprintu).

Porównywanie z referencjami

Mając już ustalone referencje, estymujemy wymagania lub zadania porównując je właśnie z nimi. Nie pytamy zespołu „Ile Wam to zajmie?”, „Jak dużo potrzebujecie czasu?”. Pytamy tylko czy coś jest większe, mniejsze, czy może takie samo jak coś, co już znacie. Estymujemy zatem nie czas a wielkość zadania. Porównanie i określenie: mniejsze / większe / zbliżone wydaje się być o wiele prostsze niż określenie ilości czasu potrzebnego na realizację.

Velocity – czym jest i jak go używać?

No dobrze, mamy już wycenę poszczególnych wymagań lub zadań w pewnych relatywnych jednostkach zwanych np. Story Pointami. Co dalej? Musimy przecież wiedzieć, jak dużo zaplanować na daną iterację (zakładając, że pracujemy w metodyce iteracyjnej) oraz oszacować, kiedy coś będzie gotowe. Do tego właśnie służy wartość nazywana z angielskiego „Velocity„. Najprościej mówiąc jest to prędkość, z jaką zespół dostarcza zadania/wymagania.

Velocity obliczane jest zazwyczaj jako średnia ilość Story Pointów dostarczona w kilku poprzednich iteracjach (zwykle 3-6). Zatem, aby poprawnie je obliczyć, musimy mieć pewną historię pracy zespołu i związane z nią dane.

Przypuśćmy, że zespół w ciągu ostatnich 3 Sprintów zrealizował wymagania o łącznej wycenie: 47, 54, oraz 49 Story Pointów. Oznacza to, że Velocity zespołu to: 50 SP. Czyli na kolejną iterację (Sprint) zespół powinien zaplanować realizację zadań/wymagań o łącznej wycenie około 50 SP. Oczywiście wielkość tą można skorygować o znane i planowane nieobecności członków zespołu etc.

A jak wycenić, kiedy dany projekt lub jego część będą gotowe? Załóżmy, że łączna wycena naszego Backlogu, czyli aktualnie znanego zbioru zdań i wymagań do zrealizowania w ramach projektu jest oszacowana aktualnie na 340 Story Pointów. Biorąc pod uwagę Velocity równe 50 SP, oznacza to, że na zrealizowanie całości zespół będzie potrzebował prawdopodobnie 7 iteracji. Jeśli każda z nich trwa 3 tygodnie, daje to 21 tygodni na zrealizowanie omawianego zakresu.

Relatywne estymacje – co wziąć pod uwagę?

Poza oczywistym czynnikiem, jakim jest ilość pracy do wykonania, dokonując estymacji dobrze jest też uwzględnić:

  • Poziom wiedzy i doświadczenia – jak duża jest nasza wiedza w danym obszarze? Czy mamy doświadczenie w realizowaniu podobnych zadań/wymagań?
  • Złożoność / trudność – jak skomplikowane jest dane zadanie? Czy do jego zrealizowania są niezbędne specjalistyczne kompetencje?
  • Niepewność – czego nie wiemy i co potencjalnie może pójść nie tak?

Moje rekomendacje

  • Używaj estymacji relatywnych, zwłaszcza gdy wycena jest wstępna, wyceniane zadania lub wymagania są duże i skomplikowane, a dodatkowo istnieją pewne niedoprecyzowania i niepewności
  • Przyłóż dużą wagę do określenia referencji – od ich jakości zależy finalna jakość dokonywanych estymacji
  • Estymując weź pod uwagę dodatkowe czynniki, które mogą mieć wpływ na finalną wycenę
  • Pamiętaj, że zespół musi mieć pewne doświadczenie wspólnej pracy, aby efektywnie, precyzyjnie i wiarygodnie estymować

Źródła

Agile Extension to the BABOK® Guide. Version 2. 2017.