Story points, czy dni idealne?

Dwie popularne metody estymowania projektów IT to estymata w story points i estymata w dniach idealnych. Jest oczywiście wiele innych metod estymaty, ale w tym artykule chciałabym krótko porównać ze sobą te dwie metody, ponieważ wydają mi się najczęściej wykorzystywanymi do estymowania projektów w branży IT. 

Story points

Jest to estymata, której podstawową jednostką jest punkt, przy czym punkt nie odnosi się w żaden sposób do czasu, ale do rozmiaru danego zadania, jest miarą względną. Ten element czasem sprawia problem deweloperom przyzwyczajonym do estymowania w jednostkach czasu. Często słyszałam pytanie: czy można przyjąć, że 8 punktów to jeden dzień? Absolutnie nie. Estymujemy, jak duże jest to zadanie, a nie jak czasochłonne. Do estymowania z użyciem story points można wykorzystać dowolny ciąg wartości liczbowych, przy czym najczęściej wykorzystuje się ciąg Fibonacciego, czyli liczby: 1,2,3,5,8,13, etc. 

Dni idealne

Jest to jednostka opisująca, ile czasu idealnego potrzebujemy, by zrealizować daną funkcjonalność. Czas idealny rozumiemy jako czas, w którym pracujemy z pełną wydajnością i nic ani nikt nas nie rozprasza. Jeśli posługujemy się miarą dnia idealnego zawsze musi być przeliczony na dzień rzeczywisty, ponieważ są to dwie różne wartości. Nikt nie jest w stanie pracować wydajnie i produktywnie całe 8h każdego roboczodnia. Badania pokazują, że jest to maksymalnie 6h z 8h i na tę wartość wpływa wiele czynników środowiskowych.

Jak lepiej zrozumieć czym jest estymata w story points, a czym w dniach idealnych?

Wyobraź sobie, że masz do przebiegnięcia maraton. Wiesz, że jest to nieco ponad 42 km. Ta wielkość jest taka sama dla wszystkich uczestników. Czy taki sam będzie czas przebiegnięcia go dla wszystkich? Oczywiste jest, że nie. Możesz być bardzo dobrym i doświadczonym maratończykiem i przebiec ten dystans w czasie nieco ponad 2 godziny, ale możesz być też bardzo początkującym biegaczem i będziesz potrzebować na to 7 godzin. Story points są tak jak km w maratonie – pozwalają znaleźć ten sam punkt odniesienia wszystkim członkom zespołu. Spróbujmy zatem westymować maraton, z użyciem story points i czasu idealnego. Nasze user stories brzmi: Jako biegacz, chcę przebiec maraton.

Estymata na podstawie czasu potrzebnego na wykonanie zadania:

Ile czasu zajmie Ci przebiegnięcie maratonu?

• Doświadczony biegacz (deweloper – ekspert): 2:20 minut
• Początkujący biegacz (junior, początkujący programista): 6h:40 minut

Estymata na podstawie rozmiaru zadania:

Jakiego rozmiaru jest to zadanie?

• Doświadczony biegacz (deweloper – ekspert): nieco ponad 42 km
• Początkujący biegacz (junior, początkujący programista): około 42 km

Zobacz, co się stanie, jeśli o poprosisz o estymatę w czasie eksperta, a zadanie będzie realizował junior. Co jeśli, będzie on realizował większość zadań w projekcie estymowanym w jednostce czasu przez eksperta? Jak bardzo estymata, którą wykonałeś będzie wówczas dokładna? 

Symulacja estymaty w story points i dniach idealnych

Dodajmy kolejne cząstki do naszego torciku estymaty. 

Mamy do wyestymowania następującą kolekcję user stories:

• US 1: Jako biegacz, chcę przebiec sprint. 
• US 2: Jako biegacz, chcę przebiec półmaraton. 
• US 3: Jako biegacz, chcę przebiec maraton. 
• US 4: Jako biegacz, chcę przebiec ultramaraton.

W trakcie dyskusji nad user stories zespół doprecyzował zakres user stories i wie, jaki konkretnie sprint chce przebiec klient i który ultramaraton. 

Estymata w story points

