Czym są punkty fabularne? Szacowanie nakładu pracy, a nie czasu

Punkty fabularne służą do pomiaru względnego nakładu pracy związanego z danym zadaniem (jego rozmiar, złożoność i niepewność ujęte w jednej liczbie), a nie liczby godzin, które zajmie jego wykonanie. Wielkość elementu backlogu ocenia się w odniesieniu do referencyjnej historii, którą zespół już zrealizował („ta jest mniej więcej dwa razy większa od tamtej”), zamiast zgadywać czas trwania. To właśnie ta jedna zmiana sprawia, że oszacowanie wytrzymuje konfrontację z rzeczywistością.

Dlaczego należy mierzyć nakład pracy, a nie czas?

Zespół, który szacuje nakład pracy w godzinach, w rzeczywistości stosuje dwa rodzaje szacunków: ten, w który wierzy starszy inżynier, oraz ten, który zapisuje młodszy inżynier po zaokrągleniu w górę, aby sprawiać wrażenie odpowiedzialnego. Ludzie nie są wiarygodni, gdy chodzi o odpowiedź na pytanie „ile to zajmie”, ale zaskakująco dobrze radzą sobie z pytaniem „czy to jest większe niż zadanie, które ukończyliśmy w ostatnim sprincie”. Punkty fabularne opierają się na tym drugim podejściu.

Ocena względna pozwala zespołowi uzgodnić, że jedna pozycja jest większa od drugiej, bez konieczności podawania przez nikogo konkretnej liczby godzin, co pozwala uniknąć efektu kotwicy i stronniczości wynikającej ze stażu pracy, które często towarzyszą szacunkom czasowym. Wynikająca z tego liczba nie oznacza czasu trwania zadania; jest to po prostu pozycja na wspólnej skali.

Ocena nakładu pracy zamiast liczby godzin pozwala uniknąć trzech problemów, które towarzyszą szacunkom opartym na godzinach:

• Szacunek nie stanowi zobowiązania. Podawanie liczby godzin skłania interesariuszy do traktowania „8 godzin” jako obietnicy; podawanie punktów sprawia, że szacunek pozostaje prognozą.
• Wykonanie tego samego zadania zajmuje różnym osobom różną ilość czasu. Punkt odzwierciedla wynik pracy, a nie samą osobę.
• Czas trwania nie uwzględnia ryzyka. Krótkie, ale niepewne zadanie może wiązać się z większym ryzykiem niż długie, dobrze znane zadanie, dlatego punktacja uwzględnia tę niepewność.

Skala oraz przeznaczenie punktów

Większość zespołów głosuje w oparciu o skalę typu Fibonacciego, 1, 2, 3, 5, 8, 13, w ramach rundy planowania pokerowego. Różnice między wartościami są celowo powiększane: im większy zakres prac, tym mniej wiadomo na ich temat, więc skala nie udaje już, że można odróżnić 9 od 10. Po zsumowaniu punktów uzyskanych przez zespół w każdym sprincie otrzymuje się prędkość, czyli tę wartość, którą faktycznie mają zapewnić dane wejściowe do prognozowania.

Jeśli element okaże się większy niż około 13, zazwyczaj oznacza to, że skala sugeruje, aby podzielić go na części, które zespół będzie w stanie zrozumieć i zrealizować w ramach jednego sprintu.

Aby przeprowadzić szybszą, mniej szczegółową pierwszą ocenę, niektóre zespoły klasyfikują cały backlog według rozmiarów koszulek i dopiero po doprecyzowaniu zadania przeliczają na punkty wyłącznie te zadania, które mają zostać zrealizowane w najbliższym czasie.

