Często podczas warsztatów dotyczących Flow Management i Kanban, jak i podczas pracy z zespołami i kadrą zarządzającą klienta zwłaszcza, gdy omawiamy metody umożliwiające znalezienie wiarygodnych odpowiedzi na pytania:
- Jakie jest tempo pracy zespołu?
- Ile zespół może zrobić w określonym czasie, np. w iteracji (sprincie) lub w ciągu tygodnia?
- Na kiedy projekt lub moduł (składający się z pojedynczych prac) będzie zrobiony ?
pojawia się kwestia wielkości zadania/pracy.
Dużo pytań budzi prezentowane przeze mnie podejście – związane z Flow Management i Kanban - mówiące o tym, że dla odpowiedzi na powyższe pytania, wielkość pracy nie ma znaczenia i że jednostką, jaką możemy się posłużyć jest po prostu liczba zadań zrealizowanych w określonym czasie, a metryką przepustowość (ang. throughput), a nie dość powszechnie stosowane w świecie zwinnym punkty (tzw. story points) i prędkość (ang. velocity).
Wyjaśnienie tych wątpliwości wymaga nakreślenia szerszego kontekstu, czyli przede wszystkim celu stosowania omawianych tu podejść, jakim jest znalezienie wiarygodnych odpowiedzi na pytania z pierwszego akapitu.
Dlaczego więc wielkość zadania nie ma znaczenia?
I dlaczego w konsekwencji stosowanie punktów i prędkości rodzi poważne problemy praktyczne w większości sytuacji?
Po pierwsze: w wielu sytuacjach jest mała korelacja oszacowania zadania w puntach i czasu wykonania (ang. lead time). Przekonać się o tym można choćby realizując proste symulacje zaproponowane przez Troya Magennisa na: https://observablehq.com/@troymagennis/story-point-velocity-or-throughput-forecasting-does-it-mat?collection=@troymagennis/agile-software-development lub po prostu zbierając i analizując dane w zespole dotyczące wielkości zadania w punktach i ich czasach realizacji.
A te sytuacje związane są z następującymi – w środowisku wytwarzania oprogramowania występującymi powszechnie - czynnikami:
- Dużym poziomem prac w toku (WIP)
- Znacznymi kolejkami i długim czasem, jaki zadania spędzają w kolejce w stanie oczekiwania
- Różnego typu problemami i blokerami, powodującymi, że praca stoi i czeka lub wymaga poprawek i/lub uzupełnień
Wszystkie one dotyczą środowiska z małą efektywnością przepływu, czyli stosunkiem czasu rzeczywistej pracy do sumarycznego czasu realizacji zadania, obejmującego zarówno czas pracy, jak i czas oczekiwania. Często ta efektywność przepływu wynosi 5-10% co oznacza, że 90-95% czasu praca spędza w stanie oczekiwania.
I to jest kolejny powód tego, że do oszacowania w punktach trzeba podchodzić z rezerwą. Bo przecież szacujemy czas pracy, nie biorąc pod uwagę czasu oczekiwania, czyli właśnie tych 90-95% czasu.
A uogólniając można powiedzieć, że czynniki systemowe – jak te wymienione powyżej - wpływające na czas realizacji i na opóźnienia mają dużo większe znaczenie i wpływ niż samo zadanie. To tak, jak z opóźnieniem lotu: zależy ono od czynników systemowych (pogoda, strajk kontrolerów, zbyt duży ruch w rejonie docelowym), a nie zależy od długości lotu.
Po prostu nie jest tak, że dostarczenie pracy 5 razy większej zajmie 5 razy więcej czasu. W świecie VUCA, dużej złożoności i nieprzewidywalności – a taki charakter ma tzw. knowledge work i wytwarzanie oprogramowania - takie proste liniowe zależności po prostu nie występują.
Podsumowując: wielkość pracy nie ma – w najczęściej spotykanych w praktyce kontekstach – znaczenia. Tym samym można do określenia przepustowości stosować „sztuki” zadań i nie trzeba szacować zadań w punktach i porównywać sumy punktów z prędkością dla uzyskania odpowiedzi na pytanie ile pracy (zadań) można zrobić w iteracji lub określonym odcinku czasu.
Prawo Little’a i sztuki
Kwestia tych „sztuk” zadań (prac) jako jednostki pojawia się także w Prawie Little’a, czyli formule:
Średnia Przepustowość = Średni poziom prac w toku / średni czas realizacji
opisującej zależności związane z przepływem pracy w systemie, jakim może być przykładowo proces wytwarzania oprogramowania, lub każdy inny proces biznesowy, w którym mogą występować fazy prac (np. analiza, programowanie, testowanie).
W powyższej formule Prawa Little’a także wykorzystywane są jako jednostki „sztuki” zadań/prac. Rodzi się więc znowu pytanie: czy wielkość tych zadań/prac faktycznie nie ma znaczenia?
Odpowiadam: nie, nie ma znaczenia, bo:
- Prawo Little’s– jak widać z powyższej formuły – dotyczy zależności między średnimi. Czyli nie interesują nas konkretne, poszczególne zadania/prace, lecz właśnie średnie zależności między poszczególnymi parametrami dla zbioru zadań/prac
- Różna wielkość zadań nie wprowadza takiego poziomu zmienności, jaka wpływa mocno na przewidywalność dostarczania. Bo w praktyce problemy z przewidywalnością wynikają z czynników omówionych wcześniej, tj. z:
- Zbyt dużego poziomu prac w toku
- Częstotliwości naruszania założeń prawa Little’a, mówiących przykładowo o takim samym tempie zasilania systemu pracy zadaniami, jak tempie wychodzenia ukończonych zadań z tego systemu oraz o zbliżonym poziomie starzenia się zadań w trakcie pracy nad nimi.
Problemy te można stosunkowo łatwiej rozwiązać niż w sposób arbitralny ustalić, by zadania/prace były tej samej wielkości, o czym napiszę już za chwilę.
Gdy więc za pomocą powyższej argumentacji uda mi się wyjaśnić kwestię stosowania szacowania zadań w punktach, czyli wielkości pracy, to natychmiast pojawia się kolejne pytanie: a czy do stosowania jako jednostki „sztuk” zadań nie jest wymagane, by te zadania były tej samej wielkości?
Moja odpowiedź to: nie, nie jest wymagane by te zadania były tej samej wielkości, czyli nie chodzi o tzw. same-sizing, tylko o „right-sizing”, o właściwą wielkość zadania. Więcej o tym „right-sizing’u” przeczytacie w innym moim tekście: „Rightsizing” co to takiego?” na: https://www.jsproject.pl/wiedza/kanban/984-rightsizing
Pozostaje teraz drugi element tytułu tekstu, czyli przepustowość i jej praktyczne zastosowanie w świecie zarządzania pracami i projektami. Przeczytacie o niej w tekście "Przepustowość".
