Odcinek 40. Ile zajmie nam ten… projekt, czyli podróż do Monte Carlo

Zespoły i organizacje nie są zgodne, co do tego, jak estymować czasochłonność pojedynczych zadań. Jeszcze większe wyzwanie stanowi próba określenia tego, kiedy można spodziewać się dostarczenia całego projektu, wersji czy inicjatywy. Łatwo jest wpaść w pułapkę prób określenia każdego elementu z precyzją, która będzie kosztowała więcej czasu i energii niż dostarczy informacji. Czy oznacza, że jesteśmy skazani na nadzieję, że będzie na kiedy będzie? Na szczęście nie! Dowiedz się, czym jest modelowanie Monte Carlo!

Złożone z wielu elementów projekty czy przedsięwzięcia, takie jak nowe wersje produktów, inicjatywy obejmujące wiele zadań o własnej wewnętrznej złożoności to już codzienność.

Mówi się, że to nie ludzie stali się głupsi, ale rzeczywistość bardzo złożona.

Nasze umysły próbują rozłożyć takie skomplikowane łamigłówki na części pierwsze w nadziei, że dokładne określenie części składowych da nam poczucie pewności i bezpieczeństwa. Praktyka pokazuje, że rzadko się to udaje, uzyskiwane poczucie bezpieczeństwa jest złudne, a angażowanie czy to ekspertów, czy całych zespołów jest bardzo kosztowne, czasem wręcz frustrujące i jeśli się zgodzicie, trąci raczej podejściem deterministycznym, zakładającym możliwość dokładnej kontroli nad przyszłością niż zwinnym empiryzmem.

Okazuje się jednak, że nie jesteśmy bez szans by w sposób „lekki”, adaptujący się do zmiennej rzeczywistości budować prognozy dostarczenia, nazwijmy to projektu. O tym czym jest, na czym bazuje i co ważne – jak w praktyce może dostarczać nam cennym informacji dowiesz się z 40. odcinka „Kanbanu przy kawie”. Zapraszam!

Treść odcinka może wydawać się trudna, więc pozwoliłem sobie na kilka akapitów rozwinięcia.

Zacznijmy od podstaw – ile potrwa pojedyncze zadanie?

Weźmy jako przykład rzut standardową kością do gry. Ile może na niej wypaść oczek? Od 1 do 6. To jest jasne, ale zaczynają się schody. Każdy kolejny rzut kością jest wydarzeniem statystycznie niezależnym, a więc fakt, że wyrzuciliśmy jedynkę, nie oznacza, że w kolejnym rzucie jedynka jest jakoś mniej prawdopodobna. Wydaje się nam to nieintuicyjne, podobnie jak fakt, że ktoś kto właśnie wygrał w loterii nie traci szans na wygranie jej jeszcze raz.

Naturalnie jeśli będziemy rzucać kością wiele razy, dajmy na to… kilkaset okaże się, że w wyniku losowości pewne wartości będą występowały częściej niż inne. Tu wracamy do domeny, którą większość z nas rozumie.

A jak jest z zadaniami, które składają się na nasz projekt? Jedna trwają krócej, inne dłużej. O ile istnieje może jakaś minimalny, najkrótszy czas realizacji, to ten najdłuższy jest właściwie nieograniczony.

To też oczywiste.

Jestem przekonany, że w części z głów czytelników i słuchaczy odzywa się teraz głos, że przecież zadania są różne. Jasne. Nie dość, że są różne, to jeszcze czas ich wykonania zależy od bardzo wielu różnych czynników. By wymienić tylko kilka podam, że zależy od tego, kto realizuje zadanie, czy ma ono jakieś zależności, jak dobrze zostało zrozumiane, opisane czy przedyskutowane przed rozpoczęciem pracy itp., itd. Czynników, które wpływają na czas realizacji zadania jest mnóstwo. Jeśli jednak nie zmieniamy co chwilę domeny, zespołu, sposobu, w jaki dzielimy wymagania, budujemy software nie oznacza to jednak tego, że ich czas realizacji jest całkowicie nieprzewidywalny.