1. Mamy wyestymowany już maraton i wiemy, że zajmie on 42 000 punktów.
2. Wiemy, że półmaraton ma rozmiar o połowę mniejszy od maratonu, zatem łatwo szacujemy, że ma on 21 000 punktów
3. O ultramaratonie wiemy, że ma to być maksymalny dystans Chudego Wawrzyńca zatem ma on rozmiar mniej więcej 2 razy większy niż maraton – dajemy mu 82 000 punktów. 
4. Sprint przy pozostałych biegach, wydaje się czymś drobnym – dajemy mu zatem 100 punktów. 

Mamy oszacowane rozmiary biegów (= funkcjonalności w perspektywie programowania). Zrobiliśmy to szybko, metodą porównania rozmiarów tych biegów (funkcjonalności).

Możemy wykorzystać do tego technikę zwaną planning pokerem. Polega ona na tym, że każdy z członków zespołu estymującego projekt dysponuje zestawem kart o określonych wartościach liczbowych (takich, w których estymujemy user stories). Każdy z członków zespołu wykłada jedną kartę w czasie estymowania danej user stories. Jeśli wartości się nie zgadzają, rozpoczyna się dyskusja, która może wyjaśnić, dlaczego ktoś dał wyższą lub niższą wartość. Może się okazać, że np. istnieje jakaś bilblioteka, która znacznie ułatwia implementację tej funkcjonalności, albo może się okazać, że zaimplementowanie jej jest proste, ale przetestowanie już nie, ponieważ wymaga pokrycia wielu scenariuszy (np. jeśli chodzi o wyszukiwarkę). Po dyskusji, członkowie zespołu reestymują funkcjonalność. Jeśli są zgodni, przechodzą do kolejnej user stories, jeśli nie, powtarzają dyskusję i estymatę.  Podstawą gry w planistycznego pokera jest właśnie grupowa dyskusja, a ta, jak pokazują badania Jørgensena i Moløkkena z 2002 roku pomogą w uzyskaniu lepszej estymaty. 

Oczywiście warunki estymowania się nie zmieniają. Nadal nie znamy wszystkich okoliczności, które mogą wpłynąć na ten bieg: jak np. pogody w dniu biegu, naszego samopoczucia, formy itp. Nie zmienia to jednak faktu, że półmaraton jest o połowę mniejszym biegiem niż maraton. 

Estymata w dniach idealnych

Zobaczmy teraz, jak wyglądałaby estymata tego projektu za pomocą jednostki czasu, wykonana przez deweloperów o różnym poziomie doświadczenia:

User stories	Developer ekspert	Developer junior
US1	0,18 min	0,25 min
US2	65 min	80 min
US 3	140 min	400 min
US 4	540 min	960 min
RAZEM	745,18 min/(8*60 min) = 1,6 dni	1 440,25 min/(8*60 min) = 3 dni

Co zrobić z taką estymatą? Którą wartość wybrać? A może uśrednić? Czy jeśli przyjmiemy estymatę junior developera, a projekt będzie realizowany przez seniora, to zadziała prawo Parkinsona? Czy jeśli przyjmiemy estymatę seniora, a projekt będzie realizował junior, to przekroczymy estymatę o 100%? Czyha tutaj sporo zagrożeń. Nie bez znaczenia jest również fakt, że estymata wyrażona w jednostce czasowej jest bardziej czasochłonna, niż kiedy porównujemy ze sobą rozmiary funkcjonalności.

Mam nadzieję, że przykład maratonu pozwala lepiej zrozumieć, czym jest estymata w story points, a czym estymata w dniach idealnych. Oczywiście, jest to pewnego rodzaju uproszczenie. 

Podsumowując

Estymata w dniach idealnych jest pozornie łatwiejsza na początku i łatwiej ją przedłożyć interesariuszom – w końcu każdy rozumie pojęcie dnia. Jednak na tym chyba kończą się jej zalety. 

Estymata w story points, pozwala wszystkim znaleźć wspólny punkt odniesienia, jest dużo szybsza do wykonania i jak pokazują badania, jej dokładność jest również większa. 

Z mojego doświadczenia wynika jeszcze jedna ciekawa zaleta takiego estymowania. Programiści, podkreślają, że estymata w story points uwalnia ich od presji dowiezienia czego w konkretnym terminie, bo uwaga jest przekierowana z jak długo, na jak trudno.  A jak wiadomo, nic tak destrukcyjnie nie działa na efektywność, jak presja. 

O tym, co dalej zrobić z estymatą w story points będzie można przeczytać w kolejnych wpisach.