Skip to content

Tankuj do pełna, czyli dlaczego Sprintów się nie skraca

Nawiązanie do tematu z poprzedniego wpisu.

Sytuacja w firmie

Klient rozwija 8 produktów (serwisów WWW) mając do dyspozycji 4 zespoły deweloeprskie. Przez większość czasu każdy z zespołów pracuje nad jednym wybranym przez klienta produktem. Zespoły w większości starają się używać Scruma i pracować w Sprintach o stałej długości starając się oddać co 2 tygodnie kolejną wersję produktu.

W ten sposób można rozwijać jednocześnie 4 produkty co jakiś czas „przełączając” jeden z zespołów na inny produkt. Pozostałe czekają w tym czasie na swoją kolej. Często jednak pojawiają się tzw. „wrzuty” na kilka dni w jednym z czekających produktów. Mimo, że nie są to duże prace, to są to nowe funkcjonalności, dlatego nie mogą być wykonane w dziale zajmującym się utrzymaniem usług i bieżącym usuwaniem usterek.

Od jakiegoś więc czasu jeden z zespołów deweloperskich nie pracuje w stałych Sprintach, a na bieżąco szacuje zgłaszane przez różnych Właścicieli Produków (Product Owner) „małe projekty” i wykonuje je w ustalanej przez klienta kolejności. Czasem są to „sprinty” na 3 dni, czasem na 7 itp., a zespół działa w modelu push zamiast pull, tj. dostosowuje czas do zakresu prac, a nie odwrotnie.

Klient nie chce się zgodzić na zaproponowany system pracy, zgodnie z którym zespół, jeśli już się przełącza na inny produkt, to powinien się przełączyć przynajmniej na cały jeden Sprint (np. 2 tygodnie), a Właściciel Produktu powinien mieć na tyle aktualny Backlog Produktu, żeby zespół miał co robić podczas tego Sprintu.

W rezultacie więc zespół jest non-stop odrywany od pracy, bo ciągle musi wyceniać nowe „projekty” w różnych produktach, koszt wynikający z częstego przełączania się między produktami rośnie (od 1 do 1,5 dnia z 3 zaplanowanych na pracę zajmują ustalenia z Właścicielami Produktów, szacowanie, merge kodu, przegrania na produkcję itp.), osoba od klienta pełniąca rolę Chief Product Ownera (czyt. pilnująca harmonogramu tego zespołu) marnuje godziny na negocjacje z Właścicielami Produktów oraz ustalanie, co i w jakiej kolejności będzie robione.

Klient postrzega całą sytuację jako jeszcze większą elastyczność niż daje Scrum. Nie widzi potrzeby delegowania całego zespołu na całe 2 tygodnie tylko dla jednego z produktów, kiedy przecież w kolejce czekają inne drobne zmiany w pozostałych produktach. Stałe długości Sprintów postrzega jako ograniczenie elastyczności zespołów.

Dlaczego to jest złe i niewydajne? Posłużmy się analogią z życia.

Tankowanie paliwa

Zawsze tankuję do pełna, bo dzięki temu marnuję swój czas na stacji paliw tylko dwa-trzy razy w miesiącu. Owszem, zatankowanie 55 litrów trwa dłużej niż 5 litrów, ale to nie w oczekiwaniu, aż się zaleje paliwo, traci się najwięcej czasu. Więcej czasu się traci na zjechanie do stacji, czekanie w kolejce, płacenie i inne czynności, przez które postój na stacji rzadko trwa krócej niż 10 minut.

Dziwią mnie osoby, które tankują 5 litrów albo „za 20 złotych”. Nie wyobrażam sobie tankowania co 2-3 dni. To całkowicie nieracjonalne.

Nie potrzebuję też większego baku ani nie wożę kanistrów z zapasem paliwa, bo zabrakłoby mi miejsca w bagażniku, a auto byłoby za ciężkie. Nie jeżdżę TIR-em.

Bieżące potrzeby biznesu

No dobra, ale co, jeśli ktoś akurat nie ma przy sobie wystarczającej ilości gotówki, ale musi akurat pojechać nieduży kawałek? Raz może zrobić wyjątek i zatankować tyle, ile można. Jeśli jednak tak dzieje się niemal codziennie, to… być może ciągły brak gotówki jest wynikiem marnotrawstwa czasu przez zbyt częste wizyty na stacjach.

Categories: Sprint.

Comment Feed

No Responses (yet)



Some HTML is OK

or, reply to this post via trackback.