Szacowanie w projektach IT – część 1

Szacowanie w projektach IT – część 1

Estymacja jest to oszacowanie przewidywanej pracochłonności lub czasochłonności wykonania zadań. Bazuje on na prawdopodobieństwie i przewidywaniu przyszłości, więc ze swojej natury jest tylko przybliżeniem rzeczywistości i rzadko kiedy estymaty idealnie trafiają w rzeczywistą wartość.

Po co estymujemy?

Estymacje są bardzo istotne w kontraktach fixed-price przy świadczeniu usług dla klienta zewnętrznego, gdzie trzeba w miarę trafnie zaplanować potrzebny czas i zasoby. Trafna estymacja pracochłonności i ryzyk jest podstawą rentowności projektu fixed-price.

W przypadku projektów dla klienta wewnętrznego często trzeba wykonać estymację na potrzeby planowania średnio i długoterminowego. Kolejną wartością dla klienta wewnęrznego jest znajomość zgrubnych kosztów realizacji, co jest często wkładem do decyzji biznesowej czy realizować w ogóle dane zadania oraz z jakimi priorytetami.

Innym pozytywnym rezultatem estymacji jest to, że samo podejście do estymacji wymaga analizy jak będzie wykonywana praca i powoduje określenie bardziej precyzyjnych kryteriów odbioru, lepsze zidentyfikowanie zależności zewnętrznych, ryzyk, wymaganych zasobów, itp.

Precyzja oszacowania

Precyzja oszacowania mówi jak blisko estymaty okazują się być zbieżne z rzeczywistą wartością zmierzoną po wykonaniu zadania. Można ją przyrównać do odchylenia standardowego z matematyki statystycznej.

Co wpływa na precyzję oszacowania?

  1. Precyzja oszacowania maleje czym większe jest zadanie, które się szacuje. Stąd w estymacji z zastosowaniem planning poker stosuje się ciąg liczb wzorowany na ciągu Fibonacciego, w którym kolejne dopuszczalne wartości oszacowania wzrastają nieliniowo i sugerują coraz mniejszą precyzję: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.
  2. Precyzja oszacowania jest tym większa, im więcej czasu poświęcimy na analizę, przygotowanie odpowiednich założeń do wyceny (precyzja nie rośnie w nieskończoność i w pewnym momencie dodatkowy czas jej już nie zwiększa)
  3. Precyzja oszacowania jest większa jeśli szacujemy powtarzalne zadanie, które było wykonywane w przeszłości.
  4. Precyzja oszacowania jest większa, jeśli w oszacowaniu bierze udział osoba, która ma wiedzę ekspercką i może odnieść się do podobnych problemów i zadań, które wykonywała w przeszłości.

Bufor bezpieczeństwa

Jeśli przyjmiemy założenie upraszczające, że estymacja jest zmienną losową o rozkładzie zbliżonym do rozkładu normalnego, to estymacja oczekiwana to środek tego rozkładu, a wartości rzeczywiste mierzone po wykonaniu zadań powinny trafiać poniżej i powyżej tej wartości mniej więcej z podobnym prawdopodobieństwem. Innymi słowy, tak samo częściej powinniśmy kończyć estymowane zadanie poniżej jak i powyżej tego, co oszacowaliśmy. To jest teoria, rzeczywistość jest jednak trochę bardziej skomplikowana. W praktyce z powodu wielu ryzyk i niepewności rozkład wcale nie musi być rozkładem normalnym i zadania mogą się wydłużyć nawet kilkukrotnie w stosunku do oryginalnej estymaty. Dlatego często dodaje się do estymaty bufor bezpieczeństwa, by zwiększyć prawdopodobieństwo dostarczenia zadań w podanej pracochłonności lub czasie. Bufor bezpieczeństwa jest zatem narzędziem redukcji ryzyka i radzenia sobie z nieprzewidywalnością w projektach.

Co wpływa na wielkość buforu bezpieczeństwa?

  1. jakiego poziomu prawdopodobieństwa oszacowania się oczekuje lub jak było ono traktowane w przeszłości przez osobę proszącą o estymację,
  2. jak osoba szacująca postrzega potencjalne ryzyka i nieprzewidziane komplikacje,
  3. jaki jest jej poziom ekspertyzy i doświadczenia przy podobnych zadaniach w przeszłości,
  4. ile jest zależności zewnętrznych i jak dużo trzeba się komunikować z innymi, by ustalić brakujące szczegóły zadania,
  5. jak bardzo osoba jest zmotywowana do pracy i czy nie chce sobie zarezerwować dodatkowego czasu na luźniejszą pracę.

Poziom prawdopodobieństwa w oszacowaniach