W rundzie planowania pokerowego wszyscy ujawniają swoje karty w tym samym momencie, dzięki czemu nikt nie kieruje się opinią osoby o najgłośniejszym głosie lub zajmującej najwyższe stanowisko. W przypadku rozbieżności między szacunkami wysokimi a niskimi dwie osoby przedstawiają swoje uzasadnienia, a ta rozmowa – która ujawnia założenia i ukrytą złożoność stojącą za daną liczbą – jest zazwyczaj cenniejsza niż sama liczba. Pełny przewodnik po planowaniu pokerowym omawia zasady tej metody.

Najpoważniejszym czynnikiem prowadzącym do niepowodzenia jest sytuacja, w której zespół zaczyna przeliczanie punktów z powrotem na godziny. W momencie, gdy tabela przeliczeniowa trafia na wiki, każda rozmowa dotycząca szacowania czasu zamienia się w spór o czas trwania, a kwestia względnego nakładu pracy schodzi na dalszy plan.

Na które dzieło należy zwrócić uwagę?

Podczas każdego spotkania poświęconego dopracowywaniu projektu pojawiają się dwa pytania: czy to w ogóle daje punkty, a jeśli tak, to ile. Skala służy właśnie do określenia odpowiedzi na pytanie „ile”. W przypadku pytania „czy to daje punkty” obowiązuje praktyczna zasada: należy przyznawać punkty za wszystko, co zespół dostarcza w ramach zobowiązanej pracy, tak aby wskaźnik prędkości odzwierciedlał rzeczywiste wykorzystanie zdolności produkcyjnej.

Błędy

Błąd o znanej przyczynie i jasnym sposobie naprawy stanowi zadanie. Posiada on kryteria akceptacji („formularz nie akceptuje już wartości ujemnych”), określony zakres oraz rozsądną wielkość, dlatego należy go oceniać tak samo jak każde inne zadanie. Prace nad błędami i prace nad nowymi funkcjami konkurują o tę samą wydajność, co powinno znaleźć odzwierciedlenie w wskaźniku prędkości.

Wyjątkiem jest błąd, którego charakter można opisać jako „nie wiemy jeszcze, co się tam kryje”: zbadanie uszkodzenia danych, ustalenie, dlaczego wartość p99 podwoiła się, klienci wciąż zgłaszają ten problem, a nam nie udaje się go odtworzyć. Nie można oszacować nakładu pracy związanego z naprawą, ponieważ przyczyna nie jest znana, więc głosowanie nad punktami fabularnymi mierzy jedynie to, co zespół ma nadzieję odkryć. Należy umieścić te zadania na ścieżce dochodzeniowej z określonym limitem czasowym: poświęćcie dzień lub dwa na poszukiwania, a następnie przedstawcie konkretne zgłoszenie dotyczące tego, co udało się ustalić.

Testowanie i zapewnienie jakości

Punkty fabularne służą do oszacowania zakresu prac od momentu „włączenia zadania do sprintu” do momentu, gdy „zadanie jest gotowe do wydania”, co obejmuje wszelkie działania związane z zapewnieniem jakości, które zespół wykonuje w ramach definicji „zakończone”: testy automatyczne, weryfikację ręczną, kontrole dostępności oraz przegląd bezpieczeństwa. Zadanie nie jest uznane za ukończone w momencie scalenia pull requestu; uznaje się je za ukończone dopiero wtedy, gdy spełnia definicję ukończenia.

Zespoły, które skupiają się wyłącznie na pracach programistycznych, a testy jakości dodają osobno, przejmują się zbyt wieloma zobowiązaniami w każdym sprincie, ponieważ testy jakości stanowią wąskie gardło, którego nikt nie uwzględnił w planowaniu. Jeśli za testy odpowiada oddzielny zespół ds. kontroli jakości, zadanie nadal wiąże się z kosztami po stronie programistów związanymi ze współpracą z tym zespołem: przygotowaniem kompilacji, sporządzeniem planu testów oraz udzielaniem odpowiedzi na pytania. Ta część nie jest bezpłatna, więc pozostaje uwzględniona w szacunku.

Dlaczego rzadko warto tworzyć artykuły oparte na jednym punkcie

