Bardzo często na planowaniu różnych Sprintów, czy w ogóle iteracji, obserwuję starania mające na celu wypełnienie wszystkim w Zespole 100% ich dostępności wyrażonej w godzinach. Wkładam więc kij w mrowiska pytając: po co i co nam to da?
Suchar z autostradą
Jak się nazywa autostrada, która jest wykorzystana w stu procentach? Parking.
Ten suchar bardzo często przytaczam na naszych szkoleniach i warsztatach, gdy rozmawiamy o efektywności, planowaniu, capacity i tym podobnych tematach. Wszyscy czujemy, że próba wyciśnięcia 100% z czegokolwiek może skończyć się problematycznie. W dzisiejszym tekście zaś chodzi mi o próby zaplanowania stu procent czasu Deweloperom.
Jest to powszechna praktyka. Liczymy ile godzin każda osoba będzie dostępna w najbliższej iteracji, a na koniec Planowania Sprintu sprawdzamy czy nikt nie ma „wolnych przebiegów” albo „za dużo zaplanowane”. Problemów z takim podejściem jest co najmniej milion.
Przede wszystkim, jak ustaliliśmy w filmie pod tytułem „Czy musimy szacować wymagania?” doświadczone zespoły czują czy ich plan na Sprint da się zrealizować, czy też nie. Jeżeli z godzin wychodzi coś innego, niż oni czują, to dostosowujemy liczby do naszego instynktu. „Wpisałem tam 20 godzin i teraz mam 76 / 70? Niee no, to wpisz tam 14, dam radę.” Ile razy to słyszeliśmy?
Idąc dalej, zaplanowanie się pod korek to jak powiedzenie „doskonale wiem, co się wydarzy przez najbliższe dwa tygodnie i nie dopuszczam, że stanie się coś nieplanowanego”. Przecież to jest bzdura. Jeden kawałek pracy okaże się łatwiejszy, inny trudniejszy. Wypadnie nam wizyta u lekarza, spóźnimy się do pracy, jeden dzień przepracujemy na kacu – po co rozliczać ludzi z każdej godziny? Co to da?
100% czasu pod kontrolą
Ciemna strona niektórych rodzajów pracy to ścisły time tracking. Pracownik ma 5 minut przerwy na godzinę, jedna 15-minutowa przerwa dziennie, a wszystko to dokładnie rozpisane. Są oczywiście sytuacje, w których tak ścisłe rozliczanie się z każdej minuty ma sens, bo np. produkcja idzie bez przerwy i musimy mieć pełną obsadę przez cały czas jej trwania. Jednak w naszych realiach IT rzadko jesteśmy w takiej sytuacji.
Nie rozumiem, po co planować np. wydarzenia Scrum, przerwy lunchowe, czas na rozwój, szkolenia, etc.? To jakby pytać „Czy pojawi się jakiś ciekawy webinar, który będziesz chciał obejrzeć albo artykuł, który będziesz chciał przeczytać?” Skąd mam wiedzieć? A może akurat skończę coś wcześniej niż planowałem i potem wykorzytam ten czas na doskonalenie warsztatu? Czy naprawdę musimy to planować na Planowaniu Sprintu?
Idąc w drugą stronę, co jeśli jakieś zadania okażą się trudniejsze? Cały plan idzie w łeb bo task o ID 34536472 zajął mi 3 godziny zamiast zaplanowanej jednej? Oczywiście, że nie! To po co było całe to szacowanie tych trzech godzin?
Planowanie nieprzewidywalnego
Wybitną abstrakcją jest planowanie czasu przeznaczonego na rzeczy, których zaplanować nie potrafimy. Np. założenie, że w najbliższym Sprincie 20% czasu poświęcimy na poprawę błędów. A co, jeżeli będzie go 60%? Albo zero?
Okej, jeśli jakiś bufor zajmie nam mniej czasu niż przewidziane, to resztę czasu po prostu zużyjemy na inne rzeczy. I tu należy podkreślić, że podejście pod tytułem „jak nam zostanie czasu, to dobierzemy” nigdy się nie sprawdza. Po pierwsze, nie zostanie tego czasu, a co za tym idzie – nic nie dobierzemy. Prawo Parkinsona jest tutaj bezwzględne.
Czy w takim razie nie powinniśmy w ogóle planować rzeczy, które mogą (ale nie muszą) się zdarzyć? No cóż, jeżeli w jednej iteracji mamy 5 błędów, które sumarycznie zajmą naszemu zespołowi 10 godzin, a w drugim 74 błędy na 250 godzin, to przepraszam bardzo, ale co chcemy planować. Średnią? Przecież te dane w ogóle nie pozwalają nam zaproponować czegokolwiek!
Co innego, jeżeli faktycznie „przypadkowe zgłoszenia” i „nieprzewidziane błędy” są na tyle stabilne, że jesteśmy w stanie przewidzieć, ile tego będzie.
Przewidywanie, a nie zgadywanie
I tu dochodzimy do sedna problemu. Jeżeli faktycznie co Sprint poświęcamy 10% naszego czasu pracy na poprawę błędów produkcyjnych, obsługę zgłoszeń czy cokolwiek innego i jest to wartość stała, to faktycznie możemy się o nią oprzeć. To jak z refinementem – jeżeli zajmuje on nam ileś procent naszego czasu pracy w każdym jednym Sprincie, to możemy śmiało założyć, że w kolejnym będzie podobnie.
Tylko dokładnie to jest powodem, dla którego nie powinniśmy w ogóle przejmować się takimi rzeczami na planowaniu. Ani 10% czasu poświęconego na refinement, ani 25% czasu, który zajmuje nam poprawa błędów krytycznych i produkcyjnych. Planujmy się tak, jak co Sprint. Nie zakładajmy żadnych „buforów” czy „placeholderów”. Planujmy rozwój naszego produktu.
Obrazowo: jeżeli co Sprint planujemy średnio 20 Story Points rozwojowych (plus minus kilka) z czego dowozimy 95-100% wymagań, to po prostu tyle planujmy co Sprint. Na samym Planowaniu nie ma znaczenia, czy do tych około dwudziestu Story Points poprawiamy jeszcze 3 czy 7 błędów. Liczy się rozwój naszego produktu, resztę się „jakoś” upchnie, podobnie jak „jakoś” upychamy refinement i inne wydarzenia.
To wszystko przy założeniu, że te „dodatki” są mniej więcej stałe i zwykle zajmują podobną ilość czasu. Nie musimy wtedy niczego przeliczać na Story Pointy, ani próbować zgadywać „Ile tym razem poświęcimy czasu na rzeczy niezwiązane z realizacją wymagań?”. Załóżmy, że tyle co zwykle. I planujmy rozwój, a nie błędy krytyczne, stałe elementy gry czy czas na rozwój.
Jak zawsze wszystko sprowadza się do dwóch pytań: „Po co?” i „Co nam to daje?”.
