Battle for Agility

Ile zespołów tyle podejść do szacowania. Czy to źle?

Jakiś czas temu pisałem na blogu tinyPM o tym czy szacowanie zadań w obrębie user stories w ogóle jest zasadne (Are you brave enough not to estimate your tasks?). Dzisiaj chciałbym podsumować w formie artykułu moją niedawną rozmowę z Marysią na temat estymacji i jej różnych wcieleń.

Zacznijmy trochę od końca (przynajmniej z mojego punktu widzenia) czyli od Scrum’a i burndown’u robionego na bazie pozostałej na dany moment pracochłonności zdań. W Scrum zalecane jest oszacowanie zadań na początek (w godzinach) i prowadzenie dziennika, w którym Scrum Master zapisuje informacje od członków zespołu, ile dane zadanie im zajęło w danym dniu i ile myślą, że jeszcze zostało. Tak każdego dnia, aż zadanie zostanie wykonane.

Co daje taka metoda? Początkowe szacowanie pozwala zorientować się czy zespół nie przeholował z deklaracją ile może faktycznie zrobić. Potem w ciągu trwania sprintu tworzony jest wykres na bazie sumy czasów pozostałych dla wszystkich zadań. To daje obraz tego co sądzi w danym momencie zespół na temat pracy jaka została jeszcze do wykonania. Ta suma może w danym dniu przewyższać estymację z dnia poprzedniego lub nawet początkową estymację co oznacza, że napotkaliśmy problemy, lub nie przewidzieliśmy jakiś zadań, których wykonanie jest konieczne do ukończenia user story.

Na koniec sprintu kończymy z zadaniami, które są powiązane z dwiema liczbami. Pierwotną estymacją oraz faktyczną sumą czasu spędzonego nad zadaniem. Daje nam to porównanie jak trafne są nasze oceny z początku sprintu. Dążymy oczywiście do tego, aby z czasem te dwie liczby okazywały się zbieżne :-)

A teraz do sedna. Po co nam takie śledzenie zadań? Czy nie da się prościej?

Szacowanie zadań wynika tak faktycznie z dwóch potrzeb:

Potrzeba nr 1
Mamy długą iterację. Np. 30 dni wg klasycznych zaleceń Scrum, a chcemy jak najdokładniej wiedzieć czy mamy jakiś problem z wykonaniem tego co w iteracji zadeklarowaliśmy. Chcemy to wiedzieć na bieżąco i chcemy wiedzieć czy idziemy dobrym kursem czy nie.

Potrzeba nr 2
Chcemy być w stanie ocenić to jak nam idzie szacowanie. Czy się mocno mylimy i w jakich sytuacjach najmocniej a w jakich najrzadziej.

I teraz każdą z tych potrzeb można zaspokoić na co najmniej kilka znanych mi sposobów, ale zależy to od przyjętej praktyki.

Małe user stories dające się ukończyć w ciągu jednego dnia. Bez podziału na zadania.

Jeśli stosujemy małe user stories, których realizacja nie ciągnie się przez całą iterację, to nie potrzebujemy w ogóle zadań ani ich estymacji bo burndown po ukończonych user stories zmienia się często i jest całkiem dokładnym odzwierciedleniem postępów zespołu. Jeśli dodatkowo user stories oszacowane są w punktach, to stwierdzenie, że ukończyliśmy w danym momencie 3 z 8 punktów daje nam całkiem dokładną informację o tym, w którym punkcie się znajdujemy.

Jeśli chodzi o dokładność szacowania, to wystarczy rejestrować czas pracy spędzony nad poszczególnymi user stories. Ocenę trafności szacowań da analiza informacji ile czasu średnio zajmują nam historyjki 1-punktowe, ile 2-punktowe itd. Okazać się może wtedy, gdzie mamy największe odchyłki. Należy się zastanowić z czego wynikają, aby uwzględnić to w kolejnym szacowaniu.

Większe user stories przy krótkich iteracjach.

Jeśli nasze user stories są zwykle większe i ich ukończenie zajmuje blisko całą iterację, to burndown po stories praktycznie nic nie mówi, bo przez całą iterację nic się nie dzieje a na koniec mamy skok i zaskoczenie.

W takiej sytuacji naturalną reakcją jest rozbicie user stories na zadania. Przy czym zadania tracą między sobą cechę porównywalności.

