- Brawa na Sprint Review — 06/09/2024
- Kanban — Jak zacząć? — 30/08/2024
- Definicja Ukończenia kontra Kryteria Akceptacji — 26/08/2024
Zdarza się, że na szkoleniach, albo pracuję z klientem spotykam duży opór kiedy rozmawiamy o szacowaniu w godzinach. Często mam wrażenie, że to jeden z punktów wysoko na liście własnej agendy uczestników szkolenia. Pojawiają się te same pytania. Dlaczego nie można szacować w godzinach? O co chodzi z tym Story Pointami? Czasem odpowiadam korzystając z pokrętnego poczucia humoru, że Story Point to jeszcze nic, poczekaj na Gumisie.
Scrum Guide nie wspomina o sposobie szacowania, wymaga jedynie, żeby Product Backlog Item miał oszacowany rozmiar. Za szacowanie odpowiada Zespół Developerski. Sposób szacowania i przebieg samego procesu jest określany przez ten Zespół. Na pewno szacowanie elementów Product Backlog odbywa się podczas czynności pielęgnacji, czyli Product Backlog refinement. Tyle wiadomo. Można zatem powiedzieć, że Scrum Guide nic nie mówi o szacowaniu w godzinach i zdecydowanie nie jest to zabronione. Natomiast warto się zastanowić czy używanie jednostki czasu do szacowania to dobry pomysł i jakie są tego konsekwencje.
Najpierw zastanówmy się nad samą jednostka czasu. W praktyce pojawiają się dwie jednostki roboczo-godzina i osobo-dzień (man-day). Skąd akurat te jednostki są w użyciu? Wynika to najzwyczajniej z pewnych zaszłości. W tradycyjnym podejściu do zarządzania projektami przyjęło się szacowanie pracy w jednostkach czasu, żeby stworzyć harmonogram pracy. Ustalenie czasu trwania zadań było potrzebne do powstania takich artefaktów jak Work Breakdown Structure i Statement of Work. W Scrum takich artefaktów nie ma. Statement of Work zastąpił ciągle zmieniający się Product Backlog. Work Breakdown Structure nie ma sensu, bo planowanie jest oparte na procesie empirycznym. Konkretne zadania pojawią się jedynie w kontekście Sprint Backlog, a wcześniej rozmawiamy bardziej o wymaganiach i “rzeczach do zrobienia”. Prowadzone projekty są określone w czasie, a rozwój produktu niekoniecznie. Odpowiedz sobie na jedno, bardzo ważne pytanie, “Po co Ci oszacowania w godzinach? ” Jeśli potrzebujesz wiedzieć co znajdzie się w kolejnym wydaniu, to weź średnie Velocity i odłóż na aktualnym Product Backlogu. Chcesz wiedzieć kiedy ukończony będzie pewien zakres funkcjonalności? Sprawdź ile to Story Points (lub Gumisiów), podziel przez średnie Velocity i wyjdzie Ci ilość Sprintów. Chcesz wiedzieć jaki budżet potrzebujesz? Oblicz ilość Sprintów i pomnóż przez całkowity koszt Sprintu. Na wszystkie pytania da się odpowiedzieć za pomocą abstrakcyjnych jednostek szacowania. I ta odpowiedź jest poparta od dowody empiryczne, więc lepsza.
Przed ruchem Agile większość pracy była kontraktowana na zasadach fixed date and scope pomiędzy biznesem i IT. Oszacowanie czasu trwania pracy było równoznaczne z wyceną budżetową projektu. Prace odbywały się w izolacji do momentu, kiedy w ustalonej z góry dacie odbywał się odbiór. Nauczone doświadczeniem IT wiedziało, że biznes o czymś nie powiedział i wymagania spuchną w trakcie pracy, więc zawyżał oszacowania. W organizacjach wymagających budżetowania i rozliczania 100% pracy trzeba było też gdzieś umieścić koszty narzutu związanego z administracją, szkoleniami i obsługą projektu. Zatem do wyceny IT dodawało narzut, lub jak kto woli podatek. Biznes o tym wiedział, więc zawsze naciskał na obniżenie oszacowania a tym samym wyceny projektu. IT zaczęło bronić się dając większe marginesy. Logiczne jest, że jeżeli ktoś ma się zobowiązać na cenę i datę, to wbuduje duże marginesy w oszacowaniach. Stosowanie jednostek czasu uruchamia stare nawyki i dotychczasowy sposób myślenia.
Stosowanie jednostki czasu do szacowania pracy niesie ze sobą pewne konsekwencje. Przede wszystkim jest to jednostka czasu, a więc coś co stosujemy na codzień do obliczania czasu trwania lub określania dat. I tak dzieje się też w przypadku szacowania. Bardzo często obserwuję w praktyce traktowania takich oszacowań jako zobowiązań. Zespół Developerski oszacował Product Backlog i wyszło, że suma oszacowań to 240 MD. Zespół Developerski współpracował z Product Ownerem w kolejnych Sprintach i dostarczał kolejne przyrosty modyfikując Product Backlog na podstawie feedbacku. Nagle jednak pojawił się P.O. i stwierdził, że 17 czerwca oczekuje końca pracy. Patrząc na Product Backlog można było wyliczyć, że jeżeli nic się nie zmieni i średnia Velocity pozostanie taka sama, to mówimy o 10 Października. Skąd P.O. wziął swój pomysł? Już na początku policzył sobie w Excelu ilość MD/ilość osób i obliczył kiedy minie tyle dni roboczych. Oczywiście zakładał, że każdy w Zespole będzie wykonywał 1MD pracy dziennie liczony jako 8h. Niestety rzeczywistość była inna oraz zmiany na Product Backlog też przyniosły pewne efekty. Nauka dla nas brzmi szacowanie w jednostce czasu staje się zobowiązaniem do daty.
Korzystając dalej z przytoczonej tutaj sytuacji przyjrzyjmy się pracy członka zespołu. Kiedy na szkoleniach prowadzonych w Polsce zadaję pytanie “Ile czasu Developer pracuje nad zadaniami ze Sprint Backlog”, padają odpowiedzi pomiędzy siedem a osiem godzin. Zwłaszcza, jeżeli w grupie mam Project Managerów. Kiedy to pytanie zadaję na szkoleniu prowadzonym zagranicą, odpowiedzi są pomiędzy cztery a sześć godzin. Z badań nad najbardziej efektywnymi zespołami wyszło, że pięć i pół godziny to maksimum. Chyba nie robili tego badania u nas ;) Zatem jeżeli Developer zaczyna pracę nad zadaniem oszacowanym na pięć godzin o godzinie 9:00 to możliwe, że skończy dopiero o 9:00 kolejnego dnia. I to jest zupełnie normalne. Gdzie podziała się reszta czasu? Kawa, potrzeby fizjologiczne, zadania administracyjne, emaile, rozproszenia, zapytania, telefony gorsze momenty we flow zabierają dużo czasu. Nie wspominając o przełączaniu kontekstu, jeżeli ktoś pracuje w więcej niż jeden zespołach lub projektach, bo w Scrum taka sytuacja nie powinna wystąpić. Tak więc można powiedzieć, że szacujemy w netto a pracujemy w brutto, lub po prostu, że szacując w godzinach, szacujemy w jednostce idealnego czasu (Ideal Time). Co oznacza oszacowanie pięć godzin Ideal Time? Jeżeli będę miał wszystko czego potrzebuję i jeżeli będę wiedział wszystkie szczegóły, i jeżeli to jest mój dobry dzień, i jeżeli nikt mi nie przeszkadza, to ta praca zajmie mi pięć godzin. Natomiast czas jaki minie od początku pracy do ukończenia zadania może wynosić osiem, a nawet więcej godzin. I to jest czas jaki minął (Elapsed Time). W tym momencie odezwą się głosy krytyki mówiące, że przecież trzeba zaraportować osiem godzin na zadaniach. Moim zdaniem raportowanie powinno wyglądać jedynie na zasadzie “Praca w Zespole Avengers 8h”. Papier lub Jira wszystko przyjmą. Raporty pracy to zupełna fikcja. Developerzy są w stanie rozwiązać skomplikowane problemy, więc dadzą radę zalogować czas na kilka zadań tak, żeby osiem godzin wyszło.
Kolejny problem jaki się pojawia przy szacowaniu w jednostkach czasu, to zależność oszacowania od konkretnej osoby. W zależności od tego, kto to będzie robił, czas będzie różny. Ile będzie trwało zbudowanie obsługi Web Service? Ja mówię, że dziesięć godzin, Kuba mówi, że cztery. Ja jestem przekonany do swojego oszacowania, on też. Sprawdzamy zrozumienie zadania i jest takie samo. Kto zatem ma rację? Oboje mamy rację. A przy siedmiu osobach szacujących jak taka sytuacja wygląda? Będzie bardzo trudno dojść do porozumienia. Jest jednak płaszczyzna, na której możemy się zgodzić. Możemy uzgodnić, że ta praca jest dwa razy większa niż inna. Element A, jest dwa razy większy niż element B. Wykonanie elementu A zajmie mi dziesięć godzin, a elementu B pięć godzin. Kubie odpowiednio cztery i dwie godziny. Czyli jeżeli umówimy się, że element B to trzy Gumisie, to element A jest wielkości sześciu Gumisiów. I co do tego się oboje zgodzimy. Na skali Planning Poker nie ma sześć, więc pewnie wybierzemy pięć, ale to już szczegół i temat na inny artykuł. W zależności kto będzie nad tym pracował, czas trwania będzie inny. A co w przypadku elementów, które potrzebują wykonania różnych elementów przez różnych Developerów. Wtedy komplikacja wzrasta i znowu dużo lepszym podejściem okazuje się szacowanie w jednostkach abstrakcyjnych. Interesuje nas na ile zespół oszacował wielkość zadania, a to nie jest suma czasu pracy poszczególnych Developerów w zależności od tego, kto będzie to zadanie wykonywał. Czas spędzony nad danym elementem można zmierzyć post-factum. Potrzebujemy jednostki, która pozwala mierzyć cały Zespół, a nie sumę indywidualności. Takimi jednostkami są jednostki abstrakcyjne takie jak klocki, Gumisie, żelki, czy Story Pointy. Oszacowanie następuje wtedy przez proste przyrównanie elementów. Abstrakcyjne jednostki nabierają znaczenia wraz z Velocity danego zespołu.
A jak mierzyć prędkość pracy Zespołu (Velocity), czy jak niektórzy mówią produktywność? Albo zapytam inaczej, jak pokazywać, które elementy nie zostały wykonane? Standardowo robi się to w ten sposób, że zalicza się jednostki dla elementów Done, a dla un-Done jest zero. Jeżeli będziemy korzystali z jednostek czasu, to wyjdzie na przykład, że Zespół ukończył 200 godzin pracy, a 60 nie zostało ukończone pomimo tego, że zalogowano w sumie 240 godzin pracy. Ktoś może zacząć drążyć co się dzieje w pozostałym czasie i naciskać na bardziej szczegółowe raportowanie każdej minuty. Mogą pojawić się pomysły optymalizacji czasu pracy tak, żeby 100% czasu było przeznaczone na pracę nad zadaniami. Co samo w sobie jest szkodliwe. I w ten sposób zachęcimy Zespół do oszukiwania. Edwards W. Deming określił, że żeby zachodziły odpowiednie interakcje w Zespole i poza nim, maksymalna ilość pracy nad zadaniami to 80%.
Skąd wiadomo jaki jest postęp pracy na Product Backlog? Product Owner będzie obliczał ile zostanie wypalone w kolejnych Sprintach i nie będzie się to zgadzało z rzeczywistym postępem. Przecież co Sprint powinniśmy kończyć określoną ilość godzin, bo wiemy ile ludzie pracują godzin dziennie. A praca w procesie empirycznym i złożonym środowisku ze swojej natury jest nieprzewidywalna.
Jak widać korzystanie z jednostek czasu wprowadza sporo komplikacji i powoduje powrót do starych nawyków. Godziny czy dni powinny być wykorzystywane do planowania Capacity zespołu i śledzenia wypalenia budżetu. Do szacowania wielkości, sprawdzania Velocity i wypalenia Product Backlogu lepiej korzystać z wybranej jednostki abstrakcyjnej.