Az elfogadási kritériumok az elfogadási kritériumok megírásához

Sok fejlesztőcsapat túlságosan ismeri a nem kielégítő elfogadási kritériumok csalódását vagy akár a kritériumok hiányát. A követelmények meghatározása olyan, mintha cselekvési terv nélkül készülnénk a csatára - a csapat több lépést tett a kudarc, mint a siker felé. Konkrét javaslatokat kínálok az elfogadási kritériumok kidolgozásában, amelyek bármilyen agilis folyamatot javíthatnak.

Először határozzuk meg gyorsan az elfogadási kritériumokat.

Az elfogadási kritériumok azok a „feltételek, amelyeknek egy szoftverterméknek meg kell felelnie ahhoz, hogy elfogadja a felhasználó, az ügyfél vagy más érdekelt fél.” (Microsoft Press)

Elég könnyű, igaz? Nem egészen. Ezen a ponton azt kérdezném magamtól, hogy itt áll-e le az elfogadási kritériumok meghatározása. A fenti meghatározás mellett a termék minden tulajdonosának készen kell állnia a válaszokra a következő kérdésekre:

Hogyan néznek ki ezek a körülmények? Ki teremti meg ezeket a feltételeket? Hány feltételnek kell lennie? Hogyan mérik az eredményeket?

Az elfogadási kritériumokat általában a termék tulajdonosa vagy az érdekelt felek kezdeményezik. A funkció bármilyen fejlesztése előtt íródnak. Feladatuk, hogy iránymutatásokat nyújtsanak üzleti vagy felhasználóközpontú perspektívához.

A kritériumok megírása azonban nem kizárólag a termék tulajdonosának feladata. Az elfogadási kritériumokat a fejlesztőcsapat és a terméktulajdonos közös erőfeszítéseként kell kidolgozni.

E kritériumok együttes kidolgozása segít a fejlesztői csapatnak megérteni a vágyat. Ez a termék tulajdonosának is segítséget nyújt a hiányzó részletek felfogásában. Ezenkívül a tulajdonos jobban megismeri a megvalósíthatóságot, az összetettséget és a hatókört.

Az elfogadási kritériumok formázása

A kritériumokat többféle formátumban lehet megírni. A legtöbb csapat két konkrét típus felé hajlik: szabály-orientált vagy forgatókönyv-orientált .

A szabályorientált követelmények egyértelműek. Megfigyelhető eredményeket sorolnak fel. "A kimutatás egyenlegének megjelenítése a sikeres hitelesítéskor."

Másrészt a forgatókönyv-orientált kritériumok általában követik az „Adott… Amikor… Akkor…” sablont. Ez a viselkedésvezérelt fejlesztésből (BDD) származott. Ez a követelmény felvázolja a várható megfigyelhető eredményt. Ez akkor fordul elő , amikor egy adott intézkedés végrehajtjuk adott némi összefüggésben.

A tényleges elfogadási kritériumok 3 jellemzője

1. Tesztelhető egyértelműen meghatározott passz / sikertelenség eredményekkel

Legyen tesztelhető kritériuma. Ez lehetővé teszi a tesztelők számára, hogy megfelelően ellenőrizzék, hogy az összes kívánt feltétel teljesült-e. Ha a kritériumok nem lennének tesztelhetők, akkor nem lehetne ellenőrizni. Ezeknek a kritériumoknak vagy teljesülniük kell, vagy nem teljesülniük. A fejlesztőnek ismernie kell azt a pontot, amelyben a kritérium teljesült. Bármilyen kétértelműség meghosszabbíthatja a történettel kapcsolatos erőfeszítéseket.

Például egy elfogadási kritérium szerint „növelje a legördülő menüben elérhető bejegyzések számát”. A fejlesztőnek fogalma sincs arról, hogy hány új bejegyzést kell felvenni, és megengedheti magának, hogy számot vállaljon a termékkel kapcsolatos tapasztalatai alapján. Hasonlóképpen, a manuális tesztelő ugyanolyan szabadságot vehet fel, és a növekedés más meghatározását is felveheti. Ez zavart eredményez, amely visszakerül a termék tulajdonosához.

2. Egyértelmű és tömör

Itt válik művészetté az elfogadási kritériumok megírása. Az akadémiai esszék hangsúlyozzák az egyértelműség és a tömörség fontosságát. Hasonlóképpen, az elfogadási kritériumok megírása azonos szintű szervezést és gondozást ír elő.

Az irodalmi darab megírásához hasonlóan a közönséget is szem előtt kell tartani. Az elfogadási kritériumokat olvasóknak meg kell érteniük az írást. Egyébként ezek a szavak teljesen haszontalanok. Ha hosszadalmasak és zsargonnal vannak tele, akkor a felvázolt feltételek főbb pontjai nem feltétlenül találkoznak. Sok ember figyelmen kívül hagyhatja a lényeges részleteket a szavak tengerében, ha időre szorul. Még ha nem is nyomják meg idővel, sokan könnyedén át tudják fényezni a hosszú elmosódásokat.

