Planowanie dostępności zespołu, czyli Capacity Planning, to w wielu zespołach rzecz zupełnie nieznana. I chociaż nie zawsze i wszędzie będzie ono w ogóle potrzebne, to zobaczmy jak Capacity Planning może wspomóc nasze zwinne życie.
Najważniejsze – po co?
Na naszym zwinnym blogu mamy już ponad trzysta tekstów, więc prawie zawsze możemy powiedzieć, że „o dzisiejszym bohaterze już pisaliśmy”. Nie inaczej jest w przypadku Capacity. Jednak zawsze znajdzie się kilka słów, które jeszcze można by dopisać i porad, których można by udzielić. To, co czekało do dziś, to odpowiedź na pytanie, jak wyznaczyć Capacity?
Wróćmy na chwilę do celu. Jednym z istotnych elementów zaplanowania każdego Sprintu jest ustalenie Capacity naszego Zespołu. Część o tym zapomina, część planuje się „na czuja”, a inni świetnie sobie radzą bez tego. I dopóki nie wystąpią problemy z niezrealizowanym zakresem Sprintu, nie jest to dla nas tak istotna sprawa. Ale kiedy pierwszy, czy drugi raz pojawia się problem ze spadami, często pojawia się pytanie „A ile wynosi nasze Capacity”?
Capacity, w przeciwieństwie do Velocity, to miara dotycząca przyszłości. Weryfikując deklarowaną dostępność członków naszego Zespołu odpowiadamy sobie na pytanie, jak dużo wszyscy jesteśmy w stanie z siebie dać w kolejnym Sprincie. Naturalnie pojawiającym się pytaniem „Jest jak dużo czego?” Godzin, dni (i lat…), a może Story Points? Nie ma to żadnego znaczenia, zresztą jak już pisaliśmy sam Scrum Guide nie reguluje kwestii miary oszacowania.
Co nam daje Capacity Planning?
Planując Sprint chcemy zderzyć ze sobą dwie kwestie: dostępność Zespołu kontra aktualne potrzeby naszego Klienta. Szukamy odpowiedzi na pytanie, czy istnieje możliwość „upchnięcia” najważniejszych elementów w kolejnych dwóch tygodniach. Zakładając, że Sprint trwa dwa tygodnie. Bez weryfikacji Capacity, odpowiedź często brzmi „oczywiście, że tak”. Jednak bardzo często wynik tego Sprintu jest również z góry możliwy do przewidzenia.
Zdarza się, że chcąc zmieścić wszystko w dostępnym Capacity następuje challengowanie wymagań. Nagle okazuje się, że są one proste, nie zajmują dużo czasu, a tak w ogóle to my już to zrobiliśmy. Mówiąc inaczej, „ktoś” przekonuje osoby wykonujące pracę, że jest ona prostsza niżim się wydaje. To jest negatywny skutek sytuacji, w której zdaliśmy sobie właśnie sprawę, że dostępny kapitał ludzki (nie zasoby) są mniejsze, niż ilość pracy, którą mamy do wykonania.
Pozytywnym aspektem tej sytuacji może być poszukiwanie MVP. W momencie, kiedy zorientowaliśmy się, że nasze zasoby są niewystarczające do zaspokojenia naszego apetytu, poszukamy nowego zakresu naszego Produktu. Operujemy zatem zakresem, tak aby na samym końcu spowodować takie same zadowolenie klienta z naszego Produktu. Może będzie on trochę prostszy, może trzeba będzie część rzeczy zapisać na kartce. Ważne jest jednak, że będzie.
Mechanika – MD
Mechanika Capacity Planning uzależniona jest od miary, którą posługujemy się, szacując nasze wymagania. Jeżeli w ogóle nie korzystamy z oszacowania elementów Backlogu, to możemy naprawić teraz ten błąd teraz i skorzystać np. ze Story Points. Jeśli korzystamy z jakieś miary, pozostaje nam dokonać prostego obliczenia. Jedni wykonają je w dniach (MD) inni w Story Pointach (SP).
Korzystający z MD sporządzą kalendarz dostępności, a następnie zsumują ilość dni, podczas których obecni są członkowie naszego Zespołu. Czy to nam coś daje? Totalnie nic. Na początku musimy zderzyć to z wymaganiami zaplanowanymi do realizacji w nadchodzącym Sprincie. Zauważycie bardzo szybko, że rzadko kiedy są one wyceniane w MD (choć czasem się zdarza), a dużo częściej w godzinach. Wystarczy więc zsumowaną ilość dostępnych MD pomnożyć przez 8. Działanie to pokaże nam ilość dostępnych godzin per Sprint. Jest to jednak mrzonka. Ilość „aktywnych” godzin, podczas których aktywnie pracujemy jest dużo mniejsza.
Jak widzicie, w powyższym przykładzie dużo jest założeń. W dodatku zupełnie pomijamy fakt zależności, zastępowalności w zespole i potencjalnych bus factorów.
Mechanika – SP
Skoro MD nie dają rady, to może punkty? Tutaj, przynajmniej w założeniu, powinno być prościej. Ustalmy, że każda osoba z naszego Zespołu jest w stanie zrealizować X punktów dziennie. Załóżmy, że dla naszego przypadku X=1 (całkowicie przypadkowo jest to zbieżne z założeniami jednej z metodyk). Następnie policzmy ile pełnych dni dewelopmentu przed nami i pomnóżmy ilość dni dostępnych (dla wszystkich członków naszego zespołu) przez… 1. Zakładając, że nasz Zespół liczy 6 członków a sprint trwa 10 dni = 6 x 10(*) x 1 = 60 SP. Prościej, jeśli wymagania wycenione mamy w SP, trudniej, jeśli w innej mierze.
Skąd wiem, że 1 deweloper jest w stanie zrealizować dziennie 1 SP? Możemy przyjąć takie założenie (i weryfikować jego prawidłowość), możemy też wyliczyć sobie to prostym równaniem. Velocity z 5 ostatnich Sprintów podzielone przez ilość dostępność członków Zespołu w tym czasie da nam średnią. Wartość tę podstawimy do wzoru.
Oczywiście do tematu możemy też podejść empirycznie i spojrzeć wstecz, na takie Sprinty, w których nie był dostępny pełen skład. Tylko szanse na to, że trafimy dokładnie na tę samą konfigurację dostępności co teraz są niskie. W dodatku, żeby wyciągać jakieś sensowne wnioski, potrzebujemy więcej danych niż n = 1.
(*) Metodyka, o której wspominam nakazuje policzyć jedynie pełne dni dewelopmentu. W takim przypadku pomnożylibyśmy to przez osiem.
Czy Capacity Planning ma sens?
Dobre plany mają to do siebie, że często zaraz po ich ustaleniu stają się nieaktualne. Zgodzę się z twierdzeniem, że plan projektu, wykonywany na wiele miesięcy czy lat w przyszłość jest bezcelowy. Ten sam plan, dokonywany w kontekście Capacity naszego Zespołu pewnie będzie uważany przez Was za równie bezcelowy. Tak jednak nie jest.
Diabeł jak zwykle tkwi w szczegółach. Jest różnica pomiędzy planowaniem 12 miesięcy, a 2 tygodni. Ilość nieprzewidywalnych elementów i zdarzeń, które mogą nas zaskoczyć w przeciągu roku jest nieproporcjonalnie większa, niż te same elementy, które mogą pojawić się przez kolejne 2 tygodnie. Mówiliśmy o tym wielokrotnie, ale powtórzymy to po raz kolejny: planowanie na bardzo krótki okres, mimo, że też obarczone ryzykiem jest o wiele lepszym pomysłem, niż dalekosiężne wyobrażenie na temat naszego celu.
Jak widać powyżej, nie ma idealnego sposobu na Capacity Planning. Dla jednych lepszym rozwiązaniem będzie planowanie w MD i obliczanie Capacity w tej mierze, inni wybiorą SP. Jeszcze inni będą używać „metody eksperckiej”. Najważniejsze aby wybrać taki sposób, abyśmy mogli Capacity wyliczyć i aby Zespół widział w tym sens i korzyść. Bo inaczej po co to wszystko?
Mam dane historyczne, tj. Capacity (z kalendarzem dostępności, a właściwie procentowy stan dostępności) i Velocity. Normalizuję dla każdej iteracji Velocity, tak, żeby było teoretyczną wartością dla sytuacji, w której mielibyśmy 100% Capacity. Biorę takie (yesterday weather) średnie znormalizowane Velocity z ostatnich kilku iteracji mnożę przez rzeczywiste Capacity przypadające na iterację i mam informację ile teoretycznie wziąć pracy.