Szacowanie wysiłku potrzebnego do wykonania pracy wg. AgileBA®

Estymacja w podejściach zwinnych jest wykorzystywana do wielu celów: do przygotowania rzetelnego Uzasadnienie Biznesowego, do ocenienia czy projekt jest wykonalny, do zaplanowanie wydatków i przygotowania harmonogramu. Warto pamiętać o kilku ważnych rzeczach!

Szacowanie wysiłku

Oszacowanie wykonują osoby, które będą wykonywać pracę. Rekomendowana techniką w tym przypadku jest Planning Poker spopularyzowany przez Mike’a Cohna. Warto zwrócić uwagę, że estymowanie przy użyciu tej techniki może być wykonywany na bardzo wczesnym etapie realizacji projektu, już w fazie „Wykonalność”, przy założeniu, że może być bardzo nieprecyzyjne. Jest zatem podawane w „widełkach” czasu, kosztu lub story pointów.
Oszacowanie powinno być zrewidowane w miarę upływu czasu i odkrywaniu szczegółów dotyczących kolejnych wymagań. Używając Planning Pokera możemy szacować wysiłek w fazie „Podstawy” kiedy na jej zakończenie powinna pojawić się deklaracja kosztu i czasu projektu. Tak jak w fazie „Wykonalność” bazujemy tylko na około 10 ogólnych wymaganiach tak w fazie „Podstaw” mamy tych ogólnych wymagań około 100. I tu się pojawia kilka pytań:
- Co zrobić, jeśli nie mamy szczegółowych wymagań a musimy podpisać kontrakt na pokaźną kwotę bez wiedzy o tym co mamy dokładnie do zrobienia?
- Co, jeśli po dekompozycji tych 100 wymagań w fazie Rozwoju Ewolucyjnego estymaty nagle „urosną”?
- Co, jeśli po dekompozycji okaże się, że nie przewidzieliśmy istnienia wielu koniecznych do zrealizowania wymagań?

Niestety tak się może wydarzyć. Zgodnie z teorią stożka niepewności (ang. „cone of uncertainty”), to jak długo będzie trwał projekt, jesteśmy w stanie tym bardziej precyzyjnie oszacować, im na dalszym etapie realizacji tego projektu jesteśmy. No niestety przewidywanie przyszłości jest trudne i obarczone dużym ryzykiem.

Jak sobie z tym radzić? Jest na to kilka sposobów!

Pamiętajmy, że tolerancją w projektach zwinnych jest zakres. W momencie zwiększania się estymat zacznijmy rozmowy o upraszczaniu rozwiązania lub rezygnacji z mniej wartościowych rozwiązań.
Skupmy się na dostarczeniu MVP (Minimum Viable Product) rozważając przesunięcie pozostałych funkcjonalności do kolejnego, odrębnie kontraktowanego etapu projektu.
Starajmy się dzielić projekty na wiele małych, najlepiej regularnych przyrostów (Incrementów), dzięki czemu łatwiej będziemy śledzili postępy prac i reagowali na bieżąco na rosnący zakres projektu.
Możemy próbować zadbać o to, żeby w kontraktach była jasno zapisana potrzeba, problem do rozwiązania a nie zakres prac. Dzięki temu łatwiej nam będzie negocjować uproszczenia.
Bądźmy transparentni w swojej pracy, dzięki temu zdobędziemy zaufanie odbiorcy naszego rozwiązania i otworzymy tym sposobem drzwi do negocjacji.
Dbajmy o klarowną komunikacje i efektywną współpracę w projekcie, ściśle angażującą biznes.

Z ciekawostek mogę polecić książkę „Scrum, czyli jak robić dwa razy więcej, dwa razy szybciej” Jeffa Sutherlanda, rozdział „Naprawianie FBI”. Tam przeczytamy jak jeden z twórców Scruma rozprawił się z kwestią niepewności szacowania na początku projektu 😊.

Romuald Krysiak