Punkty mają charakter względny, więc ocena „1” ma sens jedynie w zestawieniu z ocenami „2”, „3” czy „8”. Gdy w zespole pojawia się ciągła seria wydarzeń ocenianych na „1”, ta skala znika: wszystko, co nieznaczne, otrzymuje ocenę „1”, wszystko, co większe – „2” lub „3”, a cała skala sprowadza się do rzutu monetą.

Rozwiązaniem nie jest zakazanie wartości „1” (to właśnie ta „wersja kultu cargo” tej zasady). Należy raczej zadać pytanie, dlaczego tak wiele zadań jest klasyfikowanych w dolnej części skali. Zazwyczaj odniesienie do historii uległo zmianie: zespół przyspieszył tempo pracy, a pierwotna „1” jest obecnie mniejsza niż cokolwiek, co obecnie dostarczają, dlatego należy wybrać nowsze odniesienie, które zespół pamięta, i ponownie ustalić punkt odniesienia. Czasami zespół nadmiernie rozbija zadania podczas dopracowywania, wyodrębniając każde kryterium akceptacji jako osobną historię: „aktualizacja tekstu przycisku” nie jest historią, lecz kryterium akceptacji w ramach większego zadania. Czasami natomiast zadanie jest rzeczywiście niewielkie (kwartalna konserwacja, zmiana treści wymagająca weryfikacji prawnej, drobna modyfikacja konfiguracji mająca wpływ na środowisko produkcyjne) – w takim przypadku punkty spełniają swoją rolę i nie ma potrzeby wprowadzania żadnych zmian.

Sygnałem, na który należy zwrócić uwagę, nie jest to, że „nigdy nie ma zadań o priorytecie 1”. Chodzi o to, że zadania o priorytecie 1 stanowią większość zaległości. Jedno lub dwa takie zadania na sprint to nic złego. Jeśli co drugie zgłoszenie ma priorytet 1, oznacza to, że od zbyt dawna nie poruszono kwestii kalibracji.

Punkty fabularne i retrospektywa

Szacowanie jest jednym z najczęstszych elementów analizowanych przez zespół podczas retrospektywy sprintu. Gdy zadania są rutynowo szacowane zbyt nisko lub zbyt wysoko, gdy prędkość pracy ulega gwałtownym wahaniom lub gdy zadania oznaczone jako „zakończone” są ponownie otwierane, retrospektywa stanowi okazję dla zespołu do ponownego skalibrowania wspólnego wyczucia wielkości zadań oraz doprecyzowania sposobu ich podziału. Dokładność szacowania poprawia się dzięki tej pętli informacji zwrotnej, a nie poprzez większy wysiłek na samym początku.

Najczęściej zadawane pytania

Czym są punkty fabularne w metodologii agile?

Punkty fabularne stanowią jednostkę względnej oceny: jest to liczba odzwierciedlająca wielkość danego zadania (łącząca nakład pracy, złożoność i niepewność) w porównaniu z referencyjną historią, którą zespół już zrealizował. Celowo nie są one miarą czasu. Zespół ocenia wielkość każdego zadania w odniesieniu do pozostałych zadań, a nie w odniesieniu do czasu.

Dlaczego warto stosować punkty fabularne zamiast godzin?

Ludzie mają trudności z oszacowaniem czasu bezwzględnego, ale dobrze radzą sobie z oceną, czy jedna rzecz jest większa od drugiej, a punkty fabularne wykorzystują tę zaletę. Pozwalają one również uniknąć pułapki traktowania szacunku jako zobowiązania, uwzględniają fakt, że wykonanie tego samego zadania zajmuje różnym osobom różną ilość czasu, a także uwzględniają złożoność i ryzyko, a nie tylko czas trwania. W ciągu kilku sprintów prędkość zespołu wyrażona w punktach staje się bardziej wiarygodną prognozą niż suma szacunków godzinowych.

W jaki sposób szacują Państwo punkty fabularne?

