V prejšnjem članku smo spoznali deterministično ocenjevanje in kdaj je koristno. Tokrat pa si bomo ogledali smisel probabilističnega ocenjevanja in par orodij, ki nam pri tem pomagajo. Ta način ocenjevanja je pogostejši v Kanbanu. Planiranje
Kaj je probabilistično ocenjevanje?
Probabilistična ocena podaja verjetni čas (lead time), ki bo pretekel od podaje zahtevka do njegove realizacije. Kot taka ima dva dela. Prvi je verjetnost v procentih, drugi pa časovno obdobje.
Probabilistične ocene naj bi Kanban teamu omogočile, da se izogne ocenjevanju velikosti zahtevanih funkcionalnosti. Kot bomo videli kasneje, temu v celoti ni tako.
Primeri:
- 85% helpdesk zahtevkov rešimo v 2 delovnih dneh.
- Verjetnost da bo šest funkcionalnosti, ki bojo sestavljale naslednji release zaključenih v štirih tednih je 60%.
- Obstaja 75% verjetnost, da bo zahtevek rešen do 10. maja in 85% verjetnost, da bo rešen do 20. junija.
Kanban team skozi optimizacijo pretoka funkcionalnosti skozi razvojni proces, krajša lead time in s tem vzpostavlja željeno kadenco realizacije do meje, ki še zagotavlja vzdržnost delovnega tempa. S tem vzpostavlja t.i. Service Level Expectation (SLE), ki zunanjim deležnikom sporoča kako hitro lahko računajo na realizacijo zahtev, ki so jih predali v razvoj.
Vodenje statistike za SLE je administrativno breme, ki se mu Kanban teami žal ne morejo izogniti. Lahko pa si pomagajo z orodji, ki to statistiko računajo avtomatično na osnovi podatkov, ki se tako ali tako beležijo v sistem.
Na sliki je graf iz aplikacije Nave, ki črpa podatke iz Jire.
Na osnovi grafa (scatterplot diagram) vidimo, da je trenutni SLE Kanban teama:
- 70% za 14 dni ali:
- 85% za 29 dni ali:
- 95% za 57 dni
Naročnik, ki bo določeno funkcionalnost predal v razvoj, bo nato glede na nivo tveganja, ki ga je pripravljen sprejeti, planiral svoje nadaljnje aktivnosti.
Kaj pa velikost zahtevkov?
Verjetno se je, glede na napisano, že kdo vprašal kako je sploh mogoče (četudi približno) napovedati čas razvoja neke funkcionalnosti, glede na to, da so si te lahko zelo različne. ERP modul za skladišče je vsekakor večji kot dodajanje novega polja na WEB obrazec.
Odgovor na to vprašanje je, da se tega v resnici ne da. Probabilistično planiranje temelji na predpostavki, da s časom velikosti zahtevkov konvergirajo proti neki srednji vrednosti. SLE je reprezentacija te konvergence.
Da bi bilo čim bolj tako, Kanban teami k reševanju te zadrege pristopajo z več metodami, ki zahtevajo par predpostavk.
Metoda 1
Veliko poslovno funkcionalnost členimo na manjše dele tako dolgo, dokler imajo ti deli še lastno poslovno vrednost.
Predpostavka:
Velikost granularnih funkcionalnosti, ki smo jih pridobili, je manj variabilna, od večjih funkcionalnosti iz katerih le te izvirajo.
Komentar
Statistično gledano bi temu lahko bilo tako, a je v praksi razpon kljub temu precejšen – čeprav manjši kot pri večjih funkcionalnostih. Metoda je po mojem mnenju koristna. V praksi je enaka razčlenjevanju, ki ga na Backlog Refinement sestanku izvajajo Scrum teami.
Metoda 2
Pri planiranju večjih funkcionalnosti naj team uporabi časovno obdobje z višjo verjetnostjo. Na primer 95% namesto krajšega obdobja s 70% verjetnostjo. Planiranje
Predpostavka:
Večje funkcionalnosti vsebujejo več neidentificiranih tveganj kot manjše funkcionalnosti.
Buffer, ki nam ga nudi verjetnejša ocena, zadostuje za pokritje teh nepredvidenih tveganj.
Komentar
Z večanjem gotovosti implementacije v nekem časovnem obdobju se dolžina tega obdobja progresivno podaljšuje. To še posebej postane očitno, ko presežemo 90% SLE. Metoda je po mojem mnenju koristna skupaj s prejšnjo metodo, a je nikakor nebi uporabil za verjetnosti nad 95%.
Zaradi opisanih problemov glede variacij vhodnih zahtevkov, je logično, da se je Kanban pretežno uveljavil v helpdesk ticketing okoljih kjer je ta variacija najmanjša.
Zaključek
Neglede na to ali kot Kanban team uporabljate probabilistično ali deterministično planiranje, ali pa kot Scrum team deterministično, rezultat ne zadovolji vseh deležnikov s katerimi team sodeluje.
Obstaja tudi tretja pot, ki jo trenutno preizkušam na zgodovinskih podatkih teamov. Več o njej v tretjem delu članka.