Jak wcześniej było mówione, wielkość bufora bezpieczeństwa wynika z tego, jakiego rodzaju oszacowania się oczekuje. Poniżej są przedstawione 3 grupy prawdopodobieństwa dla oszacowań: optymistyczne, bezpieczne i pesymistyczne. Nie jest to jakiś arbitralny podział, ale pozwala w jakiś sposób podzielić estymacje pod względem poziomu prawdopodobieństwa, co może pomóc w lepszej komunikacji pomiędzy klientem, menedżerem i zespołem co do rodzaju oszacowania.

 

Oszacowanie optymistyczne, to oszacowanie, dla którego jest 50% prawdopodobieństwa, że dotrzyma się zadanie w tym terminie, czyli średnio połowa zadań jest kończona powyżej oszacowanej pracochłonności/czasu a połowa poniżej. Tego typu oszacowanie jest wykorzystywane w metodzie zarządzania projektami metodą łańcucha krytycznego, o czym będzie w jednym z przyszłych wpisów.

Oszacowanie bezpieczne jest najczęsciej podawane przez osoby szacujące zadania i już zawiera pewien bufor bezpieczeństwa. Można je porównać to do oszacowania wykorzystywanego w metodzie PERT, tylko jest ono bez wyliczeń matematycznych, a z użyciem intuicji osoby szacującej. Mało kto stosuje metodę PERT, bo jest czasochłonna i nie powoduje zaczącego zwiększenia precyzji estymacji, a ryzyka można szybciej oszacować określając margines procentowy, który dodawany jest do oszacowania optymistycznego.

Oszacowanie pesymistyczne stosuje się częściej przy szacowaniu czasu w harmonogramie, a mniej przy wycenie pracochłonności. W harmonogramie trzeba uwzględnić dodatkowe ryzyka opóźnień nie wynikające z samej pracy nad zadaniem, stąd większe marginesy.

Oszacowanie oczekiwane zgodnie z definicją matematyczną powinno to być oszacowanie optymistyczne, w praktyce jednak większość osób rozumie je jako oszacowanie bezpieczne.

Najczęściej używane metody estymacji

Przez analogię – oszacowanie zadania na podstawie podobnych zadań z przeszłości

Metoda ekspercka – oszacowanie przez eksperta, który często korzysta z metody przez analogię i sięga do złożoności zadań i ryzyk, z którym się zetknął w przeszłości

Bottom-up – szacowanie całości poprzez rozbicie jej na małe zadania, szacowanie każdego zadania z osobna i następnie zsumowanie

Top-down – szacowanie całości projektu lub zbioru zadań np. poprzez analogię, a następnie rozbijanie tej liczby na podzadania, często top-down i bottom-up stosuje się jednocześnie

Planning poker – metoda stosowana w metodyce Scrum, w której na spotkaniu estymacyjnym wszyscy członkowie zespołu szacują zadania przez jednoczesne przedstawienie swoich estymat na kartach podobnych do kart pokera, a następnie dochodzą do konsensusu poprzez dyskusję o skrajnych estymatach i ponowne jednoczesne przedstawienie estymat. W uproszczeniu jest to taka ekspresowa wersja metody delfickiej.

Co najczęściej szacujemy?

Pracochłonność jest to ilość ciągłej nieprzerwanej pracy jaką musiałaby poświęcić jedna osoba, by skończyć zadanie. Jeśli zadanie musi wykonywać kilka osób, to sumuje się ich czas tak, by powstała jedna liczba tak jakby robiła to jedna osoba. Pracochłonność mierzymy w dniach roboczych (Man Day) lub godzinach roboczych (Man Hour).

Czasochłonność jest to ilość czasu ile będzie trwało wykonanie zadania i mierzymy ją w roboczodniach lub roboczogodzinach. Czasochłonność wylicza się często na podstawie pracochłonności w następujący sposób: Czasochłonność = Pracochłonność / Ilość zasobów. Jeśli zadanie robi 1 osoba, to czasochłonność będzie się równać pracochłonności. Intuicyjnie widać, że z tym sposobem przeliczania wiążą się pewne problemy, które będą omówione w kolejnym wpisie.

Rozmiar/złożoność jest to metryka używana w metodyce Scrum, która zgodnie z głoszoną teorią nie jest pracochłonnością ani czasochłonnością, ale określa rozmiar lub złożoność zadania.  Jednostką miary jest tu tzw. storypoint, który określa relatywną wielkość/złożoność danego zadania w stosunku do innych zadań. Miara relatywna wymaga kalibracji, czyli określenia ile storypointów ma najmniejsze zadanie i największe. Na forach trwają dyskusje co do definicji rozmiaru czy złożoności oraz czy zadanie złożone algorytmicznie lub technicznie, ale krótsze do wykonania ma więcej czy mniej storypointów od zadania prostego i powtarzalnego, ale bardziej czasochłonnego. Ja podzielam pogląd Mike Cohn’a, że storypoint powinien być miarą pracochłonności. W tym wypadku ciągle szacujemy pracochłonność, ale jednostką jest storypoint i jest to miara relatywna i znacznie mniej precyzyjna niż pracochłonność w dniach roboczych.

 

Następna część >>