Osobiście uważam, że planowanie w punktach "pracochłonności" to też jakaś bzdura, bo znajomość projektu w zespole nie musi się rozkładać równomiernie. Nie czytałem przy tym SG, więc mogę pomijać założenia, ale z mojej perspektywy, jeśli cele nie zostały osiągnięte, po prostu po winna się pojawić dyskusja pt. "Co poszło nie tak" i na bazie tego powinny zostać podjęte odpowiednie kroki. Ma to sens? Bo ja dotąd z "książkowym scrumem" to się spotkałem tylko raz, reszta to takie "custom kanban" i to podejście (z reguły) działało lepiej.
Teraz będę trochę pisał jak ten gość z mema, którego wkleiłem parę postów wcześniej. SP, to nie jest jednostka pracy,. pracochłonności, złożoności. W sumie to nie jest żadna dająca się zdefiniować jednostka. Ponieważ po dość długim czasie ogarniania o co w tym chodzi, chyba doszedłem do momentu, w którym rozumiem, to się podzielę, bo nie podzieli się tym z wami żaden ScrumMaster po politologii, czy innej kosmetologii.
Właściwie, to wystarczyłoby liczyć ile tasków średnio zespół ogarniał w jednostce czasu. Jeżeli taski będą podobne, to i liczba zamkniętych tasków w okresach, dajmy na to 2 tygodniowych będzie zbliżona. Ale wiadomo, że taski są różne, więc jeżeli do prawidłowo zdefiniowanych tasków, czyli takich, w których wiadomo co ma zostać zrobione poprosi się zespół o podanie czy ten task jest mniejszy, większy czy taki zwykły, nada tym odpowiedziom wartości liczbowe, to uzyska się trochę lepszą stabilność wyników/przewidywalność. Czyli zbieramy zespół, mówimy, że np. 1sp to takie najmniejsze możliwe do wyobrażenia zadanie, 3 to takie "zwykłe" itd, Właściwie nie ma znaczenia od czego się wystartuje, ważne jak się kończy, jak zwykł mawiać pan premier. A kończy się to tak, że ludzie w zespole po jakimś czasie nadal nie wiedzą, czym ten story point jest, ale potrafią wycenić zadania w miarę jednomyślnie w SP. W tym momencie wystarczy już jedynie wyciągać średnią prędkość za ostatni okres(y), i jesteśmy w stanie szacować ile i jakiej roboty zostanie dowiezione.
Żeby to działało, trzeba spełnić kilka warunków:
-
kazać się zamknąć ambitnemu team leaderowi, który nadal wszystko by tylko szacował nisko, bo "przecież to łatwe", może dla niego i owszem, ale nie dla reszty zespołu, która nie potrafi przeczytać jego "clear code"
-
nie rozliczać zespółu z "commitmentów" i innego g...a, w tym również pozytywnie "o jaki piękny burndown chart wam wyszedł"
-
nie urządzać dramatów, że "się czegoś nie dowiozło"
-
robić retrospektyw z pytaniem "dlaczego się czegoś nie dowiozło"
-
nie rozliczać pracowników z liczby przepalonych story pointów
-
trzymać z dala od zespołu, wszystkich, którzy mają jakieś wąty
-
odrzucać zadania, które trzeba jeszcze uszczegółowić, albo rozpisać
Jeżeli się tych warunków (i pewnie wielu innych) nie spełnia, to SP staje się naprawdę nic nie znaczącą jednostką. Jeżeli się ich przestrzega, to jesteśmy w stanie powiedzieć "OK, za c.a. 4 tygodnie będzie zrobione, chyba, ze nie będzie".
Do tego trzeba trochę kanbana mieć - taski muszą być ułożone pod względem pilności. Jak coś jest ważne/pilne, to powinno być robione przed tym, co jest mniej ważne/pilne - wydawałoby się oczywiste, a jednak nie jest. Trzeba też traktować zespół jak dorosłych, znających się na swojej robocie ludzi, a nie bandę wyrobników kopiących od kołka do wieczora.