Większość zespołów korzysta z metody „planning poker”. Ktoś przedstawia pozycję z listy zadań do realizacji, zespół omawia ją, a następnie każdy z członków zespołu indywidualnie wybiera wartość z wspólnej skali, zazwyczaj opartej na ciągu Fibonacciego (1, 2, 3, 5, 8, 13). Wszyscy ujawniają swoje oceny jednocześnie; w przypadku znacznych rozbieżności w szacunkach osoby, które podały najwyższą i najniższą wartość, wyjaśniają swoje rozumowanie, a zespół ponownie głosuje, aż do osiągnięcia konsensusu. Dyskusja, która ujawnia ukrytą złożoność zadania, jest często cenniejsza niż sama liczba.

Czy błędy powinny być przypisane do punktów fabularnych?

Tak, gdy przyczyna błędu jest znana, a sposób jego usunięcia jasno określony: jest to zadanie jak każde inne, a jego zgłoszenie pozwala na rzetelne odzwierciedlenie w wskaźniku prędkości (velocity), na co przeznaczane są zasoby. Wyjątkiem są błędy o charakterze eksploracyjnym, których zakresu nie da się jeszcze określić; należy je umieścić w ścieżce badawczej z ustalonym limitem czasowym, a rzeczywisty zakres poprawki oszacować dopiero po ustaleniu przyczyny.

Czy punkty fabularne obejmują testowanie?

Tak. Punkty określają wszystkie etapy od momentu włączenia zadania do sprintu aż do momentu, gdy można je dostarczyć, co obejmuje również testowanie i kontrolę jakości przeprowadzane przez zespół w ramach jego definicji zakończenia zadania. Jeśli przypisuje się punkty wyłącznie za prace programistyczne, sprint za każdym razem się przedłuża, ponieważ kontrola jakości stanowi wąskie gardło, którego nikt nie uwzględnił.

Dlaczego warto unikać artykułów opartych na jednym punkcie?

Kilka takich przypadków nie stanowi problemu. Jeśli jednak większość zaległości to zadania o wartości 1, oznacza to, że punkt odniesienia zespołu uległ odchyleniu, a skala uległa załamaniu, przez co wszystkie zadania wydają się być albo bardzo małe, albo bardzo duże. Należy ponownie skalibrować skalę w oparciu o aktualny punkt odniesienia, zamiast ją zmniejszać.

Czy można porównać liczbę punktów fabularnych między zespołami?

Nie. Punkt fabularny jest dostosowany do własnej oceny względnej wielkości danego zespołu, więc „5” w jednym zespole nie oznacza tego samego co „5” w innym. Porównywanie prędkości lub łącznej liczby punktów między zespołami jest bezsensowne, a wykorzystywanie tych wartości jako celów jest wręcz szkodliwe: skłania zespoły do zawyżania szacunków. Punkty fabularne stanowią narzędzie planowania służące do prognozowania w ramach jednego zespołu, a nie wskaźnik produktywności przeznaczony do porównań.

Materiały powiązane

• Dlaczego w punktach fabularnych stosuje się ciąg Fibonacciego: dlaczego różnice między kolejnymi liczbami powiększają się wraz ze wzrostem ich wartości.
• Punkty fabularne a godziny: pułapka związana z przeliczaniem oraz co zrobić, gdy ktoś potrzebuje podać konkretną datę.
• Velocity: przekształcanie punktów zwrotnych w prognozę bez ich naruszania.
• Techniki szacowania w metodologii agile: kiedy zastosować daną metodę oraz jakie są jej ograniczenia.
• Retrospektywa sprintu: podczas której zespoły korygują szacunki, które ciągle okazują się niedokładne.
• Przewodnik po szacowaniu metodą agile: kompletny zestaw narzędzi, od pokera planistycznego po dzielenie opowieści.
• Bezpłatny Planning Poker dla zespołów stosujących metodologię agile: wspólnie określajcie wielkość zaległości w czasie rzeczywistym.