Budowaniu tej przewidywalności pomagają praktyki takie jak refinement, a więc doskonalenie elementów do wykonania, ich doprecyzowanie, określenie kryteriów ukończenia, obcięcie niepotrzebnych części czy rozwikłanie zależności. To przecież robią choćby zespoły Scrumowe, które budują Cele Sprintów możliwe do realizacji w trakcie trwania przedziału czasu, jakim jest Sprint. Z niejawnej więc definicji zadania stojące za Celem Sprintu powinny być dowiezione w trakcie np. dwóch tygodni (jeśli tyle trwa Sprint). Przy takiej organizacji pracy wyznacza to oczekiwaną górną granicę, coś jak maksymalna liczba oczek na kości. Ile może potrwać najkrócej? Może dzień? Jakąś naturalną dolną granicę trwania. Ile może potrwać maksymalnie? Tu analogia z kością zawodzi, bo okazuje się, że może potrwać równoważność siedmiu, ośmiu, a może nawet dziesięciu oczek.

Idziemy w las – ile potrwa cały zakres czy projekt?

Czy żeby obliczyć czas trwania dostarczenia całego zakresu nie wystarczy podzielić go na timeboxy takie jak Sprinty? Otóż niesie to za sobą wiele nieprawdziwych, mylących założeń i zwiększa ryzyko złudnej przewidywalności. Przykład? Zacznijmy od tego, że nawet najlepszym zespołom zdarza się nie dostarczyć zadania w timeboxie. Zadanie może, w różnych przyczyn trwać dłużej, a jego siłowa próba zmieszczenia w timeboxie mogłaby oznaczać utratę wartości dla odbiorcy. To oznacza sytuację, gdy na kości wyrzucamy nawet 7 lub więcej oczek. Mamy nadzieję, że nie będzie to nowy „standard”, bo oznaczałoby to coś w stylu „przewidywalnie nieprzewidywalnego” zespołu, ale nie możemy być na to ślepi. Jeśli takie wydarzenia będą miały miejsce rzadko, to będzie miało to mniejszy wpływ na harmonogram całego releasu czy produktu, jeśli będzie to częstsze, to wpływ, a tym samym czas trwania całości, będzie rósł.

Jeśli nasz projekt lub zakres produktu składa się z wielu elementów, to prędzej czy później pojawi się pytanie o to, jak zadania rozkładają się w czasie. Czy tworzą liniową sekwencję, czy mają zależności czy możemy zrównoleglić pracę nad dwoma, a może czterema naraz?

Intuicja podpowiada, że warto spędzać czas na rozłożeniu ich na sekwencję, którą często widzimy jako harmonogram, czyli popularny Gantt Chart. Nie ma w nim nic złego, bo dobrze rozumieć pewną możliwą lub sensowną sekwencję, ale już nadawanie czasu „paskom” na harmonogramie to wróżenie z fusów. Pomimo wsparcia narzędziowego wiemy, że często klocki te się rozsypują.

Czy jest sens wkładać w trud w takie zaplanowanie pracy na miesiące lub kwartały do przodu?

O zgrozo, nie!

Dochodzimy do kluczowego momentu, w którym na scenę wkracza mądrość, z której korzystali choćby twórcy Programu Manhattan, a więc programu jądrowego USA z czasów II Wojny Światowej.

Okazuje się, że na podstawie relatywnie niewielkich np. kilkunastu zmierzonych czasów realizacji zadań (lead times), albo też tempa dostarczania zadań (delivery rate) z kilku okresów możemy zacząć budować pewien statystyczny model, który pokaże nam, jaka jest przeciętna (uwaga: nie średnia!) prędkość dostarczania klocków składających się na całość. Jeśli zbudujemy model, który będzie wielokrotnie np. dziesiątki tysięcy razy próbował określić przebieg dalszego np. tempa dostarczania to okaże się, podobnie jak przy wielokrotnym rzucie kością – niektóre scenariusze są mniej prawdopodobne niż inne.

Jeśli serię 6 rzutów kością powtórzymy wiele razy, okaże się, że wyniki, kiedy wypadają same 1 albo same 6 są zwyczajnie mniej prawdopodobne niż jakaś mieszanka wszystkich dostępnych wartości.

