Az elfogadási kritériumok fontossága és szerepe a projektekben

Az elfogadási kritériumok fontossága és szerepe a projektekben

Egy termék fejlesztésekor- legyen az egy alkalmazás vagy szoftver -, vagy épp egy marketing kampány tervezése során felmerül a kérdés, hogy honnan tudhatjuk, hogy amit készítünk, megfelel-e az ügyfelek vagy felhasználók elvárásainak? Nos, ezt határozzák meg az elfogadási kritériumok. És bár ezek nem kötődnek szorosan a scrum keretrendszerhez, mégis sok scrum és agilis csapat használja őket a munka megszervezéséhez és a projekt sikerek eléréséhez. Cikkünkben most megnézzük, hogy mik is azok az elfogadási kritériumok, hogyan egészítik ki a user story-t és miért szükségesek, hogy eredményesek lehessünk? Bemutatunk néhány példát is, hogy hogyan érdemes megírni és milyen hibákat célszerű elkerülni.

Az elfogadási kritériumok a termék érintettjei (ügyfelek, felhasználók stb.) által definiált elvárások, feltételek, igények egy fejlesztéssel kapcsolatban.

Mi az az elfogadási kritérium?

Az elfogadási kritérium (angolul: acceptance criteria) a termék érintettjei – ügyfelek, felhasználók stb. – által definiált elvárásokat, feltételeket és igényeket jelenti egy fejlesztéssel kapcsolatban. 

A kritériumok vagy teljesülnek, vagy nem egy projekt kapcsán, nincs olyan, hogy részben valósulnak meg. Nem arra fókuszálnak, hogy hogyan kell eljutni a megoldáshoz, miként valósul meg a feladat, hanem a pontos célt tűzik ki. 

A formálisan megfogalmazott elfogadási kritériumok agilis gyakorlata a szoftverfejlesztési projektektnél született meg, de ma már a legkülönbözőbb iparágakban – az alkalmazás fejlesztéstől kezdve a humánerőforrás osztályokig  – számos területen alkalmazzák.

Az elfogadási kritériumok szerepe, hogy kiegészítsék a user storyt.

Mi a különbség a user story és az elfogadási kritérium között?

Az elfogadási kritériumok nem azonosak a user story-val, sokkal inkább kiegészítik azt. A felhasználói történet az ügyfél igényeinek rövid leírása, tartalmazza a céljaikat és a megoldandó problémáikat.

Az elfogadási kritériumok pedig azt definiálják, hogy mi a teendő ezen célok elérése érdekében.

Ily módon a felhasználói történet a munka “miértjét” írja le, míg az elfogadási kritériumok a “mit”. A “hogyan”-ról pedig a fejlesztők döntenek a sprintek során.

Miért fontos és mi célja az elfogadási kritériumnak?

Nézzük most meg, hogy milyen konkrét célokat szolgál az elfogadási kritérium a projektmunka során!

Részletezi a funkció hatókörét

Az elfogadási kritérium részletezi a funkcionalitást, amely segít a csapatnak megérteni, hogy a user story-ban foglaltak elkészültek-e és az elvárásoknak megfelelően működnek-e.

Negatív forgatókönyvek leírása

Az elfogadási kritériumok megkövetelhetik például, hogy a rendszer felismerje a nem biztonságos jelszavakat, és ilyen esetben megakadályozza, hogy a felhasználó továbblépjen. Az érvénytelen jelszó formátum is egy gyakori példa az úgynevezett negatív forgatókönyvre.

Meghatároz tehát bizonyos negatív szcenáriókat, és hogy a rendszernek mindezekre hogyan kell reagálnia.

Kommunikáció finomhangolása

Az elfogadási kritériumok szinkronba hozzák az érintettek és a fejlesztőcsapat elképzeléseit. Biztosítják, hogy a követelményeket mindenki ugyanolyan módon értelmezze. Tehát összhangban legyen, hogy az ügyfelek vagy felhasználók és más érdekelt felek mit várnak el, és a fejlesztők is tudják, hogy egyes funkcióknak ezekhez mérten hogyan kell működniük.

