Zespół jest coraz bardziej zirytowany, morale spadają, a interesariusze nie zadowoleni?
Brzmi znajomo? Co zrobić z takimi obserwacjami?
Przyczyn oczywiście może być wiele i zapewne jest wiele.
Jedną z pierwszych rzeczy, na jaką możemy zwrócić uwagę, jest proces szacowania wielkości zadań.
Klasycznie czy relatywnie
Pierwsze pytanie jakie powinniśmy sobie zadać, to czy w ogóle wyceniamy nasze zadania i w jaki sposób to robimy?
Generalnie szkoły są dwie. Można stosować tzw. podejście klasyczne, gdzie mówiąc ogólnie przeliczamy zadanie na konkretny czas, czy to godziny czy dni. Na plus takiego podejścia należy, przede wszystkim zaliczyć to, że jest to najbardziej naturalna metoda, nie budząca żadnych niejasności w momencie przeprowadzania oceny. Ma natomiast parę pułapek, na które należy zwrócić uwagę.
Po pierwsze, przy wycenianiu, nawet trochę bardziej skomplikowanych zadań, nie jesteśmy w stanie uwzględnić i przeliczyć na czas wszystkiego.
W momencie realizacji, rzeczywistość często brutalnie weryfikuje nasze założenia. Okazuje się, że zapominamy o pobocznych wątkach niezbędnych do wykonania zadania, lub po prostu nie byliśmy ich świadomi.
Po drugie, z reguły mamy tendencje do szacowania w idealnych godzinach czy dniach. W rzeczywistości, nigdy nie poświęcamy dajmy na to 8 godzin na pracę. Mamy przerywniki, wrzutki, kawki i inne rozpraszacze powodujące, że realny czas poświęcony na pracę jest zdecydowanie mniejszy.
Wszystko to powoduje, że w podejściu klasycznym, finalnie, często mamy tendencje do zawyżania wycen, niejako sztucznie się zabezpieczając.
Nie bez powodu najbardziej rozpowszechnionym podejściem, w branży IT, jest podejście relatywne. Które w skrócie polega na porównywaniu, np. elementów backlogu między sobą. Jeśli mamy więc 2 elementy, które według nas zrobimy w podobnym czasie, dostają one taką samą wycenę. Przechodząc przez nasz rejestr produktu i porównując jego elementy między sobą, szybko okaże się, że mamy kilka worków. Na przykład, jeden na elementy małe, drugi na trochę większe, a trzeci na największe.
Jedne zespoły stosują tzw. system koszulkowy przypisując miary S, M, L, XL, a inne zespoły stosują system punktowy (ang. Story Points), przypisując zadaniom wybrane liczby z ciągu Fibonacciego: 2, 3, 5, 8.
Oczywiście, metoda relatywna nie jest zbyt dokładna. Jest natomiast szybka i wystarczająco dobra, aby na podstawie historycznej prędkości zespołu (ang. velocity) w miarę precyzyjnie zaplanować kolejny sprint jak i planować długoterminowo.
Czy to w ogóle istotne?
No dobrze, ale czy oprócz pozytywnego wpływu na planowanie, poświęcanie czasu na wycenę zadań ma sens?
Nie będę ukrywał, że moim osobistym koronnym argumentem, który zazwyczaj przytaczam, w momencie, gdy ktoś próbuje podważać zasadność procesu estymacji jako takiego, jest fakt, że próba wyceny zadania zawsze wyzwala bardziej szczegółową i żywą dyskusje na jego temat. Bardzo często, dopiero w momencie głosowania, pojawiają się dodatkowe, trafne pytania od zespołu deweloperskiego. Warto podkreślić, że bardzo dobrą praktyką jest tajność głosowania, aby wyłapać ewentualne rozbieżności w zrozumieniu problemu. Często po odsłonięciu wyników okazuje się, że ktoś ocenił zadanie na 3, a ktoś inny na 8…
Ok, estymujemy te zadania, ale finalnie jakoś nie bardzo nam się to sprawdza. Pomimo podobnych estymacji jedno zadanie robimy szybko, a inne dużo dłużej.
Lekarstwo jest tu jedno i brzmi: zmniejszaj maksymalną, dopuszczalną wielkość zadań. Przez przytoczony problem przechodziłem jakiś czas temu w swoim zespole. Stosowaliśmy ciąg Fibonacciego w estymacjach i zdarzało się, że zadania dostawały wyceny rzędu 13 lub 21. A przekładając to na język dosłowny, w naszym przypadku, należało by powiedzieć: zadanie jest bardzo skomplikowane, ma milion zależności i nie mam pojęcia czy zajmie mi 2 dni czy 2 tygodnie. Ustaliliśmy więc wtedy, że maksymalna estymacja nie może być większa niż 8 punktów, przy czym sama ósemka jest również kandydatem do rozbicia. Dodam, że w naszym przypadku ósemka znaczy, że podobne zadania zrealizowaliśmy w przeszłości w około 3-4 dni. Takie podejście wymaga oczywiście poświęcenia zdecydowanie więcej czasu na sesje pielęgnacji rejestru produktu (ang. Refinement) i determinacji podczas rozbijania funkcjonalności, natomiast odwdzięcza się zdecydowanie większą przewidywalnością realizacji.
Czy są jeszcze jakieś korzyści ze zmniejszania maksymalnej wielkości zadań?
Owszem, i to kilka nie oczywistych.
Ustawienie górnego limitu wyceny, zmusza do wspólnego wysiłku intelektualnego, aby daną funkcjonalność sensownie rozbić. To wtedy okazuje się, co jest naprawdę ważne z biznesowego punktu widzenia i musi być dostarczone od razu (przynosi najwięcej zysku), a co może poczekać. Istnieje niezerowe prawdopodobieństwo, że wcale nie będzie potrzeby implementować kolejnych części, bo bazowa implementacja pokryje 80-90% przypadków użycia - to dopiero korzyść!
Druga korzyść wiążę się z planowaniem i morale zespołu. Jak już wspomniałem, operując na mniejszych elementach jesteśmy w stanie bardziej precyzyjnie zaplanować sprint czy też cel sprintu. Z kolei, sam development mniejszych elementów zwiększa prawdopodobieństwo ich ukończenia. Ergo, jest znacznie większa szansa, że zespół developerski ukończy zaplanowane zadania, wykonując dokładnie taką samą pracę jak zawsze i będąc dokładnie tak samo zaangażowanym jak zawsze. Po prostu nie będzie miała miejsce sytuacja, że jedno wielkie zadanie lub historyjka użytkownika przechodzi ze sprintu za sprint pozostawiając za sobą frustrację i wyrzuty sumienia u developera oraz niezrozumienie i pretensje ze strony interesariuszy. Zrealizowanie celu sprintu, powoduje wzrost morale zespołu, wiary we własne możliwości jak i chęć równie dobrego spisania się podczas kolejnej, być może bardziej ambitnej, iteracji.
Kotlety mielone
A na koniec ciekawostka, na którą natknąłem się niedawno tutaj. Rzecz tyczy się Buritto, pozwolę sobie jednak sparafrazować przykład i oprzeć go o bardziej swojskie i bliskie memu sercu Kotlety Mielone.
A mianowicie, jak zacząć szacowanie metodą relacyjną w zupełnie nowym zespole np. podczas planowania pierwszego sprintu?
Przyjmij, że 1 Story Point to 1 Kotlet Mielony (taki porządny z ziemniakami i surówką).
1 SP - Jeden kotlet mielony - jemy tyle ile normalnie zajmuje nam zjedzenie obiadu z nakryciem do stołu i pozmywaniem (czyt. Unit Testami i Code Review)
2 SP - Dwa kotlety - od biedy jesteśmy w stanie zjeść w jeden dzień (na obiad i kolacje) ale raczej rozkładamy to na dwa obiady (dwa dni).
3 SP - Trzy kotlety - umówmy się, nikt normalny nie je trzech kotletów w jeden dzień. Oczywiście jeśli bardzo chcemy i bardzo nam zależy to wciśniemy kotlet na śniadanie, obiad i kolacje. Ale normalny człowiek (nawet programista) rozkłada sobie trzy kotlety na minimum 2-3 dni.
5 SP - Pięć kotletów - na ile dni rozłożysz zjedzenie pięciu kotletów? Pewnie, na co najmniej 3-4 dni, może 5.
8 SP - Osiem kotletów - na ile dni rozłożysz zjedzenie ośmiu kotletów? Ciężko powiedzieć prawda? Mamy więc przesłanie, aby rozbić zadanie na mniejsze elementy.