Mi a különbség: Acceptance Criteria vs. Definition of Done?

Pár, sokszor félreértett fogalom tisztázásáról szeretnénk írni nektek: az Acceptance Criteria és a Definition of Done közötti különbségről van szó. Sok szervezetben ez a kettő összemosódik, nincs éles határ közöttük, pedig a két fogalom jelentése teljesen más, és más célt is szolgál.

Mi a User story?

Agilis környezetben, amennyiben a termék jellege és az azt előállító szervezet felépítése megengedi, ún. User story-kat szoktunk alkalmazni a követelmények megfogalmazására. A User story formátum az Extreme Programming (XP) gyermeke, és kifejezetten alkalmas arra, hogy a termék majdani felhasználójának szemszögéből fogalmazzon meg igényeket és követelményeket, mely megközelítés komoly segítséget nyújt a helyes fókusz és hozzáállás szem előtt tartására.

A User story egy könnyű, inkább a célra és kevésbé a részletekre összpontosító formátum. Célja, hogy mind az üzleti mind a szállítási szervezet tagjai azonos megértésre jussanak egy feladat céljairól, és ehhez a legmegfelelőbb megoldást tudják kiválasztani, majd implementálni. A User story nem tartalmaz megvalósítási részleteket, csakis üzleti célok megfogalmazására koncentrál.

Egy User story jellemzően három részből áll:

1. Agile vagy header sentence: Mely megfogalmazza, hogy:

– kinek a szemszögéből írjuk meg az igényt (persona), 
– mi az az interakció, amit az a személy szeretne, 
– és végül, de messze nem utolsó sorban: miért szeretné ő ezt? Mi a célja vele?

Pl. “Én, mint kardiológus orvos, szeretnék egy lista képernyőt a pácienseimről, mert szeretném megvizsgálni, kik azok, akik alkalmasak lehetnének egy kísérleti gyógyszer kutatási programjában résztvenni”

2. Description, leírás: Ide szoktuk azokat az információkat felsorolni, ami az elképzelés mögött áll, tehát a részleteket.

Pl.: “lista képernyő, a következő attribútumokkal (oszlopokkal), az oszlopok legyenek sorrendezhetőek, egyszerre több elemet is ki tudjak választani a listáról (multiselect), 20 találatonként oldaltörés történjen, lehessen a találati oldalak között navigálni, a neveket mindig vezetéknévvel kezdje, előtag (pl. Dr., stb.) nélkül, stb.)

 3. Acceptance criteria, azaz elfogadási kritérium

Mi az Acceptance Criteria?

Magyarul elfogadási kritériumnak nevezzük azt, amikor egy User story formátumban megírt igényt kiegészítünk olyan rövid, magvas szempontrendszerrel, aminek meg kell felelnie az adott fejlesztésnek. Ezek a szempontok lehetnek felsorolás jelleggel egyszerű vagy összetett  mondatok.

Például:

– A lista képernyőn látom a páciensem nevét, 
– A lista képernyőn látom a páciensem osztályra kerülésének dátumát, 
– A lista képernyőn látom a páciensem gyógyszerérzékenységét (ha van)
– A lista képernyőt tudom sorrendezni mindhárom  attribútumnak megfelelően
– A lista képernyő 20 tételenként oldaltörésre kerül

Az elfogadási kritérium tehát egy funkcionális kritérium lista. Minden követelményhez (User story) tartozik elfogadási kritérium, és ezek mindegyik követelménynél különbözőek, megfelelően az adott követelmény tartalmának.

Fontos, hogy az elfogadási kritérium már ne tartalmazzon új információt, amit esetleg a header sentence vagy a description nem tartalmazott. Az elfogadási kritérium már csak ennek a kettőnek a tartalmára reflektáljon.

Fontos az is, hogy ne minden részletre írjunk elfogadási kritériumot. Itt is érvényes az agilis csapatok méreténél is alkalmazott, úgynevezett Miller-ciklus, azaz 7 +/-2 db. Ha ennél több elfogadási kritérium az már azt feltételezi, hogy túl nagy a User story-nk és további darabolására van szükség.

Az elfogadási kritérium segíti a fejlesztőket és a tesztelőket a User story-ban megfogalmazott cél elérésében, és az elérése validálásában.

Mi a Definition of Done?

Definition of Done-nak, azaz a “Kész fogalmának” nevezzük azt a nem-funkcionális kritérium listát, amely kondícióknak minden egyes követelmény/igény (User story), ami átmegy a csapat kezei között, meg kell feleljen az iteráció végén.

Tehát, amíg elfogadási kritériuma minden egyes User story-nak van, és azok eltérőek, specifikusak, addig egy csapatnak vagy terméknek csak egy Definition of Done-ja van, és az minden egyes User story-ra érvényes.

Úgy kell elképzelni, mintha egy őr állna annál az ajtónál ahol kiadjuk a kis implementációinkat, csomagjainkat, és ellenőrizné azokat. Az őr nem az egyes csomagokat nézi át tüzetesen tartalmukban, funkcionalitásukban, hanem csak azt vizsgálja, hogy megfelelnek-e az általános kritériumoknak.

A Definition of Done-ban mi a következő 6 kategóriát szoktuk megkülönböztetni:

– Kódminőségi elvárások
– Fejlesztői tesztelési elvárások
– Funkcionális tesztelési elvárások
– Dokumentációs elvárások
– Általános üzleti követelmények
– Nem-funkcionális követelmények

A fenti példánknál maradva egy ilyen lista képernyőt előállító termékfejlesztő csapat jellemzően a következőhöz hasonló Definition of Done-nal tud operálni:

Például a backlog item esetében:

– commit-olva kell lennie az integration branch-be  
– code review megtörtént sikeresen
– tesztek lefutottak sikeresen, tesztjegyzőkönyv csatolva
– érintett dokumentáció frissítve/elkészítve
– demo-ra elő van készítve (tesztadatok, telepítés, stb.)
– feladatkövető rendszerben task-jai Done állapotban vannak, nincs nyitott feladata

Másik példa az Acceptance Criteria és Definition of Done közötti különbségre

Legyen a termékünk egy mobilalkalmazás, ami a kottaolvasás gyakorlásában segíti a felhasználókat. A termék backlogjának egy eleme lehetne a következő user story:

Hogy nézne ki ennek egy User story-ja?

Én, mint kezdő zongorista
Szeretnék violin- és basszuskulcsban írt kottákon is gyakorolni
Azért, hogy mindkét kulcsban megtanuljak blattolni.

Acceptance Criteria példa

A story Acceptance Criteria-ja lehet például:

– A gyakorlás indításakor az alkalmazás megkérdezi, milyen kulcsban szeretne gyakorolni a felhasználó (violin/basszus)
– A hangjegyek elhelyezése a kiválasztott kulcsnak megfelelő
– A kotta scrollozása közben a kulcs nem scrollozódik, fixen látszik a sor elején

Definition of Done példa

Mivel a Definition of Done a teljes termékre, a termék minden backlogelemére vonatkozik, abban általánosabb elvárások vannak, például:

– Minden változás be van commit-olva a fő branchbe
– Minden felület megfelel a UX guideline-nak
– Az alkalmazás minden képernyője mind portrait, mind landscape módban használható (a teljes képernyőtartalom látszik, minden interakció elérhető, …)

 

Írta: Schweinitzer Zoltán, Sprint Consulting