OK, ale jak tego użyć do naszej pracy? Podobnie jak fizycy jądrowi i matematycy, podobnie jak finansiści i ekonomiści zajmujący się ryzykiem, musimy określić, jaki jest zakres prawdopodobieństwa, najlepiej oparty o empiryczne, a więc własne, zmierzone dane „wrzucić” je do odpowiedniego modelu i chwilkę poczekać. Wiem, choć brzmi to jak wróżenie z kryształowej kuli, to okazuje się, że ma nad magią, o ile w nią wierzycie, kilka przewag. Jeśli w magię nie wierzycie, to taki model ma również przewagę przed naszymi błędami poznawczymi, czy myśleniem życzeniowym. Jakie są…

…mocne strony modelu statystycznego?

• na początku możemy nakarmić model naszymi przewidywaniami, np. zakresem „od – do” dla pojedynczych zadań, choćby w oparciu o dane z innego projektu lub uzgodnienia z zespołem czy nawet estymaty,
• tak szybko jak zaczniemy dostarczać powinniśmy przełączyć się na własne, empiryczne dane,
• im więcej zadań zrealizujemy, tym nasz model będzie zwracał celniejsze prognozy. Co ważne: nie oznacza to, że musimy czekać na setki czy tysiące pojedynczych pomiarów,
• model będzie podawał nam aktualizowane prognozy na podstawie każdej zmiany – czy to nowych zaobserwowanych czasów realizacji, zmieniającego się tempa dostarczania, czy wzrostu/zredukowania zakresu,
• model powstaje w ułamku czasu, jaki zajęłoby „gdybanie” angażujące cały zespół na długie godziny.

Dlaczego tego nie robimy?

Ktoś może się teraz zastanawiać: skoro od dekad jest to znane narzędzie w dziedzinie nauki czy ekonomii, to dlaczego nie stosujemy go (jeszcze) szeroko w świecie projektów czy prognozowania dostaw? Warto zacząć od pokory – to nie jest tak, że w np. w świecie IT jesteśmy najmądrzejsi na świecie :). A jakie są inne przyczyny małej popularności prognozowania statystycznego czy konkretnie modeli Monte Carlo?

• Nie znamy tej metody. Mimo tego, że IT to ponoć twarde kompetencje to czasem z matematyką krucho :).
• Modelowanie czy też metoda Monte Carlo jest bardzo, ale to bardzo nieintuicyjna, bo jako ludzie nie zwykliśmy myśleć statystycznie. Lubimy natomiast to, że nasza praca jest tak specyficzna, że nie dostrzegamy trendów, które uwypuklają podejścia statystyczne.
• Nie znamy czynników, które w rzeczywistości wpływają na czas realizacji czy tempo dostarczania zadań w naszej firmie czy produkcie.
• Reagujemy emocjonalnie i przywiązujemy się do naszych własnych ocen.

Jako, że zbudowanie modelu Monte Carlo to dziś chwila zachęcam do prób. Wystarczy narzędzie takie jak opisywane w odcinku 34. Jira Flow Companion, getNave czy Actionable Agile. Może wystarczy nawet Excel lub jakiś symulator online. Odcinek o którym mówię znajdziesz tu: Odcinek 34. – Czym mierzyć? Przegląd narzędzi do metryk przepływu.

Jestem bardzo ciekaw, czy stosujecie takie podejście, choćby jako ciekawostkę lub może zaczniecie zainspirowani tym odcinkiem i wpisem. Dajcie znać.

Ciekawe? Podziel się!

Jeśli treść tego odcinka Ci się spodobała to najprostszym, co możesz zrobić jest podzielenie się nim ze swoimi współpracownikami lub społecznością! Dzięki!

Jeśli jesteś głodny lub głodna wiedzy o Metodzie Kanban, to zapraszam na szkolenie Kanban Systems Improvement, na którym szerzej omawiamy temat Monte Carlo.

Dzięki i pozdrawiam!

Pomóż innym, podziel się!