Kaj je Definition of Done?
Definition of Done (DoD) je dogovorjen spisek aktivnosti, ki jih team tekom iteracije izvede za vsak objekt, ki ga je iz Product Backloga prevzel v razvoj. DoD je merijo kvalitete, ki mu mora zadostiti vsaka funkcionalnost, ki jo team razvija. Funkcionalnosti (uporabniške zgodbe), ki ob zaključku iteracije ne zadostijo DoD, se stranki na Iteration/Sprint Review srečanju ne predstavijo, ker se ne smatrajo za zaključene (Done).
V okoljih kjer več teamov vzporedno dela na istem produktu, mora obstajati skupno dogovorjeni DoD, ki se ga običajno določi na prvem backlog refinement srečanju. Posamezni teami si lahko za DoD določijo dodatne, strožje zahteve, če smatrajo, da je to zanje koristno.
Nekaj primerov Definition of Done:
- Integracijski testi opravljeni
- Regresijski testi opravljeni
- Uporabniški testi opravljeni
- Refactoring opravljen
- Potrjena usklajenost z arhitekturo
- Acceptance criteria dosežen
- Nove verzije APIjev na delavnici predstavljene ostalim teamom
- Dokumentacija osvežena
- Vse slike kompresirane
Definition of Done vs. Acceptance Criteria
Acceptance Criteria (AC) so merila, ki potrjujejo, da razvita funkcionalnost ustreza potrebam stranke. Vsaka uporabniška zgodba ima enega ali več acceptance kriterijev. Določi jih naročnik na osnovi svojih poslovnih potreb. Kot takšni so acceptance criteria drugačni za vsako uporabniško zgodbo.
AC so lahko opisne ali pa strukturirane na način, ki omogoča neposredno pripravo avtomatičnega testa v TDD (npr. Gherkin syntax). V najzrelejših okoljih, naročnik AC posreduje celo v obliki testa. V tem primeru testi nadomestijo AC. Neglede na obliko, je vsekakor priporočljivo, da je izpolnitev AC del DoD.
Na spodnji sliki je primer Given-When-Then test scenarija, ki temelji na Gherkin sintaksi. Natančneje to temo umestimo v kontekst produktnega managementa na tečaju Product Owner.
Po drugi strani se DoD tekom posamezne iteracije (ali iteracij) redko spreminja. Kot merilo kvalitete ga primarno določijo razvojniki v sodelovanju s Product Ownerjem.
Na splošno lahko rečemo, da DoD:
- Zagotavlja konstantno kvaliteto produktnih inkrementov
- Znižuje potrebo po naknadnih popravkih (rework)
- Usklajuje razumevanje meril kvalitete med deležniki
- Omogoča natančnejše merjenje napredka in posledično kvalitetnejše planiranje
Vendar….
Evolucija DoD
…. DoD s pravim pristopom lahko postane katalizator Agilne transformacije.
Praviloma naj bi Agilni teami release v produkcijo izvajali vsaj na koncu vsake iteracije/sprinta. Poslovna vrednost se namreč realizira šele, ko je funkcionalnost predana v produkcijo. Dokler razvita funkcionalnost čaka na release, se sredstva vložena vanjo ne vračajo in je to po Lean definiciji odpadek (waste).
Batch releasi kjer se naenkrat v produkcijo potisne celo množico funkcionalnosti, so tvegani s stališča povratnih informacij končnih uporabnikov. Ob istočasni množici novih funkcionalnosti je težko prioritizirati nujne popravke (preobremenitev Helpdeska), težko določiti vir napak in težje narediti roll-back, če se ta pokaže za nujnega (npr. odzivnost sistema pade pod sprejemljivo mejo).
Naloga kvalitetne Definition of Done je omogočiti release v produkcijo vsaj enkrat na iteracijo. Če je funkcionalnost “Done”, se release lahko zgodi tudi sredi iteracije. Zakaj bi čakali na uradni zaključek iteracije? Takšno dinamičnost omogoča t.i. idealna Definition of Done.
Cilj Agilnih organizacij je, doseganje idealne DoD. Temu se približujejo s postopnim razširjanjem DoD na dejavnosti, ki odstranjujejo ovire za sprotni release v produkcijo. Približevanje idealni DoD lahko za večje organizacije traja leta, vendar je mogoče. Amazon na primer izvaja release v produkcijo vsakih par sekund.
Praktični primer
Opomba:
Slovensko razmišljanje o izrazih, ki jih večinoma uporabljamo v angleški različici, je lahko naporno. Tukaj je krajši obrnjeni slovar, ki nam bo olajšal razumevanje.
- Veja – branch
- Razvojna veja – dev ali feature branch
- Glavna veja – main ali trunk
Obstajajo sicer manjše razlike med Trunk-Based-Development in Git Flow pristopom, ampak te variacije ne vplivajo na sporočilo tega članka.
1.)
Razvojni team starta z DoD, ki zapoveduje, da je Product Backlog Item (PBI) zaključen, ko so izpolnjeni naslednji pogoji:
- Vsi acceptance criteria so izpolnjeni
- Refactoring je opravljen
- Koda je implementirana in pregledana. To pomeni, da je razvojnik napisano kodo lokalno preizkusil, nato pa je drug razvojnik naredil še lokalni code review.
- Unit testi so napisani skupaj z implementacijo funkcionalnosti (v istem ciklu), za razliko od TDD, kjer se testi pišejo pred kodo.
- Koda je integrirana v razvojno vejo (ne v glavno vejo).
- Funkcionalnost je uspešno prestala ročno testiranje v integracijskem/staging okolju.
1.1.)
Težave, ki jih je team opazil po par tednih razvoja:
- Razvojna veja se z glavno združuje le vsak 1 do 2 tedna (na koncu iteracije). Zato se težave z integracijo nabirajo in odkrivajo pozno.
- “Done” v resnici pomeni “razvojno zaključeno”, ne pa pripravljeno za produkcijo.
- Tudi če je glavna veja nestabilna, to ne ustavi dela ekipe, ker jo redko uporabljajo za razvoj ali testiranje. Stabilnost glavne veje je pomembna zgolj na papirju, a ker ima majhen neposreden vpliv na vsakodnevni razvoj, se ji tim redko posveča.
2.1.)
Na osnovi zgornjih opažanj je razvojni team dopolni DoD. PBI se po novi definiciji smatra za zaključenega ko:
- Vsi acceptance criteria so izpolnjeni
- Refactoring je opravljen
- Je nova koda integrirana v glavno vejo.
- Vsi avtomatični testi (unit, integracijski, regresijski) v Continuous Integration (CI) pipeline so uspešni.
- Koda se avtomatično integrira v testno/staging okolje. To odpravlja ozko grlo čakanja na ročno vključevanje nove kode v testno okolje (zametki DevOps?).
- Ni odprtih kritičnih napak. Izjave kot: “Feature je narejen, samo še ta bug je ostal. Ga bomo rešili drugič” niso sprejemljive.
2.2.)
Posledice spremembe DoD so naslednje:
- Razvojniki so prisiljeni v pogostejšo integracijo v glavno vejo. Glavna veja tako postane “živčno središče”, ker jo vsi uporabljajo kot izhodišče za svoje delo. Če je torej glavna veja nestabilna, to takoj ustavi delo vseh (ker testerji ne morejo testirati, razvojniki ne morejo suvereno delati na novih nalogah). Tako stabilnost postane operativno kritična in vpliva na produktivnost tima v realnem času. Posledično dnevna integracija (ali večkrat dnevno) postane norma. Sistem je podoben Andon vrvici v Toyota Production System.
- Ker je ročno izvajanje vseh regresijskih testov ob pogostih integracijah nemogoče, je tim prisiljen vzpostaviti avtomatiziran Continuous Integration (CI) cevovod, ki ob vsaki spremembi v glavni veji gradi, testira in namešča aplikacijo v testno okolje.
- S stalno integracijo se integracijski konflikti in težave z okolji močno zmanjšajo.
- Kulturni premik k CI miselnosti. Ker je CI postal tako rekoč pogoj za dopolnjen DoD, to tim vodi v smer “production ready” po vsaki spremembi.
Recimo, da razvojnik zaključi funkcionalnost “Nalaganje profilne slike uporabnika”.
Stari DoD: funkcionalnost se združi v dev vejo, QA jo testira v naslednjem sprintu, nato se čez tedne združi v glavno vejo.
Novi DoD: funkcionalnost je potrebno še danes integrirati v glavno vejo, kar sproži:
- avtomatično gradnjo (build),
- statično analizo kode za odkrivanje napak, odstopanja od standardov in ranljivosti (ESLint, Flake8…),
- unit teste,
- integracijske teste,
- regresijske teste,
- namestitev v testno/staging okolje.
Če takšen cevovod (pipeline) pade, funkcionalnost ni zaključena.
S takšnim vseobsegajočim DoD tim v praksi začne izvajati Continuous Integration (CI) ob vsakem zaključenem PBIju, četudi CI formalno nikoli ni bil razglašen kot cilj.
Zakaj torej organizacije ne izvajajo releasov v produkcijo sproti?
Prvi razlog je seveda ker: “Pri nas so zadeve drugačne/bolj kompleksne/regulirane/povezane… ⇐ izberi najljubšega”. Sledi spisek najpogostejših “razlogov” in rešitev:
Iz zgornje tabele vidimo, da širitev DoD v smeri zagotavljanja Continuous Integration/Continuous Deployment zahteva tudi sodelovanje višjega managementa, saj marsikje posega v delovanje same organizacije.
Na začetku razvoja/projekta, bo DoD verjetno precej daleč od ideala. Razlogi za to so lahko trenutno še nezadostno tehnično znanje razvojnikov, premajhen obseg razvoja, da bi se formirali resnični večfunkcijski teami, izolacija razvojne iniciative od ostalih delov organizacije ali nepoznavanje problematike iniciative.
Ob koncu iteracij, funkcionalnosti zaključene na osnovi te nepopolne DoD, verjetno ne bojo neposredno primerne za vključitev v produkcijo. Neopravljene (a za release pomembne dejavnosti) bi bile na primer lahko neizvedeni regresijski, performance in/ali uporabniški testi, uporaba različnih verzij APIjev in različnih programskih vzorcev (design patterns) v sorodnih modulih. To nedokončano delo je tisto kar teame loči od ideala Continuous Deployment.
Seveda več iteracij kot mine brez releasa, večja je zaloga nedokončanega dela. To lahko ustvarja lažni občutek napredka. Ko pa se management odloči, da je čas za release, se izkaže, da funkcionalnosti še zdaleč niso primerne za vključitev v produkcijo in je za to potrebnega še precej dela.
To zagato organizacije rešujejo na različne improvizirane načine:
- Hardening sprint/iteracija je namenjena izključno optimizaciji kode, ki naj bi “nekako” že bila pripravljena na produkcijo, pa očitno temu ni tako.
- Release sprint/iteracija je namenjena pripravi razvite kode na integracijo v produkcijo. Običajno to pomeni, da razvoj ni testiral v testnem okolju, ki je bilo kopija produkcije.
- Integracijski team, ki sproti integrira kodo ostalih teamov v funkcionalno celoto.*
- Undone team, ki sproti prevzema nedokončano delo in ga zaključuje, ter tako pripravi na release – sanjska služba 🙁
Vse zgoraj našteto so neželeni vzorci.
* Nekateri Scaled Agile frameworki (Nexus, SAFe) sicer predvidevajo integracijske teame, vendar njihova primarna naloga ni neposredna integracija kode, ampak pomoč teamom pri procesu integracije.
Takšen neplaniran zamik releasa je lahko za organizacijo težek udarec, saj se releasi pogosto usklajujejo z vzporednimi dejavnostmi, ki jih je potrebno planirati v naprej. To so na primer marketinške kompanije, javne napovedi produkta, partnerske konference, izobraževanje članov poprodajne podpore in finančni tokovi.
Verjetno se strinjamo, da je vseobsegajoči (idealni) DoD koristen za doseganje Agilne fleksibilnosti, optimizacijo dela in hitrejši ROI. Kaj organizacijam preprečuje širitev DoD?
Generični odgovor na to vprašanje bi bil, da “je ovire za evolucijo DoD potrebno iskati na vseh nivojih organizacije. Še posebej z analizo interakcije posameznih delov sistema (systems thinking) …. bla, bla, bla”. V praksi pa bo vsak razvojni team sam najbolje vedel povedati, kaj jih ovira pri doseganju cilja Continuous Integration/Continuous Deployment in s tem povezane idealne DoD.
Ko organizacija identificira razloge za neoptimalni DoD, se njihova odprava doda v organizacijski ali produktni backlog (glede na to ali gre za strateške ali operativne spremembe). V naslednjem ciklu se spremembe implementirajo in v par naslednjih ciklih ovrednotijo. Uspešne spremembe se ohrani ali nadgradi, neuspešne pa zavrže.
Širitev DoD je za zainteresirano vodstvo ključno orodje pri uveljavljanju organizacijskih sprememb. Ključna beseda prejšnjega stavka pa je “zainteresirano“. Agilna transformacija je izven obsega tega članka. S tem izzivom se obširno ukvarjata Scaled Agile frameworka LeSS in Scrum@Scale. Vsak na svoj način, rdeča nit obeh tipov transformacij, pa je upoštevanje dobrih Agilnih praks in razširjanje te mentalitete na ostanek organizacije. Širitev DoD je pri tem lahko koristno orodje.
Več o zahtevnejših Agilnih pristopih zveste na tečaju Scaled Agile.
Spodnja tabela opisuje nivoje organizacijske zrelosti, ki pogojuje tudi največji možni obseg Definition of Done.
Zaključek
Definition of Done je nujno orodje zagotavljanja kvalitete razvijanega produkta. Istočasno pa njeno dopolnjevanje v smer Continuous Integration katalizira za to nujne organizacijske spremembe. Rezultat je vse Agilnejša organizacija, ki žanje vse več prednosti tega pristopa.
