Punkty fabularne służą do pomiaru względnego nakładu pracy związanego z danym zadaniem — jego wielkości, złożoności i niepewności ujętych w jedną liczbę — 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 sprawdza się w praktyce.

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ę właśnie 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.

Skala oraz przeznaczenie poszczególnych punktów

Większość zespołów ocenia zadania w skali typu Fibonacciego — 1, 2, 3, 5, 8, 13 — podczas rundy planowania pokerowego. Różnice między wartościami są celowo powiększane: im większy zakres pracy, tym mniej wiadomo na jej 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 właśnie tę wartość, do której obliczenia prognoz mają faktycznie prowadzić.

Najpoważniejszym czynnikiem prowadzącym do niepowodzenia jest sytuacja, w której zespół zaczyna przeliczać punkty 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”. Jeśli chodzi o pytanie „czy to daje punkty”, obowiązuje praktyczna zasada — należy przyznawać punkty za wszystko, co zespół dostarcza w ramach pracy, do której się zobowiązał, tak aby wskaźnik prędkości odzwierciedlał rzeczywiste wykorzystanie zdolności produkcyjnej.

Błędy

Błąd o znanej przyczynie i jasnym rozwiązaniu stanowi zadanie. Posiada on kryteria akceptacji („formularz nie akceptuje już wartości ujemnych”), określony zakres oraz rozsądną wielkość — proszę więc głosować na to zadanie tak samo, jak na każde inne. 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” — zbadaj uszkodzenie danych, ustal, 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 w ś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 określają zakres prac wykonywanych 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 testowanie odpowiada odrębny zespół ds. kontroli jakości, zadanie nadal wiąże się z kosztami po stronie programistów wynikającymi ze współpracy 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 drużynie nieustannie pojawiają się sytuacje warte tylko 1 punkt, ta skala znika — wszystko, co nieznaczne, to „1”, wszystko, co większe, to „2” lub „3”, a cała skala sprowadza się do rzutu monetą.

Rozwiązaniem nie jest zakazanie wartości „1” — to tylko powierzchowna interpretacja tej zasady. Należy raczej zadać pytanie, dlaczego tak wiele zadań ma tak niską wartość. Zazwyczaj historia odniesienia uległa zmianie: zespół przyspieszył tempo pracy, a pierwotna „1” jest obecnie mniejsza niż cokolwiek, co obecnie dostarczają, więc należy wybrać nowszą historię odniesienia, którą 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 (kwartalne prace konserwacyjne, 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 zadano pytania dotyczące kalibracji.

Najczęściej zadawane pytania

Czym są punkty fabularne w metodologii agile?

Punkty fabularne stanowią jednostkę względnej oceny: jest to liczba, która odzwierciedla wielkość danego zadania — uwzględniając jednocześnie 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.

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

Tak, gdy błąd ma znaną przyczynę i jasno określone rozwiązanie — jest to zadanie jak każde inne, a jego zgłoszenie pozwala na rzetelne oszacowanie, na co przeznaczane są zasoby w ramach wskaźnika velocity. Wyjątkiem są błędy o charakterze eksploracyjnym, których zakresu nie da się jeszcze określić; należy je umieścić na ś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 wydać, 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, to punkt odniesienia zespołu uległ odchyleniu, a skala przestała mieć sens — 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ć.

Warto przeczytać