Zwinne techniki szacowania w Agile
“Osoba, która twierdzi, że jest w stanie oszacować wpływ niezliczonych decyzji [dotyczących projektu i projektowania] na samym początku, albo jest prorokiem, albo słabo się zna na rzeczywistej naturze rozwoju oprogramowania”[1]
Oszacowanie dotyczyć może wielkości produktu, wymagania lub nakładu pracy na jego dostarczenie. W skrócie, jest to pewna prognoza kosztów, nakładów pracy i czasu potrzebnych do zrealizowania konkretnego celu. Aby poprawić dokładność oszacowań warto sięgnąć po różne techniki szacowania oraz zaprosić do tego więcej osób – najlepiej takich, które daną pracę będą wykonywać.
Najpowszechniejszymi stylami szacowania jest tzw. “szacowanie z góry” (szacowanie przez analogię) oraz “szacowanie z dołu” (szacowanie przez dekompozycję).
Szacowanie z góry
To styl szacowania, wykorzystujący ustalanie przybliżonej wielkości i grupowanie. W celu oszacowania wielkości produktu wykorzystuje się jego widzialne cechy. Opiera się na wiedzy i umiejętnościach szacującej osoby, która już wcześniej robiła coś podobnego (analogia).
-
Szacowanie T-shirt
W tej technice wszystkim wymaganiom nadaje się rozmiary takie jak rozmiarówki T-shirtów: S (small), M (medium), L (large), XL (eXtra Large). Technika ta uważana jest za szybką i stosunkowo łatwą technikę szacowania w sytuacjach, gdy o szacowanym przedmiocie niewiele wiadomo.
-
Szacowanie punktów historyjkowych
Ta technika, znana też jako szerokopasmowa technika delficka (“wind band Delphi”), do nadawania relatywnego rozmiaru wymaganiom (historyjkom) wykorzystuje dyskusje grupowe. Należy do bardziej wymagających i czasochłonnych technik, ale dzięki temu przynosi bardziej precyzyjne efekty.
Do odmian tej techniki należy gra Planning Poker.
-
Szacowanie przez Tempo
Szacowanie przez Tempo zazwyczaj stosowane jest wraz z punktami historyjkowymi. Tempo opiera się na dotychczasowej wydajności zespołu, określanej w formie punktów historyjkowych, jakich zespół może dostarczyć w ciągu jednego Timeboxa.
Tak określona wydajność wykorzystywana jest do prognozowania oczekiwań na przyszłość. Każdy zespół ma swoje indywidualne Tempo, w przypadku zmiany składu osobowego zespołu tempo należy obliczyć ponownie. Jeśli Tempo zespołu nie jest znane to również ono wymaga oszacowania.
-
Szacowanie przez Przykład
Stosowane jest przy szacowaniu “T-shirt”, ale przydaje się też przy szacowania Punktów Historyjkowych, w przypadku nieznanego Tempa. Zespół opracowuje 2 lub 3 historyjki, grupuje je i dzieli na czynności, a następnie szacuje. Dalej, zadania się sumuje i kojarzy konkretną historyjkę (wymaganie) ze spodziewanym nakładem pracy. Po oszacowaniu wszystkich historyjek zespół oblicza średnią jako przykład nakładu pracy i czasu dla danego rozmiaru wymagania.
Szacowanie z dołu
Uważane jest za najdokładniejszy sposób szacowania, ze względu na to, że każde zadanie lub produkt szacuje się osobno. Jego wyniki mogą być odmienne od wyników szacowania z góry. Stosując jednak zalecenia stosowania więcej niż jednej techniki nie powinno to stanowić problemu, gdyż jeden styl będzie walidować drugi.
Szacowanie z dołu polega na podzieleniu komponentów na pojedyncze elementy (zadania, produkty) i oszacowanie nakładu pracy dla każdego z nich. Następnie sumuje się nakłady pracy wszystkich elementów.
Szacowanie z dołu jest czasochłonne i wymaga dobrego zrozumienia celu, który mamy do zrealizowania. Tym samym jest to dość kosztowny styl szacowania, co stanowi poważny minus, tym bardziej, że wstępne szacowania opierają się na wielu założeniach i końcowy wynik może okazać się nieprecyzyjny.
Wybór stylu szacowania w dużej mierze zależy od fazy cyklu życia, w którym znajduje się projekt. Szacowanie z góry wykorzystywane jest w początkowych fazach projektu (Wykonalność i Podstawy), a szacowanie z dołu w późniejszych fazach projektu (Rozwój Ewolucyjny – podczas Planowania Timeboxa).
Szacowanie jest niezmiernie ważnym elementem pracy projektowej. Im dokładniejsze oszacowanie tym lepiej i łatwiej przebiega dalsza praca. Więcej o technikach szacowania dowiesz się na szkoleniu AgilePM Practitioner. Przeczytaj więcej o kursach AgilePM.
Źródła:
- AgilePM Handbook
- S. McConnell, Software Project Survival Guide
[1] Steve McConnell – Software Project Survival Guide