Capacity Planning to proces, który wiele zespołów niestety pomija. Są takie, które rzeczywiście go nie potrzebują. Jednak większość nawet nie zdaje sobie sprawy, jak dużo traci. Szczególnie jeżeli mówimy o złożonych produktach z wieloma współzależnościami. Spójrzmy więc, czy jest Capacity Planning oraz co nam daje.
Zwinne Planowanie
Agile Manifesto twierdzi, że reagowanie na zmiany jest ważniejsze niż przestrzeganie planu. To wcale nie znaczy, że nie powinniśmy planować. Wręcz przeciwnie! Twórcom zwinnego manifestu chodziło o to, że ludzie często mylą mapę z terenem i stawiają na dociśnięcie planu, kiedy ewidentnie nie jest to najlepsza decyzja. Natomiast zwinne planowanie umożliwia nam, po pierwsze, mieć jakąś przewidywalność tam gdzie to jest możliwe, a po drugie reagować na nieprzewidziane okoliczności kiedy to jest koniecznie.
Zasady zwinnego planowania są proste: chcemy ustalić jakiś realistyczny cel, który chcemy osiągnąć. Potem wyznaczyć kroki, które musimy wykonać, żeby go osiągnąć. Jednocześnie musimy wziąć pod uwagę prędkość, z którą możemy te kroki wykonywać oraz zobaczyć, jakie warunki na nią wpłyną. Może się okazać, że kroków będzie więcej (lub mniej), niż się spodziewaliśmy. Albo, że niektóre z nich trzeba będzie zamienić na inne. Właśnie ten ostatni punkt sprawia, że nasz plan nie rozsypie się przy zderzeniu z rzeczywistością.
Capacity (Planning)
Jedną z rzeczy, która umożliwia nam zwinne planowanie jest Capacity. To nic innego, jak miara, która wskazuje, ile pracy możemy wziąć na siebie per iterację. Wywodzi się ona, po pierwsze, z Velocity – miary, która pokazuje, ile historycznie zespół dowoził. W Capacity musimy jednak uwzględnić inne warunki, takie jak dostępność członków zespołu oraz ilość dni roboczych.
Opierając się o Capacity, będziemy wiedzieli, czy możemy dodać jeszcze jakieś wymagania do naszego Sprintu, czy już dosyć. Również w przypadku, kiedy musimy zmienić zakres Sprintu, to właśnie Capacity pomoże nam stwierdzić, czy te zmiany da się realistycznie realizować.
Szacowanie Capacity
Rzeczą, która umożliwia korzystanie z Capacity jest szacowanie. Jeżeli nie wyceniamy naszych wymagań, to nie wiemy, które z nich jest duże czy małe, ani nie mamy pojęcia na ile stać nas per iterację. Czyli, bez szacowania nie ma ani Capacity, ani Capacity Planning.
W temacie szacowania często powstają debaty czy wyceniać w Story Pointach (SP) czy w Man Day’ach (MD). W pierwszym przypadku nasze Capacity będzie zawierało pewną ilość SP, na przykład 50 albo 100. W tym drugim będzie to ilość dni roboczych pomnożona przez ilość członków zespołu. Teoretycznie. A teraz spójrzmy na pewien problem.
Trudno jest oszacować capacity w MD w sensowny sposób: jedno wymaganie może wymagać od 1 do 3 godzin, drugie od jednego do 3 dni i tak dalej. I co będzie, jak okaże się, że nasze Velocity to 45 MD, a mamy dwutygodniowy Sprint dla 5-osobowego zespołu? Przecież miało być 50! Dlatego szacowanie relatywne w zespołach zwinnych sprawdza się po prostu lepiej.
Capacity Planning
Znając nasze Capacity wynoszące X Story Points per Sprint, możemy zacząć dodawać do Backlogu Sprintu wymagania, które zespół wcześniej wycenił. W taki sposób ułożymy sobie realistyczny plan. Jeżeli powstaną jakieś wrzutki, zespół powinien je również oszacować i wtedy zobaczyć, na ile jest możliwe, aby się nimi zająć. Nie dzieje się to jednak „metodą ekspercką”, a opieramy się, oczywiście, na Capacity.
Może też się okazać, że nie mamy już przestrzeni na dodanie czegoś, lecz wrzutka jest priorytetowa. Wtedy musimy zrezygnować z czegoś, co wrzuciliśmy do naszego planu na początku. Jak widzimy, Capacity Planning mocno ułatwia zarządzaniem zakresu prac. Ale do sukcesu potrzebny jest jeszcze jeden proces, który koniecznie musimy omówić.
Refinement Backlogu, a Capacity Planning
Zdolność zespołu do trafnego szacowania wymagania jest bezpośrednio uzależniona od jakości definicji tych wymagań. Jeżeli są opisane zbyt ogólnie, albo po prostu nie są przemyślane, a wszystkie detale będą wychodzić “w praniu”, to nasz plan nigdy nie będzie realistyczny. Będzie to wyglądało tak, że zespół bierze jakąś User Story, która wydaje się nie być zbyt złożona i wycenia ją na 13 SP. W procesie pracy wypływa mnóstwo faktów, które bez problemu można było rozpoznać wcześniej, gdybyśmy tylko zajęli się tym wymaganiem tak jak należy. Teraz okazuje się, że to już nie 13 SP tylko 21. I cały nasz plan traci sens.
Wniosek jest taki, że chcąc czerpać wartości z Capacity Planning musimy zadbać o porządny Refinement Backlogu.
Kto potrzebuje Capacity Planning?
Capacity Planning jest mało wartościowe dla zespołów wykonujących głównie wsparcie i maintenance w trybie Kanbanowym. Jest natomiast bardzo potrzebne tym zespołom, które mają do czynienia z wieloma współzależnościami. Na przykład, jeżeli działamy w którymś ze skalowalnych modelów Scruma.
Choć sam Podęcznik Scruma wypowiada się przeciwko planowaniu długoterminowym, to jednak szacowanie do przodu jest absolutnie niezbędne w wielu dziedzinach. Powinniśmy wiedzieć, czy jest realistyczne spodziewać się dowiezienia czegoś za 3 miesiące, czy raczej za pół roku. To Capacity Planning pozwoli nam, żeby długoterminowe cele były konkretnymi celami, a nie życzeniami bądź marzeniami.
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.