Jednym z największych wyzwań w pracy Zespołu Deweloperskiego, ale też Product Ownera z interesariuszami jest określenie, kiedy dana funkcjonalność zostanie dostarczona. Jest wiele aspektów tego zagadnienia. Relacje, emocje, asertywność, szacowanie. I właśnie tą ostatnią kwestią chce się dzisiaj zająć. Jakie są metody relatywnego szacowania zadań, jak to wytłumaczyć zespołowi i dlaczego jest to lepsze podejście od klasycznego?
Rand Corporation w swoim badaniu przeprowadzonym w latach ‘40 pokazał, że ludzie nie są dobrzy w estymowaniu (szacowaniu) zadań w godzinach i pokazuje to też nasza praktyka. Jako ludzie nie potrafimy tego robić. Posiadamy tendencje do bycia albo zbytnimi optymistami, albo pesymistami. Rzadko się zdarza, że jesteśmy w tym procesie realistami. Według raportu przygotowanego przez firmę doradczą KPMG i opublikowanego w 2017 roku (raport dotyczy Nowej Zelandii, ale myslę, że ma również prawdziwe stwierdzenia dla reszty świata), tylko 31% organizacji szacujących w klasyczny sposób (opierając sie na dniach) jest przekonana, że dostarczy projekt w deklarowanym czasie. Może być wiele powodów takiego oszacowania. Kilka przykładowych wymieniam poniżej:
- złożoność, definiowana jako: trudność w znalezieniu rozwiązania do zdefiniowanego problemu, wpływ na obecną funkcjonalność, obecność wymagań niefunkcjonalnych, poziom długu technicznego,
- brak przewidywalności, definiowana jako: potrzebę kreowania wiedzy, potrzebę bycia innowacyjnym, wpływ społeczny, oczekiwany poziom dynamiczności (reagowania na zmiany wewnętrzne jak i zewnętrzne), występowania zależności (wewnętrznych np. od innych zespołów, jak i zewnętrznych np. od firm trzecich), występowanie przeciwności i problemów (np. problemy z technologią),
- nieuszczegółowione wymagania, definiowane jako: brak ukierunkowania na rzeczywistą potrzebę biznesową, brak kompletności wymagań, brak klarowności, brak spójności (np. do funkcjonalności już istniejących), brak możliwości przeprowadzenia testów,
- czas, definiowany jako: uzależnienie się od podania konkretnej daty (czasami również jej narzucanie), różne możliwości poszczególnych osób.
Jest jeszcze jeden kontekst, na który chcę Wam zwrócić uwagę. Cytując artykuł “Comparing traditional and agile project management estimation techniques“ załóżmy, że mamy trzech ekspertów i budujemy razem z nimi nowe data center. kiedy spytamy się o estymację, pierwszy odpowie, że jego praca zajmie 20h. Drugi ekspert, zajmujący się trochę inną dziedziną i słysząc poprzedni szacunek pomyśli “zajmie mi to 20 godzin, ale podwoję to i powiem 40h, ponieważ nie chcę być zakłopotany, jak w ostatnim projekcie, kiedy utknęliśmy z serwerem, na który poświęciłem dużo więcej czasu”. A trzeci ekspert zapytany o swój szacunek odpowie “To może zabrać mi 60 godzin, ale powiem 40, ponieważ chcę zaimponować zespołowi i pokazać, jaki jestem inteligentny i kompetentny”.
Teraz wyobraźcie sobie zwielokrotnienie ekspertów w skomplikowanym projekcie. Jeden będzie zawyżał pracochłonność aby mieć rezerwę, inny ją obniżał aby się “pokazać” szefowi lub klientowi.
Innymi słowy w tradycyjnym szacowaniu znajdziecie wiele emocji i oczekiwań. Pracownicy chcą wyglądać na kompetentnych, aby uniknąć zakłopotania lub mieć argumenty przeciw narzuconej przez kierownika projektu czy klienta dacie. Łatwo zauważyć, że podczas gdy tradycyjne szacowanie może być postrzegane jako znane i bezpieczne przez wielu klientów i PMO, to proste ćwiczenie jest pełne emocji, ego i wielu innych elementów.
W opozycji do opisywanego szacowania klasycznego, jest szacowanie relatywne. Oryginalnie zostało ono stworzone w firmie RAND Corporation i nazwane Wideband Delphi. Ta sama technika została zastosowana w Agile, a nazywa się Planning Poker.
Wg scrum.inc, organizacje pracujące na poziomie CMMI 5 potrafią skrócić czas estymacji o 80% w stosunku do organizacji szacujących zadania w sposób tradycyjny. Według tego samego źródła, firmy telekomunikacyjne raportują skrócenie czasu potrzebnego na estymowanie 48 razy, przy zachowaniu tej samej lub lepszej dokładności szacunków.
A problemy wskazane na początku artykułu? Przy relatywnym estymowaniu prawdopodobnie one nadal będą występowały, jednak znaczne skrócenie czasu na estymację pozwoli na jej ponowne wykonanie w dalszym etapie prac, kiedy zmniejszy się poziom chaosu, kiedy Zespół będzie więcej wiedział o technologii, materii projektu, zależnościach. Więc i część problemów / przeszkód naturalnie zniknie.
Tylko jak wytłumaczyć zespołowi co to jest estymacja relatywna? Poniżej znajdziecie trzy opisane metody, które pomogą wyjaśnić różnice w estymacji a czasami jej nauczyć.
Metoda 1 – Budynki
Metoda proponowana przez AxisAgile z Australii. Bazuje ona na pokazaniu estymacji na przykładzie wejścia na cztery różnej wysokości budynki, będące też w różnej kondycji. Podoba mi się tutaj ujęcie drugie, mówiące o przypisaniu 10 wirtualnych punktów do najmniejszego budynku i zmierzenia tą skalą pozostałych (jak zwrócicie uwagę, budynek trzeci dostał tych punktów 25 z uwagi na jego złą kondycję i potrzebę założenia nieprzewidywalnych zdarzeń, które mogą się pojawić). Czyli de facto mamy w tym ćwiczeniu pokazany wysiłek związany z wejściem na budynek, jednak nie w skali tradycyjnej a poprzez porównywanie, czyli skalę relatywną. Dalej autor metody tłumaczy jak się ta estymacja ma się do prędkości zespołu. Jeżeli w tym przykładzie przyjmiemy, że umowna długość naszego sprintu to 10 minut , to pytanie brzmi, jak daleko w tym czasie zajdziemy. Tutaj wyszło, że do połowy budynku najmniejszego. Czyli cały najmniejszy budynek zajmie nam około 20 minut. Dla mnie najważniejsze w tym ćwiczeniu jest to, że porównujemy budynki między sobą. A w świecie produkcji oprogramowania także porównujemy, ale nie budynki, a zadania.
Metoda 2 – Tasty estimation
Metoda polega na wskazywaniu wielkości zadań bazując na pierwszym losowym, którego wielkość już została oszacowana. Jest ona bardzo podobna do Magic estimation. Innym słowy pierwsze z zadań ktoś, losowy członek zespołu, szacuje w ciszy na jakąś wartość (powiedzmy, że M w skali koszulkowej). Kolejne zadania są porównywane z tym pierwszym – mniejsze otrzymują S, XS, większe L, XL. Metoda także dopuszcza, aby nie robić nowego szacowania zadania, ale przesunąć już oszczacowane zadanie jako mniejsze / większe. Najbardziej podoba mi się ostatni akapit w opisie tego ćwiczenia, podający link do listy posiłków. Listy posiłków dlatego, że jest to dobry wstęp do samego szacowania – poproszenie zespołu o oszacowanie złożoności przygotowania np. hamburgera i użycie tego jako pierwszego zadania, z którym każde kolejne będzie porównywane (np. przygotowanie fish & chips). Nauczenie w ten sposób zespołu czym jest szacowanie relatywne może pomóc w przeprowadzeniu faktycznej estymacji.
Metoda 3 – szacowanie zadań domowych
Wychodzimy od listy zadań, którymi mogą być zadania związane z prowadzeniem / utrzymaniem domu. Listą tą mogą być zadania takie jak umycie podłogi w kuchni, montaż nowego piekarnika czy też powieszenie na ścianie nowego obrazu. Najważniejsze w tym zadaniu znowu jest wybranie pierwszego, oszacowanie skali trudności i szacowanie kolejnych zadań w kontekście tego pierwszego.
Oczywistą wadą tej metody (jak i poprzedniej) jest fakt, że szacunki będą się różniły w zależności od doświadczenia poszczególnych osób (ktoś podobne zadania robi cały czas, ktoś wie o co chodzi w zadaniu, ktoś pierwszy razy słyszy o zadaniu). Trochę to będzie przypominało zespół deweloperski – znam tą technologię / nie znam jej, robiłem już coś podobnego / nie robiłem tego nigdy, itp. Jak sobie z tym poradzić? Są co najmniej dwie wariacje tego pytania:
- jak może ktoś wyznaczać estymatę, jeżeli nie ma wystarczających umiejętności?
Sytuacja dotyczy np. testera, który ma wątpliwości czy szacować zadania związane z np. “backendem”. Mike Cohn w swoim artykule sugeruje, że osoba taka nie musi estymować zadań, które jej technologicznie nie dotyczą, ale powinna uczestniczyć w planowaniu. Oznacza to, że taka osoba może zadawać w trakcie spotkania bardzo trafne pytania dotyczące odkrywania przeoczonych założeń lub może widzieć pracę do wykonania, którą przeoczyli pozostali członkowie zespołu. Zapoznajcie się proszę z kilkoma przykładami podanymi przez Mike’a, które pokaże Wam konketne zachowania i pytania, które w trakcie takiego spotkania powinny paść.
- brak doświadczenia (jedna osoba już to robiła i estymuje na 2, druga osoba nigdy nie dotknęła materii zadania i estymuje na 5)
Czy przypadkiem nie robimy estymacji relatywnej, która w swoim założeniu opiera się na uśrednieniu złożoności podanej przez poszczególnych członków zespołu? Metoda Planning Poker dobrze to wyjaśnia.
Podsumowanie
Zwinne zespoły przez iteracyjno-przyrostowe budowanie produktu do kolejnych planowań włączają wnioski z tego, czego nauczyły się w poprzednich iteracjach, dzięki temu tworząc samoregulujące się plany, które są oparte na rzeczywistości i przeszłych doświadczeniach. Wracamy tutaj do podstaw agile i empiryzmu.
Nasze doświadczenie pomaga nam w estymowaniu przyszłych zadań bazując na wiedzy o zadaniach już zrealizowanych. Oczywiście zawsze Zespół Deweloperski może trafić np. na dług techniczny i w związku z tym pierwotna estymata nie będzie prawidłowa. Ale w takim przypadku Zespół wie, jakie obszary aplikacji mogą generować dodatkowe ryzyko, ile takich sytuacji wystąpiło (temat zahaczający o miary i dlaczego właśnie takie, itp.
Na koniec subiektywne korzyści z relatywnego (względnego) szacowania:
- Szybsza ocena zadań
- Szacowanie (zrozumiałych) zadań przez cały zespół
- Wykorzystanie wiedzy zdobytej podczas poprzednich szacowań