Estymacja czasu projektu, estymacja czasu w projekcie - to dość kluczowe i znaczące elementy, zadania realizowane w ramach metodyk zwinnych (np. Agile), czy mówiąc bardziej konkretnie w ramach frameworku Scrum.
Estymacja czasu projektu w praktyce oznacza konieczność poznania trafnych, adekwatnych do wielkości Backlogu Produktu technik estymacji.
Trzeba bowiem pamiętać, że estymacja projektów to zadanie kłopotliwe, do pewnego stopnia trudne.
Nie zawsze kończące się pełnym sukcesem, czego dość dobrym przykładem są badania, o których będziemy - między innymi rzecz jasna - pisać w tym artykule.
To zadanie, które można wykonywać na wiele sposobów, czego najlepszym dowodem jest ilość wypracowanych do jego realizacji technik.
W gronie najczęściej opisywanych znajdziemy co najmniej kilkanaście sposobów, które mają swoje ewidentne zalety, ale i nie są wolne od mniejszych lub większych wad.
Estymacja czasu w projekcie na pewno wymaga sporego doświadczenia oraz wiedzy, jak prawidłowo, rzetelnie, a przede wszystkim trafnie oszacować czas konieczny do wdrożenia, zaimplementowania danej pozycji w Backlogu Produktu.
Koniec końców wiedzieć, ile coś może, powinno (sens pozytywny estymacji czasu projektu) i jednocześnie nie może i nie powinno zajmować (sens negatywny estymacji czasu projektów) to panować nad przebiegiem.
Choć czas wdrożenia danego elementu z Backlogu Produktu zależy od wielu czynników - od obiektywnych, zewnętrznych po całkiem subiektywne, wewnętrzne to jednak Product Ownerzy, Scrum Masterzy, czy po prostu zespoły scrumowe nie są zupełnie skazane na przysłowiowe wróżenie z fusów.
Im bardziej doświadczone i doskonałe w estymacji pracy koniecznej do implementacji elementów z Backlogu Produktu są zespoły scrumowe, tym sprawniej, płynniej prowadzą projekt.
Są w stanie go “dowozić” na czas, zgodnie z przyjętym harmonogramem, a tym samym są także w stanie nie przekraczać budżetów.
Umiejętność przewidywania koniecznego czasu pracy jest niezbędna, jeśli projekt ma się zakończyć pełnym sukcesem, zgodnie z oczekiwaniami różnych interesariuszy.
Co jeszcze ważniejsze, trafne oszacowanie Backlogu Produktu pod kątem czasowym pozwala priorytetyzować zadania, osadzać je w szerszym kontekście czasowym (np. związanym z ilością dni roboczych, planowanymi urlopami, sytuacjami losowymi).
Za pomocą jakich technik najlepiej estymować pracę elementów Backlogu Produktu?
W jaki sposób podejmować bardziej trafne, uzasadnione, korzystne decyzji dotyczące harmonogramu tworzenia produktu cyfrowego?
Jakie są najważniejsze korzyści z estymacji pracy elementów Backlogu Produktu?
Jeśli jesteście ciekawi odpowiedzi koniecznie przeczytajcie poniższy artykuł, w którym przybliżymy problematykę pracy, czasu, szacowania tych dwóch kwestii.
Serdecznie zapraszamy do lektury!
Estymacja - co to jest?
Zacznijmy od zaanonsowania kluczowych pytań: Co to jest estymacja? Co to znaczy estymacja projektów prowadzonych w organizacji?
Czym jest czas trwania zadania, na czym polega estymowanie w zarządzaniu projektami? W jaki sposób określić czasowe wymagania projektu w procesie estymacji?
Być może nie każdy czytelnik Journala wie, co rzeczownik "estymacja" i czasownik od niego powstały "estymować" znaczy, dlatego zacznijmy od podania definicji tego słowa, by stało się jasne o czym dokładnie piszemy.
Zgodnie ze słownikową definicją (Słownika Języka Polskiego PWN), estymować to tyle, co szacować, określać w przybliżeniu.
Estymacji nie należy zatem mylić z dokładnym określeniem wielkości. Estymacja nigdy nie jest wystarczająco precyzyjna, by mogła być brana za wartość ostateczną, niezmienną.
Estymacja jest pewnym przybliżeniem się do prawdy, a poziom jej dokładności, a więc zgodności ze stanem faktycznym, jest zależny od wielu czynników.
Doskonale znanych, jak również imponderabiliów, a więc rzeczy, czynników nieuchwytnych.
Takich, których nie da się łatwo i dokładnie zmierzyć lub obliczyć. Takich, co do których istnieje przypuszczenie, że mogą jednak wywierać istotny wpływ.
Techniki estymacji, proces estymacji poszczególnych zadań przez cały zespół, szacowanie parametryczne pozwalają wykonanie zadań, planowanie zadania uczynić bardziej racjonalnym.
Do najważniejszych kwestii determinujących dokładność estymacji należy:
- ilość danych historycznych
- kompletność danych historycznych
- stabilność danych - dynamiki ich zmienności w czasie
- różnorodność danych
- wartość danych - siły ich wpływu
- punkt odniesienia - umiejętność dostrzegania analogii
- doświadczenie w estymacji
- znajomość danych, kontekstów, determinant
- znajomość większości kluczowych ryzyk, zmienności i regularności procesów
- przygotowanie, doświadczenie zespołu, przyjęte założenia - w szczególności ważne jest by trafnie zdefiniować zakres, złożoność, trafność działań.
W kontekście szacowania czasu pracy koniecznego do zaimplementowania, na przykład danej User Story, która znajduje się w Backlogu Produktu, estymacja oznacza przybliżone określenie ile czasu, zasobów, specjalistów jest koniecznych do jej ukończenia.
Ale także oznacza konieczność przyjęcia konkretnych kryteriów, które pozwalają w sposób jednoznaczny rozstrzygnąć, czy wdrożenie danej funkcjonalności zostało ukończone.
Na marginesie dodajmy, że o problematyce Definition of Done / DoD pisaliśmy w osobnym artykule pt. “Co to jest Definition of Done”.
Generalnie estymację można przeprowadzać - w najbardziej ogólnym sensie - na dwa sposoby.
Klasycznie, próbując określić czas realizacji projektu, jaki jest jednocześnie wystarczający i niezbędny do uzyskania pożądanego efektu.
W drugim przypadku do estymacji, czasu wykonania można podejść w sposób relatywny, w którym w procesie oszacowania nie tyle próbuje się wskazać ilość czasu, co dostrzec podobieństwa dwóch zadań.
Porównując zadanie znane do zadania nieznanego całkowicie lub znanego jedynie połowicznie za pomocą określenia ich złożoności, uwarunkowań (np. technologicznych, kompetencyjnych, rynkowych), z jakimi się wiążą jesteśmy w stanie określić ile zadanie nieznane, ale w jakimś sensie podobne może wymagać czasu pracy.
Metoda porównawcza, polegająca na dostrzeganiu analogii oraz znajomości uwarunkowań. W dużym stopniu swoją dokładność zawdzięcza doświadczeniu, wiedzy oraz trafności przyjętych założeń.
Bez względu na sposób dokonywania szacunków czasu pracy, każda metoda estymacji powinna być przede wszystkim:
- łatwo dostępna - nie powinna się wiązać na przykład z koniecznością wykorzystywania drogich narzędzi, technik, metodyk
- prosta i szybka do wykonania
- możliwe tania - także w sensie kosztu czasu pracy osób jej dokonujących
- przekonująca prostotą, efektywnością, intuicyjnością oraz trafnością - powinna dawać “twarde” poczucie, że jej użycie jest słuszne i pożyteczne oraz w niewielkim stopniu ryzykowne.
Dokonując estymacji czasu pracy elementów Backlogu Produktu warto także mieć w pamięci zasady opisane przez Vibhuti Verma w artykule pt. “How to estimate an Agile Backlog?”.
Vibhuti Verma słusznie rekomenduje, by w ramach metodyk zwinnych estymowanie, szacowanie czasu pracy było oparte na przedkładaniu:
- szybkości nad dokładność
- konsensualności nad arbitralność
- relatywności nad bezwzględność.
Szacunki powinno dać się uzyskać szybko, nawet za cenę ich dokładności, bowiem celem jest nie tyle uzyskanie pewności, co możliwość ustrukturowania procesu, projektu w czasie.
Ewaluacja powinna być wynikiem pracy zespołowej, jako swoiste sensus communis, common sense, a więc powinna nie tylko cechować się rozsądkiem, ale także powinna mieć możliwie pełne poparcie członków zespołu.
Zbiorowy konsens jest o wiele trafniejszy, a przynajmniej bardziej odporny względem pojedynczych preferencji, doświadczeń, uprzedzeń, czy nieświadomych założeń.
Warto o tym pamiętać, tym bardziej, że o wiele lepiej chroni on przed popełnieniem błędów o różnym stopniu ważności.
Trzeba także pamiętać, że…
Relatywność estymacji wspierana jest przez naturalną dla człowieka potrzebę porównywania, określania proporcji, wskazywania różnic i podobieństw, dostrzegania analogii.
Szacowanie względne jest stałą cechą operowania człowieka w rzeczywistości. Jest umiejętnością naturalną, którą można wykorzystać także do szacowania czasu pracy.
Tym bardziej, że nasz gatunek ewolucyjnie wykształcił bardzo skuteczną metodę kolektywnego rozwiązywania problemów, która jest o wiele skuteczniejsza niż rozwiązania oferowane przez jednostki.
Rozpoznawanie wzorców pozwoliło człowiekowi stopniowo podporządkowywać sobie rzeczywistość.
Z dużą łatwością przychodzi nam - w szczególności, gdy uruchamiamy “mądrość kolektywną” - porównywanie dwóch podobnych rzeczy i dostrzeganie ich podobieństwa oraz zróżnicowania.
Oszacowanie czasu pracy koniecznego na stworzenie czegoś nie stanowi tutaj żadnego wyjątku.
Efekt jest także zależny od prawidłowości statystycznych.
Nawet, jeśli grupa nie jest koherentna pod względem umiejętności, kompetencji, doświadczeń, potencjałów to przy odpowiedniej skali zaistniałe błędy jednostek nie będą miały wpływu na jakość decyzji podjętej przez grupę. Ich wpływ zostanie zniesiony.
Przykładowo, wiedząc, kto wykonuje pracę, jaki ma poziom kompetencji i doświadczeń, jaką ma wydajność jesteśmy w stanie oszacować w szybko / wolno wykona zadanie, czy będzie ono postrzegane jako łatwe / trudne.
Warto także mieć na uwadze czynniki wpływające na złożoność pracy, które zostały opisane przez Manuela Küblböcka w artykule pt. “How to estimate backlog items”.
Zgodnie z podejściem Küblböcka, na złożoność danego elementu pracy ma wpływ przede wszystkim:
- ilość osób niezbędnych do wykonania pracy
- zróżnicowanie koniecznych kompetencji
- ilość oraz złożoność zależności, powiązania danego elementu Backlogu Produktu z innymi elementami
- możliwość “obsłużenia” zależności przez zespół - praca jest bardziej czasochłonna, gdy musi być oparta na swoistym “outsourcingu kompetencji i doświadczeń”
- ilości komponentów koniecznych do zrealizowania danego zadania
- długu technologicznego oraz konieczności jego naprawienia
- dostępności danych testowych
- ilości, złożoności, wzajemnego powiązania pozostałych prac, które będą wykonywane w czasie konkretnego Sprintu
- ilości, wagi, wpływu czynników niedostrzegalnych, nieuświadomionych, które jednak oddziałują na szybkość, jakość, bezproblemowość, bezbłędność, doskonałość wykonywanej pracy.
Warto także dodać, że im bardziej dwie porównywane do siebie rzeczy są podobne, tym łatwiej jest je ze sobą porównywać.
Szacowanie pracy elementów Backlogu Produktu, które są do siebie w dużym stopniu podobne będzie o wiele prostsze, dokładniejsze i w mniejszym stopniu podatne na ryzyko popełnienia błędów.
Jak oszacować, estymować pracę elementów Backlogu Produktu?
Trafność, dokładność, tym samym użyteczność estymacji jest, co oczywiste, kwestią priorytetową oraz najbardziej problematyczną.
Warto jednak, trochę pół żartem, trochę pół serio, mieć na uwadze, że zgodnie z prawem Hofstadtera uzyskany wynik, czy to liczbowy, czy wyrażony w sposób jakościowy zawsze będzie w pewnym sensie niedoszacowany.
Przypomnijmy, prawo Hofstadtera głosi, że praca zawsze trwa dłużej niż się spodziewamy, nawet jeśli bierzemy pod uwagę prawo Hofstadtera.
Zaprezentowane prawo w książce “Gödel, Escher, Bach: An Eternal Golden Braid” bardzo wymownie pokazuje, że dokładność szacowania zawsze jest mniej lub bardziej problematyczna.
Stąd też nie może być traktowana jako wartość bezwzględna, ale raczej jako swoisty drogowskaz, podpowiedź.
Prawo Hofstadtera nie jest tylko i wyłącznie intelektualną ciekawostką, pewnym rodzajem żartu intelektualnego, ale jest obserwowalne w codziennej pracy zespołów scrumowych.
Potwierdzają to także badania.
Badania McKinsey i BT Center for Major Program Management na Uniwersytecie Oksfordzkim wykazały, że aż 66% projektów oprogramowania doszło do przekroczenia kosztów.
Co jeszcze gorsze, a co w wynika z wyżej cytowanych badań McKinsey przeprowadzonych wraz z BT Center, w 17% projektów IT niedoszacowania niemal spowodowały upadłość firm.
Średnio duże projekty IT przekraczają budżet o 45%, przynosząc o 56% mniejszą wartość niż przewidywano.
Badania przeprowadzono w ponad 5400 projektach informatycznych, co zapewnia iż uzyskane wyniki cechują się rzetelnością oraz znaczną trafnością. Badania McKinsey i BT Center for Major Program Management pod względem metodologicznym są bardzo wiarygodne.
Dlatego warto pamiętać o tych wynikach, nawet biorąc poprawkę, że wartości w polskich warunkach mogą się nieco różnić. Jednak, co do zasady, podobne trendy będą się uwidocznić także na polskim rynku.
Nic więc dziwnego, że dokładność estymacji pracy elementów Backlogu Produktu powinna być doskonalona.
Zakres, złożoność, typowość / nietypowość projektu, zmiany zakresu pojawiające się w trakcie trwania kolejnych Sprintów, brakujące funkcjonalności najczęściej odpowiadają za przekraczanie estymowanego czasu implementacji.
Ponadto, “winnym” jest także skłonność ludzi do przeceniania własnych możliwości, co skutkuje tendencją raczej do zaniżania czasu koniecznego do wykonania danego zadania, osiągnięcia danego celu.
Na gruncie psychologii tę tendencję nazywa się Złudzeniem Ponadprzeciętności (Illusory Superiority), które najczęściej dochodzi do głosu właśnie w szacowaniu trudności wykonywania zadań.
Odwołanie się do zdrowego rozsądku, na którego straży bardziej stoją grupy niż jednostki, pozwala uniknąć tych efektów niedoszacowania i planować pracę w bardziej realistyczny sposób.
Stąd też Backlog Produktu powinien być maksymalnie dostępny, przejrzysty i uporządkowany zgodnie z konsensualnie ustanowionym porządkiem przez zespół deweloperski.
Sposobem radzenia sobie z niedoszacowaniem jest także podział projektu na kamienie milowe (Milestones), które wyznaczają ramy czasowe projektu. Podział dużych zadań na mniejsze, a tych na jeszcze mniejsze także pozwala uzyskać lepszą precyzję oraz dokładniejszą estymację.
Choćby tak “prowizoryczne” ustrukturowanie czasowe projektu pozwala na podejmowanie lepszych, bardziej adekwatnych i skutecznych decyzji.
Jednak prawdziwymi game changerami w tym temacie są popularne techniki szacowania pracy elementów Backlogu Produktu w metodykach zwinnych.
W literaturze przedmiotowej najczęściej omawia się kilkanaście. My wybraliśmy kilka z nich, które naszym skromnym zdaniem na pewno warte są zastosowania.
Wybór konkretnej techniki, co oczywiste, zawsze powinien być jednak uzasadniony specyfiką danego projektu, wielkością Backlogu Produktu, specyfiką zadań, doświadczeniem zespołu.
Ciąg Fibonacciego (Fibonacci Sequence)
Ciąg Fibonacciego powstaje, gdy każda kolejna liczba stanowi sumę dwóch poprzednich. Na przykład: 1, 2, 3, 5, 8, 13, 21… I jako taki stanowi doskonałą skalę porównawczą.
Ciąg Fibonacciego wykorzystuje się do określenia rozmiaru, wielkości danego zadania. Wystarczy do konkretnego zadania przypisać konkretną wartość liczbową, która reprezentuje konieczny do jego wykonania czas, wysiłek, jego trudność oraz złożoność.
W praktyce najczęściej do określenia poziomu trudności używa się zakresu od 1 do 21. Mając pewien punkt wyjścia każdy kolejny podobny element Backlogu może być estymowany poprzez porównanie do zadania wyjściowego.
Ciąg Fibonacciego wraz ze wzrostem złożoności uwydatnia odległości dzielące kolejne pozycje. Zwróćmy uwagę, że między wartością 21 a kolejną po niej następującą 34 jest “przepaść” 13 punktów, podczas gdy “odległość” między 21 a poprzedzającą ją 13 to tylko 8 punktów.
Zatem, zadania proste, podobne do siebie w niewielkim stopniu będą się od siebie różniły pod względem wartości, jaką im przypiszemy. Co z kolei pozwala uzyskać bardziej realistyczne estymacje.
Rozmiary T-shirtów (T-shirt Sizing)
Wszyscy znamy rozmiarówkę koszulek. Mogą być w rozmiarze Extra-Small (XS), Small (S), Medium (M), Large (L) i Extra-Large (XL).
W sposób intuicyjny, bezproblemowy “łapiemy” różnice, jakie między nimi występują oraz, co one oznaczają w praktyce. Metafora koszulki, jako wielkości projektu, jest jednocześnie bardzo obrazowa i w dobrym tego słowa znaczeniu swojska. Jest dostępna dla każdego.
Dzięki temu rozmiary mogą stanowić bardzo trafne miary poziomu złożoności, trudności User Story, do których estymacji są najczęściej używane.
Po przeczytaniu przez facylitatora Historyjki Użytkownika zespół scrumowy przypisuje jej rozmiar i w drodze dyskusji dochodzi do ostatecznego określenia rozmiaru koszulki, jaki do niej najbardziej pasuje.
Zaletą tej metody jest operowanie jakościowymi wielkościami (choć przez niektórych uznawane jest to za wadę, głównie z powodu mniejszej precyzji), które są obrazowe oraz związane z doświadczeniem.
Karty do gry (Playing Cards)
W tej technice estymacji każdy członek zespołu scrumowego otrzymuje talię kart. Każda karta z talii reprezentuje określoną wartość, wynikającą z przyjętej skali.
Historyjki Użytkowników wraz z kryteriami ich akceptacji są odczytywane przez facylitatora. Wszyscy członkowie zespołu oceniają poziom ich trudności, złożoności za pomocą uniesionych kart.
Celem zespołu jest przedyskutowanie ocen - w szczególności skrajnych, odnoszących się do minimalnego i maksymalnego poziomu trudności - oraz osiągnięcie konsensusu.
Metoda ta jest rekomendowana do Backlogów Produktu, w których jest niewielka ilość pozycji (nie więcej niż kilkanaście), bowiem istotą tej techniki jest analiza, dyskusja oraz konsensu, które siłą rzeczy zajmują dużo czasu.
PERT (Program Evaluation and Review Technique)
Technika ta została stworzona przez pracowników Departamentu Obrony Stanów Zjednoczonych.
Ewaluowany projekt jest przedstawiany za pomocą diagramu sieciowego, którego wierzchołki odpowiadają zadaniom, a łączące je linie graficznie wskazują ich wzajemne powiązanie wraz z estymowanym czasem trwania.
Istotą tej techniki jest traktowanie czasu trwania zadania jako zmiennej losowej, a nie determinowanej przez konkretne czynniki. Tym samym możliwe jest obliczanie statystycznego prawdopodobieństwa.
W obliczeniach uwzględniane są trzy zmienne:
- wartość optymistycznego, minimalnego potrzebnego czasu do zakończenia zadania (Optimistic Time)
- wartość najbardziej prawdopodobnego czasu koniecznego do zakończenia zadania (Most Likely Time)
- wartość pesymistycznego, maksymalnego potrzebnego czasu do zakończenia zadania (Pessimistic Time).
Szacowany czas wykonania zadania (Time Expected) jest wyliczany zgodnie ze wzorem: TE=(O+4M+P)÷6.
Szybkość, łatwość obliczeń jest dużą zaletą tej techniki, natomiast do największych wad zalicza się subiektywność przypisywanych wartości czasowych do zadań oraz zbyt dużą sztywność, wynikającą z myślenia o sieci w sposób deterministyczny.
Program Evaluation and Review Technique jest techniką rekomendowaną do estymacji czasu pracy znacznej ilości elementów znajdujących się w Backlogu Produktu.
Jak estymować pracę elementów Backlogu. Podsumowanie
- Słowa estymacja, estymować oznaczają szacowanie, określanie wartości, wielkości czegoś w przybliżeniu.
- Estymacja jest pewnym przybliżeniem się do prawdy.
- Szacowanie względne jest stałą cechą operowania człowieka w rzeczywistości. Jest umiejętnością naturalną, którą można wykorzystać także do szacowania czasu pracy.
- Poziom dokładności estymacji, a więc zgodności ze stanem faktycznym, jest zależny od wielu czynników. Zarówno znanych, jak również niejawnych, nieuświadamianych.
- Warto pamiętać, że każda estymacja jest niedoskonała. Zgodnie z prawem Hofstadtera uzyskany wynik, czy to liczbowy, czy wyrażony w sposób jakościowy zawsze będzie w pewnym sensie niedoszacowany.
- Estymację można przeprowadzać w sposób klasyczny próbując określić czas, jaki jest jednocześnie wystarczający i niezbędny do uzyskania pożądanego efektu oraz w sposób relatywny, w którym nie tyle próbuje się wskazać ilość czasu, co dostrzec podobieństwa dwóch zadań.
- Porównując zadanie znane do zadania nieznanego całkowicie lub znanego jedynie połowicznie za pomocą określenia ich złożoności, uwarunkowań, z jakimi się wiążą jesteśmy w stanie określić ile zadanie nieznane, ale w jakimś sensie podobne może wymagać czasu pracy.
- Estymacja czasu projektu w praktyce oznacza konieczność poznania trafnych, adekwatnych do wielkości Backlogu Produktu technik estymacji.
- Estymacja czasu w projekcie wymaga doświadczenia oraz wiedzy, jak prawidłowo, rzetelnie, a przede wszystkim trafnie oszacować czas konieczny do wdrożenia, zaimplementowania danej pozycji w Backlogu Produktu.
- Trafne oszacowanie Backlogu Produktu pod kątem czasowym pozwala priorytetyzować zadania, osadzać je w szerszym kontekście czasowym.
- Ewaluacja czasu pracy elementów Backlogu Produktu powinna być wynikiem pracy zespołowej, jako swoiste sensus communis, common sense, a więc powinna nie tylko cechować się rozsądkiem, ale także powinna mieć możliwie pełne poparcie członków zespołu.
- Zakres, złożoność, typowość / nietypowość projektu, zmiany zakresu pojawiające się w trakcie trwania kolejnych Sprintów, brakujące funkcjonalności najczęściej odpowiadają za przekraczanie estymowanego czasu implementacji.
