Wiele osób pracujących z produktami i projektami głowi się od lat, jak estymować, by oszacowania miały sens? Jakimi technikami się posługiwać, by zespół był efektywny, ale także pewny i zaangażowany w swoje decyzje? Odpowiedzi na te pytania szuka każdy, kto odpowiada za proces, projekt, budżet i wyliczając tak dalej, powinniśmy też dojść do wniosku, że samym zespołom deweloperskim powinno na tym zależeć.
Temat estymowania rozbijemy na 3 artykuły:
- Teoria;
- Techniki estymacji;
- Team Estimation Game.
W każdym z nich, zagłebimy się w pojęcie szacowania w zwinnym środowisku i postaramy się odpowiedzieć na tytułowe pytanie.
Teoria estymacji
Niezależnie od wybranej techniki, estymowanie służy do oszacowania złożoności poszczególnych zadań czy projektów. W efekcie osiągniętych wyliczeń podejmowane są decyzje o kolejności, wdrożeniu, budżetach i czasie trwania prac. Wydawałoby się, że z pozoru niepewna wartość, która może ulec zmianie nie znaczy nic dla osób biznesowych – jest wręcz odwrotnie! O estymacje opiera się większą część planowania prac, deklarowania terminów i marketingowych działań wokół produktu.
Jak zatem estymować? Poniżej kilka wniosków i ogólnie znanych teorii:
- Estymacja nie powinna być nadawana przez pojedynczą osobę, nawet tą, która będzie dane zadanie robiła; największy sens i bliskość prawdy posiadają estymacje nadawane wspólnie, przez zespół.
- Technik estymacji jest wiele i nie ma jednej właściwej, która zawsze przynosi wymierne rezultaty. Warto testować, sprawdzać i oceniać techniki w zespołach. Tylko tak dojdzie się do tej najbardziej dopasowanej do ludzi, produktu i potrzeb.
- Nie można zapominać, że estymacja to szacunek, prognoza tego jak złożone i czasochłonne jest zadanie. Nie jest to dokładna wartość odzwierciedlająca ile czasu tak naprawdę nam dana czynność zajmie.
- Prawdopodobieństwo dobrego oszacowania funkcjonalności rośnie wraz ze znajomością produktu i środowiska. Zespoły zwinne mogą dostarczać lepsze oszacowanie dzięki iteracyjnej pracy, która daje im feedback z rynku i częstą adaptację działań do oczekiwań.
Co ma wpływ na estymację?
Estymacja bazuje na kilku czynnikach i zmienia się wraz z nimi:
- doświadczeniu członków zespołu;
- dostępnej wiedzy o produkcie;
- jasno zdefiniowanych wymaganiach;
- zrozumieniu wymagań;
- przyjętych założeniach i warunkach;
- zidentyfikowaniu zależności pomiędzy zadaniami.
Estymacje w Scrumie
Pracując w Scrumie, należy mieć na uwadze, że brak estymacji jest niezgodny z zasadami frameworku. Estymowanie stało się jedną z nieodłącznych części przygotowania do planowania. Sama dekompozycja i szacowanie odbywa się najczęściej w procesie refinementu Backlogu Produktu. Dzięki estymacjom możemy wyliczyć velocity, czyli prędkość pracy zespołu i przygotować wstępne plany na sprinty, czy też oszacować czas wdrożenia danej funkcjonalności.
Zespół deweloperski, jako grupa ekspertów powinien być zawsze zaangażowany w omawianie i estymację zadań. Co więcej – estymacja to ich odpowiedzialność. Każdy członek zespołu powinien wiedzieć na czym polegają poszczególne zadania i jaki mają wpływ na produkt. Dzięki takiemu podejściu dbamy o artefakt transparentności w całym zespole i unikamy tzw. wąskiego gardła. Silosy kompetencji zdarzają się także w wyniku estymacji w pojedynkę. W przypadku nagłej nieobecności takiej osoby, nikt inny nie zna założeń jakie przyjęła i jaką wiedzą dysponowała, zatem estymacja obarczona jest wysokim ryzykiem.
Fakty i mity estymacji w Scrum
Wśród osób mających do czynienia ze Scrumem krążą trzy flagowe mity, które praktycznie w każdym nowym zespole prędzej czy później wychodzą na światło dzienne. Śpieszymy z wyjaśnieniem!
Mit: W Scrum estymuje się w story pointach.
Fakt: Scrum Guide nie określa żadnej techniki i miary, ich wybór należy do zespołu. Zatem, story pointy nie są jedyną słuszną miarą estymowania w Scrumie. Warto eksperymentować i poszukać miary odpowiadającej zespołowi, takiej, która przyczyni się do zrozumienia wielkości, pozwoli planować i odpowiadać na potrzeby całego zespołu. Szukając odpowiedzi w Scrum Guide jak estymować dowiecie się jedynie, że każdy PBI ma atrybut estymacji.
Mit: Estymacja nie może się zmienić.
Fakt: Estymacja jest prognozą, szacunkiem, pewnym domniemaniem, że dana funkcjonalność będzie tak złożona jak na dzień estymowania się wydaje. Scrum Guide mówi o estymacji jako “forecast” a nie jako “commitment”. Dodatkowo, zespół powinien reestymować zadanie gdy tylko okaże się ono inne niż zakładano. To bardzo ważne, by wartości odzwierciedlały rzeczywistość, bo tylko wtedy wszelkie narzędzia prognozujące prędkość pracy zespołu i przy okazji pozwalające na skuteczne planowanie będą stanowiły wartość dodaną w pracy nad produktem.
Mit: Velocity można porównywać i oceniać na jego podstawie rozwój zespołów.
Fakt: Velocity opiera się na średniej z ilości ukończonej pracy np. z ostatnich 3 sprintów wyrażonej w mierze jaka została wybrana do estymacji. Każdy zespół może estymować na innej skali czy z inną granularnością, czy też z innymi założeniami co do wartości. Zatem 50 punktów w zespole A nie będzie mogło być przeciwstawiane 100 punktom w zespole B. Należałoby porównać jakość i wartość dostarczaną produktowi zamiast ilości punktów.
Warto o tych faktach pamiętać, a mity obalać, bo wprowadzają więcej zamieszania niż korzyści.
Gdzie warto sięgnąć po więcej teorii?
Dochodząc do wprawy w estymowaniu należałoby przede wszystkim skupić uwagę na praktykowaniu szacowania. Jest jednak kilka wartych uwagi źródeł teorii, które pomogą uniknąć podstawowych błędów. Przede wszystkim dobrym źródłem podstaw jest książka Mike Cohna “Agile Estimating and Planning“. Znajdziecie w niej dużą dawkę wiedzy o szacowaniu i planowaniu w zwinnym środowisku popartą przykładami i doświadczeniem autora.
W drugiej kolejności stoją na równi wszystkie artykuły o estymowaniu jakie uda się znaleźć w sieci. Każdy z nich zawiera uniwersalne rady, nowatorskie pomysły i oparte na doświadczeniach wnioski – warto kilka takich tekstów przeczytać i sprawdzić postawione tezy w praktyce.
Zobacz trzecią część serii o Team Estimation Game >>
Sprawdź nasze ostatnie wpisy:
