Cumulative Flow Diagram (CFD) se s pridom uporablja v večini Agilnih frameworkov. Populariziral ga je Kanban, kjer je “Visualize the flow” ena od šestih vodilnih praks.
CFD prikazuje količino dela, ki se trenutno nahaja v določeni fazi razvojnega cikla in s tem služi kot vizualna reprezentacija stabilnosti razvojnega procesa. Lahko ga smatramo za nadgradnjo burnup grafa. CFD interpretacije
Obstaja veliko variacij CFDja. Nekateri prikazujejo količino dela v backlogu, drugi ne, nekateri razvoj razbijejo na pod faze, drugi pa jih združijo v skupni pas. Na CFD se pravtako da prikazati trende, ki nam pomagajo pri planiranju release datuma. Odvisno od potreb.
Spodnji primeri so zgrajeni na preprostem ciklu, ki prikazuje količino dela prevzeto v razvoj, testiranje in kumulativo zaključenih funkcionalnosti.
V članku se ne bomo zadrževali na osnovah CFD kot so npr. Littlov zakon in relacija med WIP in Cycle Time. Za to obstaja dosti drugih virov. Namesto tega si bomo raje ogledali naprednejšo temo interpretacije CFD vzorcev. Ti nam razkrivajo detajle timske dinamike, ki so na prvi pogled lahko skriti.
Faza (trak) se širi
Pogosti vzorec. V našem primeru testerji prevzemajo razvite funkcionalnosti v testiranje hitreje, kot jih uspejo obdelati. Posledično se čakalna vrsta funkcionalnosti (uporabniških zgodb), ki čakajo na testiranje podaljšuje. V grafu se to vidi kot širjenje Testing traku in njegovega WIP.
Višji WIP, bo posledično vodil v daljši Cycle Time, kar upočasnjuje pretok funkcionalnosti skozi razvojni proces. Dodatni negativni faktor je, da bojo na določeni točki, testerji zaradi časovne stiske, začeli z multitaskingom, kar bo še dodatno znižalo njihovo produktivnost. Statistično, vsaka dodatna vzporedna naloga zniža produktivnost za 20%.
Rešitve
- Takojšnja prekinitev prevzemanja razvitih funkcionalnosti v fazo testiranja.
- Implementacija primernih WIP limit, ki bo zagotovila, da v fazo testiranja ne bo prevzeto več funkcionalnosti, kot jih testerji lahko sproti obdelajo. Če so WIP limite že postavljene, so verjetno previsoke in jih je potrebno znižati. Idealno je povprečni “inflow” v posamezno razvojno fazo enak njenemu “outflow”. Vizualno bi to pomenilo, da trak določene faze s časom ostaja več ali manj enako širok (se ne širi ali oži).
- Vključevanje dodatnih testerjev v team. Pri tem se je potrebno zavedati, da team ob vključitvi novih članov mora ponoviti potovanje čez Tuckmanove razvojne faze. V praksi to pomeni, da bo produktivnost teama po vključitvi novih članov nekaj časa nižja, predno se bo zvišala.
- V primeru interdisciplinarnih teamov kjer se specializacije članov prekrivajo, lahko razvojniki priskočijo na pomoč testerjem pri krajšanju testing backloga.
- Če imamo srečo, in je naš team pretežno interdisciplinaren, se splača razmisliti tudi o WIP limiti na teamskem nivoju, ne samo na posameznih fazah. Skupna limita, ki pokriva vse razvojne faze, v takšnem primeru, avtomatizira optimizacijo pretoka skozi celoten proces. V praksi to pomeni, da smo omejili število backlog entitet, ki so sočasno lahko prisotne na kanban tabli.
- Širjenje traku razvojne faze je lahko normalna posledica dodajanja članov teamu. V tem primeru se praviloma s časom zviša tudi WIP kapaciteta omenjene faze. Če to ni podprto z večjo strmino traku, ki predstavlja zaključene funkcionalnosti (modro), takšen team z novimi člani ni dosegel višje produktivnosti. Razloga za to sta lahko dva:
- Team novih članov še ni uspešno integriral v svoj razvojni proces
- V teamu je preveč članov, zaradi česar je medsebojna koordinacija postala prezahtevna in je posledično padla produktivnost individualnih članov (Brooksov zakon)
- Če se širi samo trak testne faze, lahko to pomeni tudi nezadovoljivo kvaliteto outputa razvojne faze (zeleno). V tem primeru je verjetno potrebno dopolniti Definition of Done (Scrum) ali procesne politike (Kanban).
Več faz se širi
Isto kot zgoraj, le da se širijo trakovi več faz. Naraščajoči WIP pomeni daljši Cycle Time in upočasnjen pretok funkcionalnosti skozi razvojni cikel. Višji WIP običajno povzroči tudi multitasking razvojnikov, ki je eden pomembnejših Lean odpadkov.
Rešitve
- Zaustavitev prevzemanja novih funkcionalnosti v prizadete faze, dokler se njihov WIP ne zniža.
- Nižanje WIP limit. Če te kljub širjenju trakov niso bile presežene.
- Rigorozno uveljavljanje WIP limit. Stolpce določenih razvojnih faz na Kanban tabli razdelimo na “V delu” in “Zaključeno”. To nam bo pomagalo identificirati ozka grla v procesu. WIP limito postavimo za celotno razvojno fazo, ki vključuje tako pod stolpec “V delu” kot “Zaključeno“.
- Potrebno je ugotoviti temeljni vzrok pojava. Nekaj morebitnih razlogov:
- Management forsira razvoj funkcionalnosti mimo Product Ownerja oz. produktnega managerja.
- Scope creep
- Previsoke WIP limite
- Preozka specializacija članov teama (različne faze si medsebojno ne morejo pomagati)
- Je kakšna od faz ozko grlo in se zato WIP kopiči v predhodnih fazah?
Ravnine
Ravnine v CFD pomenijo, da se funkcionalnosti ne premikajo skozi proces. Potrebna je identifikacija blokad.
Rešitve
- Če se ravnine pojavijo istočasno na vseh fazah (1), verjetno govorimo o zunanjih faktorjih kot so npr. prazniki, dopusti, izobraževanja ali sistemske nadgradnje, ki ovirajo delo teama.
- Če se ravnina pojavi nad in pod določeno fazo (3), je v tej fazi blokada. Testirane funkcionalnosti ne potujejo v Done, pravtako Testing faza (zaradi doseženih WIP limit) iz predhodne faze ne prevzema pripravljenih funkcionalnosti. Mogoče so testerji zaradi previsokih WIP limit začeli z multitaskingom? Mogoče je težava v dostopnosti testne infrastrukture? Mogoče team čaka na zunanje odobritve? Naloga Scrum Mastra je, da teamu pomaga identificirati blokado in ga usmerja na poti pozitivne rešitve. V Kanbanu je to običajno naloga produktnega managerja.
- Pod predpostavko, da so WIP limiti doseženi, ravnina pa se pojavi samo v eni fazi (napr. med Testing in Done) (2), faza nad njo (Testing) pa se širi, pomeni da znotraj teama ne obstaja zadostna komunikacija. Nima namreč smisla v proces prevzemati novih funkcionalnosti, če stare še niso razvite. Scrum Master team v takšnem primeru usmerja v uporabo dobrih komunikacijskih praks, ki ga bojo popeljale iz faze normiranja (Norming) v fazo učinkovitosti (Performing). Če je team dosegel multidisciplinarnost, kjer na primer programerji lahko pomagajo testerjem in obratno, se splača razmisliti po določitvi WIP limite za celoten team (kanban board).
- Ravnine so lahko tudi posledica prevelikih uporabniških zgodb. V tem primeru je težava v Backlog Refinement in Sprint Planning procesu, ki nista dovolj detajlna (za prihajajoči Sprint). To težavo naj Scrum Master naslovi na naslednji Sprint Retrospektivi. Prevelike uporabniške zgodbe namreč povečujejo rizik, da team, v primeru nepredvidenih težav, na koncu Sprinta ne bo realiziral nobene poslovne vrednosti. Če prakticiramo Kanban je težava pravtako nezadostna dekompozicija backlog entitet s strani produktnega managerja in razvojnega teama.
Stopnice
Ni nujno problematično. Pomeni da se poslovna vrednost realizira paketno (batches) v redni kadenci (če so stopnice enakomerno razporejene). Agile teži h kontinuiranemu kreiranju poslovne vrednosti, neglede na okvire iteracij. Paketna realizacija poslovne vrednosti s tega stališča predstavlja odmik od ideala, vendar je včasih pogojena z zunanjimi faktorji.
Rešitve
- Preverimo ali so Sprinti prekratki. Mogoče je zadnja razvojna faza “Priprava na produkcijo” časovno tako zahtevna, da procentualno zavzame preveč časa v kratkem Sprintu. V našem grafu so Sprinti verjetno dolgi le šest dni.
- Funkcionalnosti prevzete v razvoj niso razbite na dovolj majhne uporabniške zgodbe. Poizkusimo jih razbiti na manjše zgodbe. Tipična uporabniška zgodba naj bi predstavljala 1 – 4 delovne dni.
- Poizkusimo vzpostaviti sistem Continuous Deployment/Delivery (CI/CD) in s tem pospešiti vključevanje razvitih funkcionalnosti v produkcijo. DevOps filozofija je ideal takšnega procesa. Za DevOps velja isto kot za TDD. Organizacije, ki verjamejo, da tega pristopa še ne potrebujejo, naj svoje inženirje že zdaj začnejo izobraževati v tej smeri. Ko bojo DevOps potrebovali, bo za iskanje kadra in vzpostavljanje sistema prepozno. DevOps inženirji so relativno redki in posledično dragi.
Faza izgine
Če trak razvojne faze izgine, to običajno pomeni, da smo priča preskakovanju faz.
Rešitve
- Preverimo s teamom ali je faza, ki je izginila bila smiselna. Mogoče se je team odločil, da jo eliminira, ker razvojniki v njej ne vidijo dodane vrednosti – jo smatrajo za odvečno administracijo.
- Faza je postala tako avtomatizirana, da je postala trivialna in jo je team združil z neko drugo fazo.
- Mogoče se traku ne vidi, ker je granulacija vizualizacije v CFD prevelika in jo je potrebno zmanjšati?
- Mogoče faza nima jasnega lastništva in ga je potrebno določiti?
- Preverimo, ali je team samo nehal beležiti WIP te faze. Ugotovimo razlog.
- Stolpce razvojnih faz na Kanban tabli razdelimo na “V delu” in “Zaključeno”. To nam bo pomagalo identificirati morebitne blokade v procesu.
S krivulja
Pogost vzorec. Lahko kaže na neučinkovitost procesa. S krivulja preko daljšega obdobja več Sprintov otežkoča planiranje. Normalno je, da se trakovi na začetku razvoja ali Sprinta postopoma razširijo in na koncu zožijo. Problem je lahko vmesno obdobje kjer trakovi idealno napredujejo linearno, ne v S obliki. Kar se tiče produktivnosti, je takšna situacija pozitivna, a bi bila lahko njena posledica izgorelost teama.
Po mojem mnenju, takšen vzorec znotraj posamezne iteracije/Sprinta ni problematičen. Faza testiranja ima na začetku WIP pogosto enak nič, kar je normalna posledica dinamike razvojnega cikla (dokler funkcionalnost ali njen del ni razvita, ni kaj testirati). Pravtako na koncu Sprinta želimo, da se razvojne in testne dejavnosti počasi zaključujejo. Scrum nikakor ne zahteva 100% izkoristka članov teama.
Rešitve
- Če ima prva razvojna faza na začetku Sprinta, WIP enak nič in se ta postopno povečuje, imamo težavo v planiranju Sprinta. Team naj v razvoj takoj prevzame toliko funkcionalnosti kot je njegova kapaciteta brez multitaskinga (ne začnejo na vrednosti nič). Izjema so teami, ki prakticirajo one-piece-flow. Takšni teami prevzemajo v razvoj le eno funkcionalnost (uporabniško zgodbo) naenkrat in jo razvijajo na način, da v posamezni razvojni fazi istočasno ni drugih funkcionalnosti (WIP limite vseh razvojnih faz so 1).
- Če ima zadnja razvojna faza (Testing) ob koncu Sprinta visok WIP in posledično visok Cycle Time, bi bilo dobro v testiranje vključiti dodatne člane. Idealno obstoječe razvojnike v teamu, ki do zdaj niso sodelovali pri testiranju. V tem primeru predpostavljamo, da je faza razvoja pretežno zaključena in imamo tako na voljo razvojnike, ki bojo prevzeli del testiranja. Z angažiranjem obstoječih članov, se izognemo organizacijskemu stresu prevzemanja novih članov v team (Tuckman).
- Razmislimo ali je S krivulja v naši situaciji sploh problematična. Lahko je le posledica dobro uigranega tima, ki potrebuje nekaj časa za “zagon” in se njegovi člani proti koncu sprinta/releasa že delno angažirajo na drugih projektih.
Zaključek
CFD diagrami so koristni tako v Scrumu kot v Kanbanu.
Pokažejo nam:
- Kje se delo (in s tem rizik) kopiči
- Kje so neučinkovitosti v razvojnem procesu.
Brez interpretacije so CFD samo še eden od KPIjev. Njihova vrednost je v razlagi opaženih anomalij.
CFD so eno od vizualnih orodij, ki jih spoznamo na tečaju Scrum Master.
