Co to jest szacowanie Agile?

Niezależnie od tego, czy zespół tworzy produkt, czy projekt, musimy odpowiedzieć: „Kiedy możemy go zakończyć?” lub „W jakim stopniu możemy go zrealizować do określonego czasu?” Podobnie jak w tradycyjnych modelach rozwojowych, przed rozpoczęciem projektu musimy oszacować obciążenie pracy.

Szacowanie Agile ma następujące trzy cechy:

Współpraca zespołu w szacowaniu

W Scrum rozwoju zespół dzieli odpowiedzialność i wspólnie pracuje nad każdym Sprint. Dlatego zespoły Agile wykorzystują techniki wspólnej oceny, aby oszacować obciążenie pracy. Współpraca w szacowaniu zwykle wykorzystuje Planning Poker jako narzędzie, w którym zespół wspólnie gra w grę szacowania. Planning Poker uznawany jest za jedną z najefektywniejszych i najbardziej angażujących technik szacowania wysiłku w Agile rozwoju. Składa się z zestawu liczb podobnych do ciągu Fibonacciego: 0, 0,5, 1, 2, 3, 5, 8, 20, 40, ?, ∞. Każdy zestaw zawiera cztery zestawy tych liczb Fibonacciego, przeznaczone do użycia przez do czterech członków zespołu.

Dokładność szacowania grupowego w porównaniu do indywidualnego

Badanie dokładności szacowania wysiłku między osobami a grupami w eksperymencie projektu oprogramowania wykazało, że 20 specjalistów ds. oprogramowania z tej samej firmy niezależnie oszacowało wysiłek potrzebny do zrealizowania tego samego projektu oprogramowania. Uczestnicy mieli różne tło i role, a projekt oprogramowania został już wcześniej zrealizowany. Później zostali podzieleni na pięć zespołów. Każdy zespół omówił i połączył swoje wiedzę, aby osiągnąć jednolite szacowanie.

Wynik: Szacunki oparte na dyskusji grupowej były dokładniejsze niż szacunki indywidualne.

Kroki gry w Planning Poker

1. Każdy członek zespołu otrzymuje zestaw kart zawierających: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞ — łącznie 12 kart.
2. Za Product Owner przeczytuje opis historii użytkownika lub funkcji zespołowi.
3. Członkowie zespołu omawiają funkcję i zadają pytania Product Owner, jeśli to konieczne.
4. Po dyskusji każdy członek wybiera kartę reprezentującą jego szacunek i odkrywa ją jednocześnie.
5. Jeśli szacunki znacznie się różnią, zespół dyskutuje: Czy się zgadzamy? Jakie czynniki zostały pominięte? Osoba z najwyższym lub najniższym szacunkiem powinna wyjaśnić swoje rozumowanie przed kolejnym głosowaniem.
6. Po dyskusji zespół może przejść przez kolejną rundę, aż osiągnie porozumienie.
7. Wróć do kroku 2 i zacznij szacować następny element listy priorytetów.

Szacowanie rozmiaru, a nie czasu — wykorzystywanie szacowania względnego zamiast bezwzględnego

Szacowanie to po prostu wybitne przypuszczenie. Wykorzystujemy całą dostępna wiedzę i doświadczenie, aby oszacować, jak długo to potrwa. Zamiast oceniać każdy nowy element pracy w izolacji, dlaczego nie porównać go z wcześniej zrealizowanymi elementami? Ludzie są lepsi w relacjach do obiektów o podobnych rozmiarach niż w zgadywaniu absolutnych rozmiarów.

Na przykład: Czy jest zbliżone do tego bardzo małego elementu? Czy bardziej podobne do tego średniego projektu? Czy naprawdę duży, jak ten, który zrealizowaliśmy w ubiegłym miesiącu? Szacowanie względne nie tylko zmniejsza czas poświęcony na szacowanie, ale znacznie poprawia dokładność.

Nasze mózgi nie są dobre w szacowaniu bezwzględnym — zawsze porównujemy nowe rzeczy, które musimy oszacować, do tego, co już znamy.

Szacowanie punktów historii

Szacowanie prędkości — zapisywanie i średnia prędkości zespołu na każdy sprint

Prędkość zespołuprędkość to liczbapunktów historii zespołu Scrumktóre faktycznie kończy w sprintie. Prędkość zespołu mówi Ci, jak szybko zespół pracuje. W przypadku nowego projektu lub zespołu (bez wcześniejszych danych o prędkości) możemy przeprowadzić 1–2 sprinty, aby zmierzyć i ustalić początkową prędkość. Podczas wykonywania sprintu zapisujemy prędkość zespołu w każdym sprintie w celu planowania przyszłych działań.

Szacowanie prędkości historii użytkownika

Szacujemy całkowitą liczbę punktów historii wkolejce produktu. Znając średnią prędkość na sprint, możemy obliczyć, ile sprintów jest potrzebnych do zakończenia projektu — a tym samym szacować jego czas trwania. Jak pokazano na rysunku poniżej.

Szacowanie czasu trwania projektu Scrum