Można user stories rozbić na zadania nie większe niż jednodniowe, wtedy na poziomie zadań osiągniemy stan taki jak w poprzednim punkcie na poziomie stories. Można takich zdań nie estymować (skoro są wykonalne w ciągu jednego dnia), bo dokładność ruchów na wykresie będzie zadowalająca. Można powiedzieć ze skoro wykonaliśmy 12 z 25 maksymalnie jednodniowych zadań to jesteśmy mniej więcej w połowie pracy i porównać to z momentem iteracji.

W tym przypadku również bardziej interesujące wydaje się badanie jak nam idzie szacowanie user stories a nie zadań (których jeszcze nie zaczęliśmy estymować).

Długa iteracja i kilka naprawdę dużych user stories.

Przy np. 30 dniowej iteracji i user stories, które i tak zajmują prawie cały ten okres (iteracja zawiera np. 2-3 takie historyjki) dochodzimy do stanu w którym user stories tracą znaczenie z punktu widzenia śledzenia iteracji. Koniec jest zbyt odległy aby można sobie pozwolić na brak bieżącego i rzeczywistego obrazu tego jak nam idzie. Reakcja po 30 dniach może być zbyt późna.

Tutaj pojawia sie potrzeba estymacji zadań i potrzebujemy do tego jednostki, którą nadal można porównywać (np. godziny lub tez punkty). Z punktami jest ten problem, że ciężko rozbić story oszacowanego na 3 punkty, na 5 zadań i je także oszacować w takich samych punktach które w sumie dadzą 3.

No to może w godzinach… bliskie to wszystkim programistom. Ale jak wiemy, mocno się różnimy w szacowaniach godzinowych. Więc co z tego ze coś szacowaliśmy na 8 godzin, skoro w takcie miesiąca okazuje się: “oj pomylilem sie, to zajmie wiecej bo jeszcze musimy…”, itp.

Stąd pomysł ze Scrum na prowadzenie dziennika z czasem pozostałym do wykonania. Ta technika niweluje niedokładność szacowań godzinowych przy długich sprintach i ciągnących się przez wiele dni zadaniach. Codziennie mamy najbardziej rzeczywisty obraz stanu projektu.

Informacja o czasie pozostałym do wykonania nie daje nic jeśli chodzi o weryfikację estymacji po ukończeniu iteracji. Wtedy również istotny jest czas faktycznie spędzony nad zadaniami.

Można też spróbować weryfikować średnie czasu w grupach user stories szacowanych na tyle samo punktów. Ale przy długich iteracjach i dużych stories dokładność szacowania user stories bardziej zaczyna interesować samego właściciela produktu na poziomie planowania wydań. Zespół programistów bardziej obchodzą dokładności na zadaniach, bo w porównaniu do pierwszego punktu, to zadania zaczynają spełniać tę samą rolę co tam małe user stories.

Po co ten cały wywód?

Otóż wciąż często spotkam się z twierdzeniem, że do dobrego planowania potrzebujemy dokładnie takiego sposobu śledzenia zdań jak to proponuje Scrum, czyli szacowania zadań w godzinach, codziennego śledzenie czasu spędzonego i pozostałego na każdym zadaniu.

Tymczasem twierdzę, że tak faktycznie nie ma się co przywiązywać do tej metody, bo została ona opracowana z właśnie po to, by dać odpowiednią dokładność przy sprintach 30 dniowych i kilku dużych user stories wykonywanych w trakcie sprintu.

Natomiast coraz częściej obserwujemy zmianę w preferowanej długości iteracji i skracanie jej do 7 lub 14 dni. Także user stories są często dużo mniejsze niż początkowo zakładał Scrum czy XP. Dlatego zawsze należy dobrać narzędzia i środki do aktualnych warunków, bo być może to samo da się osiągnąć w dużo prostszy sposób.

Ja preferuje podejście na granicy pierwszego i drugiego i czyli iteracją 14 dniowa, małe stories z zdaniami dającymi się wykonać w ciągu jednego dnia. Tym samym interesuje mnie szacowanie user stories w punktach. Nie szacuję zadań. Natomiast śledzenie rzeczywistego czasu wykonania zdań, a w efekcie całego story, może dawać interesujący materiał do przemyśleń.

I jeszcze na koniec odsyłam do dobrego artykułu Mike’a Cohna na temat relacji user stories i ich faktycznego czasu wykonania: How Do Story Points Relate to Hours?

A wy którą metodę preferujecie / stosujecie?

Add comment February 22nd, 2010