Az elfogadási teszt egyszerűsítése

Az elfogadási kritériumok a user story elfogadási tesztjének alapjául szolgálnak. Minden egyes kritériumnak önállóan tesztelhetőnek kell lennie, és egyértelműen sikeres vagy sikertelen forgatókönyvekkel rendelkeznie. Ezek segítségével automatizált teszteken keresztül is ellenőrizhető a történet.

Funkcióértékelések elvégzése

Az elfogadási kritériumok meghatározzák, hogy pontosan mit kell a csapatnak fejlesztenie. Amennyiben egyértelműen lefektetésre kerülnek a követelmények, a user story-kat helyesen becsülhető feladatokra lehet bontani.

Mivel egy problémával kapcsolatban a különböző embereknek eltérő nézőpontjaik és megoldási ötleteik lehetnek, egységes álláspont kialakítása szükséges arról, hogy a funkciónak mit kell tudnia.

Ki fogalmazza meg az elfogadási kritériumokat?

Az elfogadási kritériumok arra adnak választ, hogy egy ügyfél mit vár az elkészült terméktől, hiszen minden fejlesztés célja az, hogy aki használja, elégedett legyen.

A projektek sokszor egyedi iparágakban futnak, ezért nem feltétlenül egy hagyományos ügyféltől származnak a kritériumok, hanem elképzelhető, hogy a product owner vagy az érdekelt felek, illetve más típusú ügyfél vagy felhasználó elvárásaiból születnek.

Hogyan hozzuk létre az elfogadási kritériumokat?

Ezek meghatározása az alábbiak szerint történhet:

  • Egyeztetések nyomán az ügyfelekkel vagy megbízókkal
  • Az érdekelt felekkel folytatott megbeszélések alapján
  • Scrum finomítás során
  • Scrum sprint tervezéskor
  • Product backlog menedzsment tevékenységek alkalmával
  • Csapat brainstorming során
  • Az ügyfelek vagy végfelhasználók visszajelzéseinek értékelése után

A scrum csapatokban többnyire a product owner felelős ezeknek az elfogadási feltételeknek a megírásáért, azonban a fejlesztőcsapatot is be lehet és bele is kell vonni, hogy a PO elvárásaihoz igazodva segítsék a munkát szakértelmükkel és visszajelzéseikkel.

A scrum master támogathatja a folyamatot azzal, hogy megvizsgálja a kritériumokkal kapcsolatos esetleges aggodalmakat, segít a csapatnak megérteni a kritériumok célját, és bátorítja a fejlesztőket, hogy jelezzék, amennyiben ezek nem egyértelműek. 

Ilyen módon valóban csapatmunka jöhet létre, még akkor is, ha a product owner ügyfélközelisége gyakran a kritériumok kidolgozásának kiindulópontja.

Mikor kell elkészülniük az elfogadási kritériumoknak?

A scrumban a tervezés és finomítás részeként folyamatosan szó esik a product backlog elemekről. A kezdeti kritériumok gyakran a backlog finomítása során kerülnek meghatározásra, a véglegesítést azonban közvetlenül a fejlesztés megkezdése előtt célszerű elvégezni. 

Ez biztosítja, hogy a legfrissebb információk alapján haladhasson a munka. A kritériumok véglegesítésének a sprint tervezéskor kell történnie. A scrum csapat áttekinti a kritériumokat, megvitatja az esetleges problémákat vagy tisztázandó kérdéseket, és eldönti, hogy a munka bevonható-e a sprintbe.

Az elfogadási kritérium fontossága abban rejlik, hogy megfogalmazza, mit kell tenni a probléma megoldása vagy a cél elérése érdekében.

Hogyan írjuk meg az elfogadási kritériumokat?

A scrum útmutatóban sajnos nem találunk iránymutatást erre vonatkozóan, mivel az elfogadási kritériumok elkülönülnek a scrum keretrendszerétől. Az interneten fellelhetők különféle sablonok, de készíthetünk egyéni dokumentumot is, mindenképpen érdemes kipróbálni, hogy melyik működik legjobban a csapat esetében.

