Opóźnienie realizacji projektu informatycznego to niestety dla programistów i Project Managerów rzecz, z którą czasami przychodzi im się zmagać. Z czego wynika błędna estymacja potrzebnego czasu i w jaki sposób, pracując w Scrumie, ale również poza nim, można uniknąć nieprawidłowej wyceny stosując metodę story points?
Typowa, stosowana w większości zespołów developerskich metoda wyceny czasu realizacji projektu opiera się najczęściej o szacunek czasowy (np. roboczodni). Efektem tego planowania jest (praktycznie zawsze) przekroczenie zakładanej ilości czasu na realizacje (głównie ze względu na zbyt optymistyczną ocenę efektywności pracy i stopnia złożoności zadania). Czyli upraszczając – zespołowi wydaje się, że skończy szybciej. Błędnie oszacowany czas to również wyższe koszty realizacji projektu – zatem przekroczone budżety.
Story points
Metoda story points, stosowana w Scrumie, umożliwia takie oszacowanie ilości potrzebnej pracy, by estymacja została dokonana prawidłowo. Pozwala również, uniknąć sytuacji, w której okazuje się, że pierwotne założenia zaczynają zupełnie nie przystawać do rzeczywistości, a cała estymacja ulega inflacji. Mówiąc wprost – szacunki zaczynają odbiegać od realiów. Jak to działa?
Na czym polega estymacja zadań w scrumie metodą story points?
Aby zrozumieć metodykę estymacji story points, trzeba wyjaśnić kilka pojęć. W każdym projekcie informatycznym podstawą jest stworzenie listy zadań (itemów) do wykonania (product backlog). Realizacja każdego itemu, wymaga czasu oraz wysiłku programisty/ów i reszty zespołu. Ten pierwszy zależy od skomplikowania zadania, jego złożoności, kompleksowości itd. Aby można było estymować zadanie, tworzy się abstrakcyjną jednostkę – tzw. story points, która reprezentuje abstrakcyjną porcję pracy. Suma story points daje nam obraz całości pracy, jaka musi zostać włożona w projekt, by mógł on zostać zrealizowany.
Każdemu itemowi przypisuje się konkretną liczbę story points, przy czym wartości możliwe do przypisania są ograniczone ciągiem Fibonacciego (zaokrąglonych przy wyższych wartościach do pełnych dziesiątek – 0.5, 1, 2, 3, 5, 13, 20, 40, 100). Zaokrąglenia pokazują, że jest to szacowanie, a nie konkretna wartość i pozwalają unikać ewentualnych inflacji punktów. Dzieje się tak, ponieważ przy konkretnych wartościach zespół mógłby na przykład spierać się przez godzinę o to, czy zadanie ma 23 czy 24 punkty.
Dlaczego story points są lepsze niż po prostu szacowanie czasowe?
Po pierwsze dlatego, że dzięki swojej abstrakcyjnej naturze pozwalają unikać niedoszacowania wynikającego z optymistycznej oceny czasu (łatwiej powiedzieć, że dany item będzie kosztował 10 punktów niż 6 godzin pracy). Ponadto bierze pod uwagę złożoność zadania, a tym samym uwzględnia to, że przykładowo zadanie, do którego potrzebny jest relatywnie krótki kod, wymaga skomplikowanego procesu myślowego lub jest wysoce wyczerpujące.
Jak wygląda estymacja metodą story points w praktyce?
- Spotkanie całego zespołu
- Omówienie user story i jej szczegółów.
- Estymacja indywidualna, podczas której każdy dokonuje szacunku, ale go nie ujawnia.
- Po tym, jak każdy członek zespołu ustalił wartość, następuje jej kolektywne ujawnienie (wszyscy na raz odsłaniają wartość).
- Jeśli między członkami zespołu istnieje zgoda, user story otrzymuje określoną liczbę punktów. Jeśli nie – zespół negocjuje i wraca do punktu 3.
Badanie efektywności w metodzie story points
Metoda ta pozwala na śledzenie efektywności dzięki zliczaniu i sumowaniu story points przy iteracji itemów. Aby monitorować efektywność konieczne jest również ustawienie bramki jakości, by mieć pewność czy efektywność nie rośnie kosztem większej ilości błędów. Często na początku wdrażania systemu story points pojawia się rozbieżność pomiędzy planowaną ilością story points w sprincie, a faktycznie ich wykonaną ilością. Z czasem zespół niejako uczy się tego, jak prawidłowo szacować ilość story points, by praca przebiegała równo i bez zakłóceń.
Co powoduje inflację punktów? (czyli zawyżoną wycenę zadań)
- Różne rozumienie story points (jako jednostki pracy) pomiędzy członkami zespołu.
- Im większe (bardziej złożone) zadanie, tym większa jest niedokładność estymacji.
- Brak brania przez zespół pod uwagę metryk oraz danych historycznych.
- Zmiana wartości story points w trakcie realizacji projektu.
- Brak śledzenia velocity, co może powodować spadek jakości i konieczność wydatkowania większej ilości story points w kolejnych sprintach.
Jakie dobre techniki stosować w trakcie estymowania, by unikać pojawiania się inflacji punktów?
- Zespół, aby estymacja projektu mogła zostać wykonana, musi uzgodnić wspólną wartość story points wśród wszystkich członków. Jeśli rozumienie jednostki będzie różne, estymacja będzie nieefektywna.
- W ustalaniu wartości itemu pomaga stworzenie zadania referencyjnego. Jest to przykład zadania, do którego odnosimy inne zadania i na tej podstawie szacujemy ich wartość punktową. Przy tworzeniu zadania referencyjnego trzeba pamiętać o tym, że musi być ono zrozumiałe i łatwe do odniesienia dla osób o różnych kompetencjach, współtworzących zespół (musi je pojąć zarówno deweloper JavaScript, bazodanowiec, jak i tester). Dobrym przykładem takiego zadania może być wdrożenie prostej zmiany na środowisko produkcyjne. Chodzi tu o niewielką zmianę, która można wdrożyć bez wcześniejszego przeprowadzania zaawansowanych tekstów. Próbujemy określić jej realną wycenę i na tej podstawie odnosimy się do innych zadań.
- Zadanie powinno być dzielone mniejsze punkty, by zredukować niedoszacowania.
- Należy kolekcjonować dane z poprzednich sprintów i wykorzystywać dane historyczne do szacowania kolejnych user story.
- Warto dbać o to, by stale stosować tę samą wartość story points w trakcie realizacji całego projektu. Odejście od tego założenia zdarza się zwłaszcza wtedy, gdy pojawiają się naciski na realizację wyższej liczby punktów w sprincie.
- Należy badać i analizować efektywność (velocity) i wyciągać z niej wnioski przy planowaniu story points dla kolejnych sprintów.
- Trzeba brać również pod uwagę planowane zakłócenia – np. urlopy pracowników.
Na koniec warto dodać, że podstawą redukcji inflacji punktów jest też pamiętanie o tym, że nie odzwierciedlają one jakiejś konkretnej wartości czasowej, lecz są reprezentacją rozkładu normalnego i jako takie, zawsze będą podlegać pewnym odchyleniom.
