SLAP NA KANBAN TABLI
Obstaja veliko poti po katerih se Waterfall lahko vtihotapi v Agilno okolje. Nekatere so posledica pritiska na deležnike, nepoznavanja Agilne filozofije, organizacijske strukture ali preprosto prepričanja da: “Mi smo drugačni”. Rezultat je vedno neoptimalen. mini waterfall
Waterfall in Agile sta namenjena izvajanju temeljno različnim tipom projektov.
- Waterfall je primernejši za dobro definirane projekte, kjer se ve, kaj želimo kot rezultat in za izvedbo obstajajo uveljavljene najboljše prakse (gradnja objektov, organizacija koncerta, masovna distribucija softwarea v organizaciji…).
- Po drugi strani je Agile primernejši za projekte, pri katerih vemo kaj želimo doseči, pot do cilja, metode in tip rešitve pa niso povsem znani. Torej za razvojno delo (razvoj aplikacij, inovativni tržni pristopi, NPI, implementacija novih tehnologij v proizvodnji…).
V članku se bomo omejili na Waterfall pasti, ki se pojavljajo znotraj Sprinta. Napisano velja tudi za Kanban, ki se srečuje z enakim problemom čeprav nima tako poudarjenih iteracij.
V času Sprinta, team delo planira in spremlja s pomočjo Kanban boarda (khm… table). Poenostavljen Kanban board izgleda kot na spodnji sliki.
- V levem stolpcu imamo uporabniške zgodbe, ki sestavljajo Sprint Backlog. Torej zgodbe za katere team predvideva, da jih bo uspel razviti v tekočem Sprintu. V primeru Kanbana je ta stolpec kar trenutni Product Backlog.
- Desno od Sprint Backloga imamo tri sekvenčne razvojne faze: arhitekturo, razvoj in testiranje. Te faze imajo za zagotavljanje pretoka skozi proces VIP limite (3). VIP limiti pogosto predstavljajo število članov teama, ki izvajajo določeno fazo. V zgornjem primeru imamo v teamu torej na razpolago tri arhitekte, tri razvojnike in tri testerje (poleg Scrum Mastra in Product Ownerja).
- V skrajno desnem Done stolpcu, so uporabniške zgodbe, ki zadoščajo definiciji “Done“. So zaključene in pripravljene na potencialni release.
Z zaključevanjem posameznih faz, se uporabniške zgodbe preko Kanban boarda premikajo v desno:
V resnici zgodbe preko Kanban boarda premikamo več ali manj vodoravno, na sliki pa sem premike nalašč prikazal padajoče, da nas to spomni na – Waterfall. Ali imamo torej znotraj Sprinta več mini Waterfallov? Da, če nismo pazljivi.
Uporabniške zgodbe potujejo skozi proces sekvenčno. To pomeni, da programerji ne morejo začeti z delom dokler niso določeni in usklajeni arhitekturni standardi. Pravtako testerji ne morejo celovito testirati razvite kode dokler programerji ne zaključijo s kodiranjem uporabniške zgodbe (delno se da, a za naš primer to ni ključno). Vsaka faza je torej odvisna od zaključka predhodne. Waterfall projektni management takšno odvisnost nalog imenuje Finish-to Start.
OPTIMIZACIJA DELA IN KJE SE ZATAKNE
1. poizkus
Oglejmo si Kanban tablo sedem članskega razvojnega teama z določenimi VIP limitami in ga heretično prekrijmo s kvazi Gantt grafom.
Slika zahteva nekaj pojasnil.
- Imamo tri tedenski Sprint in šest uporabniških zgodb v Sprint Backlogu.
- Uporabniške zgodbe imajo različno zahtevne faze. Prva uporabniška zgodba na primer zahteva pol tedna dela na arhitekturi, pol tedna na razvoju in en teden testiranja. Tretja uporabniška zgodba zahteva pol tedna arhitekture in po en teden razvoja in testiranja. V praksi velikost uporabniških zgodb ocenjujemo v Story Points a za naš primer je časovnica primernejša, rezultat pa isti.
- Gantt graf je že optimiziran glede na zahtevnost posameznih faz razvoja uporabniških zgodb in število razpoložljivih arhitektov (2), programerjev (3) in testerjev (2).
Zanima nas kakšna konfiguracija teama je v dani situaciji najproduktivnejša.
Vidimo da je team v takšni konfiguraciji uspel v Sprintu zaključiti štiri uporabniške zgodbe z devetimi tedni zapravljenimi s čakanjem na delo – Lean waste (razvojniki čakajo arhitekte, testerji razvojnike).
Mislim, da se strinjamo, da imamo v takšni konfiguraciji opravka z linearnim razvojem. Torej več mini Waterfall procesi znotraj Sprinta.
2. poizkus
Team in njihov Scrum Master se strinjajo, da nižanje VIP limit poveča pretok skozi sistem. Da nebi imeli toliko odpadka v obliki delovnega časa, se odločijo zmanjšati število članov v posameznih fazah (arhitektura 1, razvoj 2, testiranje 2).
Na istih uporabniških zgodbah je rezultat naslednji:
Manjši team (5 članov) ima sicer samo še osem tednov odpadka (waste), a je uspel zaključiti le dve uporabniški zgodbi.
Izkoristek je še slabši kot pri sedem članskem teamu. Pretok skozi sistem se očitno ni povečal. Omejitev je nekje drugje.
3. poizkus - T specialisti na pomoč
Teamu je spoznal, da bo problem produktivnosti uspel rešiti le z večfunkcionalnostjo članov razvojnega teama.
“Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.” – Scrum Guide 2020
Člani “Cross-Functional” teama so praviloma tako imenovani T specialisti. Strokovnjaki na enem ali dveh področjih in kompetentni na par drugih področjih (npr. tester, ki tudi programira ali arhitekt, ki pozna tesne procedure).
Po krajšem obdobju dodatnega izobraževanja, programiranja v parih in internih delavnic, team smatra, da je pripravljen na nov poizkus.
- Eden od programerjev sedaj pozna tudi arhitekturne zakonitosti.
- Eden od testerjev je postal spreten v programiranju.
- Eden od arhitektov je spoznal testne procedure.
Od petih članov teama so samo trije postali T specialisti, pa še to le na enem dodatnem področju. Poglejmo ali je to pomagalo.
Pet članski team je razvil enako število uporabniških zgodb kot sedem članski. Pri tem je imel trikrat manj odpadka. Šest tednov odpadka, ki smo se ga znebili, je ekvivalent polnega delovnega časa dveh članov, ki smo ju po prvem poizkusu izključili iz teama. Minimalna večfunkcionalnost članov teama nam je z enakim rezultatom torej omogočila zmanjšanje števila članov teama za dva.
Ali je odpadek mogoče zmanjšati na nič? Teoretično da, če bi več funkcionalnost članov razširili še na druga področja. V praksi pa to niti ni mogoče, niti potrebno. Tri tedne “odpadka”, ko razvojniki ne delajo neposredno na produktu, običajno zapolnijo z Backlog Refinement sestanki, izobraževanji, refactoringom, dokumentiranjem in interakcijo z naročnikom/končnimi uporabniki. Dejavnostmi, ki bi jih bilo potrebno opraviti v vsakem primeru.
Mini Waterfallu v Agilu se torej lahko izognemo s teami sestavljenimi iz T specialistov. Ti bojo prevzeli druge faze razvoja v primeru, ko ima njihova primarna faza prosto kapaciteto.
ONE-PIECE-FLOW
Drugi način preprečevanja sekvenčnih odvisnosti med razvojnimi fazami je One-Piece-Flow, ki izvira iz Lean metodologije in je ideal h kateremu teži marsikateri Kanban team.
V praksi to pomeni, da se naenkrat v določeni fazi razvoja nahaja samo ena uporabniška zgodba. Neglede na to koliko članov teama je specializiranih za to fazo, njen WIP limit ostaja enak ena (1).
Swarming pomeni, da vsi razpoložljivi razvojniki v fazi skupaj razvijajo isto uporabniško zgodbo. Če naletijo na težavo, ki zavira pretok zgodbe skozi sistem, se swarmingu pridružijo še T specialisti ostalih faz dokler blokada ni odpravljena.
To zagotavlja polni izkoristek T specialistov v teamu.
Swarming se lahko izvede z razbitjem uporabniške zgodbe na pod-zgodbe po funkcionalnih ali tehničnih kriterijih. Pravtako se za iskanje rešitev lahko prakticira programiranje v parih, brainstorming in problemsko usmerjene delavnice.
Ene-Piece-Flow je posledica ekstremne oblike swarminga.
Na zgornji sliki vidimo, da je Arhitektura že zaključila uporabniško zgodbo, ki sedaj čaka v arhitekturnem Done stolpcu, da se sprosti kapaciteta v razvoju. To je signal, da se arhitekti pridružijo swarmingu na uporabniški zgodbi, ki blokira dev fazo in s tem celoten pretok skozi sistem (flow). Več glav več ve.
MINI WATERFALL - ZAKLJUČEK
Namen T specialistov in swarminga je:
- Omogočanje nemotenega in čim hitrejšega pretoka uporabniških zgodb skozi razvojni proces in s tem konstantnega kreiranja poslovne vrednosti naročniku.
- Na osnovi tako optimiziranega procesa team lažje določi svoj velocity, ki jim bo pomagal pri planiranju naslednjih Sprintov.
- Manjšanje variacij v procesu omogoča zanesljivejši release planning.
T specialisti in swarming sta dva od načinov optimiziranja teamskega dela. Obstajajo tudi drugi (predvsem elementi TDD ter CI/CD), ki si jih bomo ogledali v enem od prihodnjih člankov.