Milyen formában készülhetnek az elfogadási kritériumok?

  • ellenőrző listaként pontokba szedve vagy számozva
  • táblázat formátumban
  • rövid leírásként
  • forgatókönyv alapú sablonként

Sokan egyszerű ellenőrző listát használnak, ami egyrészt könnyen létrehozható, másrészt jól elhelyezhető a user story-ban. De vannak, akik még a retro megoldások hívei és post-iteket használnak. Érdemes ezt a csapat igényeihez igazítani.

Vannak olyan agilis csapatok, akik forgatókönyv alapú sablont alkalmaznak, amiben azt írják le, egy adott kontextus vagy előfeltétel esetén, ha bizonyos műveletet elvégeznek, annak mi lesz az eredmény.

Milyen a jó ellenőrző lista?

  • Minden érintett számára egyértelmű
  • Tesztelhető vagy ellenőrizhető
  • Az eredményre összpontosít, nem annak elérési módjára
  • Konkrétumokat tartalmaz (pl. gyors oldalbetöltési sebesség helyett 3 másodperces oldalbetöltési sebesség)

példák

Most pedig tekintsünk meg néhány gyakorlati példát!

1. példa: Elfogadási kritérium lista hitelkártya egyenleg megtekintéséhez

User story: Hitelkártya tulajdonosként szeretném megtekinteni a számlám egyenlegét, hogy befizethessem az esedékes összeget.

Kritérium lista:

  • Hitelesítéskor a számlaegyenleg megjelenítése (pl. 156 000 Ft)
  • A teljes egyenleg megjelenítése (pl. 356 000 Ft. Itt a folyó időszakból származó egyenleg 256 000 ft, a múltbeli egyenleg pedig 100 000 Ft)
  • Minimum fizetendő összeg megjelenítése. (pl. 14 000 Ft)
  • Fizetési határidő megjelenítése (pl. aktuális hónap 20-a)
  • Hibaüzenet megjelenítése, ha a szolgáltatás nem válaszol, illetve időtúllépés esetén (Pl. ‘Sajnálom, valami hiba történt. Kérjük, próbálja meg újra.’)

2. példa: Forgatókönyv alapú elfogadási kritériumok elfelejtett jelszó esetén

User story: Felhasználóként szeretném visszaállítani a fiókom jelszavát, ha elfelejtettem a jelszót, hogy be tudjak ismét lépni a fiókomba.

Hogy néz ki a forgatókönyv típusú kritérium?

Forgatókönyv: Elfelejtett jelszó

  • Adott: A felhasználó a bejelentkezési oldalra navigál
  • Amikor: A felhasználó kiválasztja a <jelszó elfelejtése> opciót.
  • És: Megadja az érvényes e-mail címét, hogy megkapja a jelszó helyreállításához szükséges linket.
  • Ezután: A rendszer elküldi a linket a megadott e-mail címre.
  • Adott: A felhasználó megkapja a linket az e-mailben
  • Mikor: A felhasználó rákattint az e-mailben kapott hivatkozásra.
  • Ezután: A rendszer lehetővé teszi a felhasználó számára, hogy új jelszót állítson be.

Milyen hibákat követhetünk el az elfogadási kritériumok megírásakor?

Bár az elfogadási kritériumok meghatározása nincs kőbe vésve, és érdemes a csapat igényeihez igazítani, van néhány gyakori buktató, amire célszerű odafigyelni.

  • A felhasználói nézőpont figyelmen kívül hagyása
  • A fejlesztőknek megmondjuk, hogy “hogyan” végezzék el a munkát
  • Túl korán írjuk meg az elfogadási kritériumokat
  • Csak azután készülnek el az elfogadási kritériumok, hogy a fejlesztés már folyamatban van
  • A kritériumok nem egyértelműek
  • Túl sok az elfogadási kritérium

Szeretné elmélyíteni tudását az agilis módszertanokban? Fejlessze gyakorlati eszköztárát és szerezzen nemzetközi minősítéseket! Tekintse meg aktuális agilis képzéseinket!