Ahelyett, hogy mások gondos olvasásának hiányát vádolnánk, proaktívan be lehet mutatni az elfogadhatósági kritériumokat, amelyek könnyen olvashatók, egyenesen a lényegre törnek, és nem tartalmaznak felesleges részleteket.

3. Teremtsen közös megértést

Valószínűleg ez a legfontosabb és a magától értetődő tulajdonság. Ha a csapat összes tagja nincs egy oldalon, akkor a folyamat és a termelékenység veszélybe kerül. Ha a fejlesztő csapat áttekinti az elfogadási kritériumokat, mielőtt továbblépne a sztorival, minimalizálja a zavart. Pontosítani kell a kritériumokat, és a kritériumokat ennek megfelelően frissíteni kell.

Voltak tapasztalataim, amikor a csapat minden tagja részt vett az elfogadási kritériumok megírásában. Ez lehetővé tette, hogy mindenki megértse a történet minden részét. Lehetőséget biztosított a csapattagok számára kérdések és ötletek harangozására is. Ez a folyamat azonban nem mindig lehet ideális, különösen a nagyobb csapatok számára.

Mindazonáltal fontos, hogy minden tag olvassa el az elfogadási kritériumokat. Innentől kezdve minden tagnak meg kell értenie, hogyan lehet a történetet befejezni. Függetlenül attól, hogy fejlesztés alatt áll, vagy tesztelés alatt áll.

Amikor a túl sok kérdés

Már tisztáztuk a nem egyértelmű elfogadási kritériumok veszélyét. Ez azt a kockázatot eredményezi, hogy idegen jellemzők kerülnek be a történetbe. Létezhet azonban a meglepő ellentétes eset is: az elfogadási kritériumok túl részletesek lehetnek.

„Az elfogadási kritériumoknak szándékot kell tartalmazniuk, nem pedig megoldást” ( Segue Technologies )

Adja meg a „mi” (szándék) tervét a „hogyan” (megvalósítás) helyett. Ellenkező esetben a fejlesztőcsapattól el lehet rabolni a lehetőséget a probléma megoldásának különböző módjainak feltárására. Ezeken a vonalakon jobb megvalósításokat lehet kitalálni a megoldással kapcsolatos kezdeti gondolatok után.

Miután megírta elfogadási kritériumait, megkérdezheti magától: „Hány a túl sok?”

Láttam olyan történeteket, amelyek a nulla elfogadási kritériumtól a több mint tizenötig terjednek (vagy legalábbis ilyen érzés volt).

Alapszabályként személy szerint három-nyolc elfogadási kritériumot szeretnék látni történetenként. Ennek a határnak a felső vége felé, öt vagy több elfogadási kritérium körül azonban ellenőrizném a kezelhetőséget. Gondosan ellenőrizném, hogy a történetet nem lehet-e kisebb, könnyebben kezelhető történetekre bontani.

Mások nem értenek egyet és azzal érvelnek, hogy nyolc már túl sok lenne. Szeretek azonban hajlamosak lenni minél több „mi” részletre, anélkül, hogy a tömörséget feláldoznám.

Most mi?

Ok, hazudtam. Az elfogadási kritériumok megírásához nem nyújtottam be teljes listát az elfogadási kritériumokról. A kívánt tulajdonságok, mint a tömörség, az áttekinthetőség és a megértés, szubjektívek. Szántam őket.

Úgy gondolom, hogy az elfogadási kritériumok megírásához nincs „helyes” formátum. Helyességüket a csapat eredményessége méri.

Nagyon ajánlom a sablon használatát. Számos csapat számára szilárd és biztonságos felépítést biztosítottak, amely elősegíti a jó elfogadási kritériumok megfogalmazását. Azonban ne hagyja, hogy ez a szerkezet megakadályozza Önt abban, hogy olyan ötletekbe lépjen, amelyek elősegíthetik a hatékonyságot és eredményességet.

Ha Ön terméktulajdonos vagy ügyfél, aki elfogadási kritériumokat ír, akkor arra kérem Önt, hogy kérjen visszajelzést a fejlesztői csapatától a jelenlegi elfogadási kritériumokról. Egy kis odafigyeléssel, gyakorlással és szervezettséggel a hatékony elfogadási kritériumok kidolgozása hatékony eszközzé válik bármely csapat munkafolyamatának javításában.

További olvasnivalók

• //rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important - írta Maryna Z. és Dmiriy G.
• Steve Povilaitis: //www.leadingagile.com/2014/09/acceptance-criteria/
• //www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/, készítette: Segue Technologies
• //agileforgrowth.com/blog/acceptance-criteria-checklist/ - írta Kamlesh Ravlani