Szacowanie Agile: Szacunki względne vs Szacunki absolutne

Czym jest szacowanie projektu?

Szacunek to przybliżone obliczenie czegoś. Na przykład, oszacowanie kosztów projektu to ogólna koncepcja modelu cenowego projektu. Pomaga ono przedstawić – miejmy nadzieję, bardziej realistyczną – wartość, gdy klienci lub inni interesariusze projektu proszą o ocenę kosztów i czasu wykonania projektu.

Szacowanie Agile vs. tradycyjne

Tradycyjnie przeznaczamy czas na szacowanie projektów programistycznych, podczas gdy w metodach agile preferuje się przypisywanie punktu historyjek (story point) do elementu backlogu jako miary względnego nakładu pracy. Pozwala to zespołowi porównać zrealizowane wcześniej zadania z obecnym elementem backlogu, który ma być oszacowany. Punkty historyjek nie wyrażają się w określonym czasie, lecz odzwierciedlają pracochłonność wymaganą do rozwiązania podobnych zadań na podstawie wcześniejszych doświadczeń.

Szacowanie agile charakteryzuje się trzema cechami:

1. Kolektywne szacowanie zespołu
2. Względny nakład pracy vs. szacowanie w czasie absolutnym
3. Szacowanie prędkości zespołu

1. Szacowanie kolektywne

Podczas wdrażania Scrum zespół dzielił odpowiedzialność i wspólnie zobowiązywał się do wykonania pracy w każdym Sprincie, dlatego przy szacowaniu nakładu pracy dla zespołu agile stosowano podejście kolektywne. Kolektywne szacunki zazwyczaj wykorzystują Planning poker jako narzędzie – zespół dokonuje wspólnego oszacowania, grając w grę szacunkową. Planning poker jest uważany za jedną z najskuteczniejszych i najciekawszych technik szacowania nakładu pracy w Agile. Zestaw kart zawiera liczby podobne do ciągu Fibonacciego, w tym: 0, 0.5, 1, 2, 3, 5, 8, 20, 40, ?, ∞; każda talia kart ma 4 grupy takich liczb, dedykowane dla 4 osób.

Dokładność szacowania grupowego vs. indywidualnego

Według pewnego badania dotyczącego dokładności szacowania nakładu pracy – porównano oszacowania indywidualne i grupowe w eksperymencie na projekcie programistycznym. 20 specjalistów IT z tej samej firmy indywidualnie oszacowało nakład pracy niezbędny do realizacji tego samego projektu programistycznego. Uczestnicy mieli różne doświadczenia i role, a projekt programistyczny był wcześniej wdrożony. Następnie utworzono pięć grup. Każda grupa, dyskutując i łącząc wiedzę swoich członków, ustaliła jedną wspólną ocenę.

Wynik – Szacunki oparte na dyskusjach grupowych były dokładniejsze od szacunków indywidualnych.

Kroki przeprowadzania Planning Poker

1. Każdy członek zespołu otrzymuje zestaw kart: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞, w sumie 12 kart.
2. Właściciel produktu opisuje daną funkcjonalność zespołowi.
3. Członkowie zespołu dyskutują nad funkcjonalnością i, jeśli to konieczne, zadają pytania właścicielowi produktu.
4. Po zakończeniu dyskusji każdy z członków wybiera jedną kartę pokerową, która reprezentuje jego szacunek. Następnie wszystkie karty są ujawniane jednocześnie.
5. Jeśli zespół ocenił inaczej szacunki, należy zapytać: Czy się zgadzamy? Czy mamy różnice? Czy coś zostało pominięte? Ci, którzy wybrali najwyższą lub najniższą wartość, powinni podzielić się swoimi argumentami z grupą, zanim każdy wybierze kolejną kartę.
6. Po dyskusji można przeprowadzić kolejną rundę szacowania, a zespół powinien dojść do porozumienia.
7. Następnie wróć do drugiego kroku i rozpocznij szacowanie kolejnego elementu.

2. Szacowanie względnego nakładu pracy vs. szacowanie w czasie absolutnym

Szacunek nie jest niczym więcej jak dobrze uzasadnionym przypuszczeniem. Wykorzystujemy całą dostępną wiedzę i doświadczenie, aby zgadnąć, ile czasu zajmie dana praca. Zamiast patrzeć na każdy nowy element pracy osobno, lepiej porównać go z wcześniej wykonanymi zadaniami. Dla ludzi łatwiej jest odnosić nowe zadanie do podobnych, już znanych, niż próbować oszacować rzeczywisty rozmiar zadania.

Na przykład, czy przypomina to naprawdę mały element? A może bardziej odpowiada temu standardowemu przedmiotowi? Czy może jest naprawdę ogromny, podobnie jak zadanie, które ukończyliśmy w zeszłym miesiącu? Szacowanie względne nie tylko skraca czas przeznaczony na estymację, ale również znacznie zwiększa dokładność szacunków.

Nasz mózg nie radzi sobie z dokonaniem szacunków absolutnych; zawsze porównujemy nowe zadanie do rzeczy, które już znamy.

3. Szacowanie prędkości – rejestracja i uśrednienie szybkości zespołu w każdym Sprincie

Prędkość zespołu, czyli velocity, to liczba punktów historyjek, które zespół Scrumowy faktycznie realizuje w Sprincie. Prędkość zespołu mówi, jak szybko zespół realizuje zadania. W przypadku nowo szacowanego projektu lub zespołu (bez odniesienia do wcześniejszych wyników prędkości) można wykonać 1–2 Sprinty w celu ustalenia początkowej prędkości. W trakcie realizacji Sprintu należy rejestrować prędkość każdego z nich, z myślą o przyszłych planach.

Szacujemy łączną liczbę punktów historyjek dla backlogu produktu, a następnie, znając średnią prędkość poszczególnych Sprintów, możemy obliczyć, ile Sprintów potrzeba na zakończenie projektu, co przedstawiono na poniższym rysunku.