Mi a felhasználói történet és Elfogadási Kritériumok (példák)

tökéletes útmutató a felhasználói történet elfogadási kritériumaihoz valós forgatókönyvekkel:

a szoftverfejlesztő iparban a “követelmény” szó meghatározza, hogy mi a célunk, amire az ügyfeleknek pontosan szükségük van, és mi teszi cégünket üzleti tevékenységének növelésére.

legyen szó akár szoftvertermékeket gyártó termékvállalatról, akár egy olyan Szolgáltató cégről, amely különböző szoftvermezőkön kínál szolgáltatásokat, mindegyik számára a legfontosabb alap a követelmény, a sikert pedig az határozza meg, hogy a követelmények mennyire teljesülnek.,

a “követelmény” kifejezés különböző nevekkel rendelkezik a különböző projektmódszerekben.

vízesésben “követelmény/specifikációs dokumentum” – nak, agilis vagy SCRUM-ban “Epic” – nek, “felhasználói történetnek” nevezik.

alatt vízesés modell, a követelmény dokumentumok hatalmas docs 200 vagy több oldalt, mint az egész termék végre egy fázisban. De nem ez a helyzet az agilis / SCRUM esetében, mivel ezekben a módszertanokban a követelmények kis funkciókra vagy funkciókra vonatkoznak, mivel a terméket lépésről lépésre készítik el.,

ebben a cikkben mindent megtettem, hogy megosszam az összes 4 éves tapasztalatomat a felhasználói történetekkel és azok kapcsolódó elfogadási kritériumaival, valamint az egyszerű és egyszerű valós forgatókönyvekkel a jobb megértés érdekében.

először nézzük meg újra az alapokat.

mi a felhasználói történet?

a felhasználói történet minden olyan funkció vagy szolgáltatás követelménye,amelyet egy vagy két sorban írnak le, legfeljebb 5 sorban. A felhasználói történet általában a lehető legegyszerűbb követelmény, és csak egy funkcionalitásról (vagy egy funkcióról) szól.,

A felhasználói történet készítésének leggyakrabban használt szabványos formátuma az alábbiakban található:

<felhasználói szerep/ügyfél, Szeretnék<elérni kívánt cél>hogy tudok<A cél oka>.

példa:

WhatsApp felhasználóként szeretnék egy kamera ikont a chat írási mezőbe képeket rögzíteni és küldeni, hogy a képeimet egyszerre kattinthassam és megoszthassam a barátaimmal.

mi az elfogadási kritérium?,

az elfogadási kritérium olyan elfogadott feltételek vagy üzleti szabályok halmaza, amelyeket a funkcionalitásnak vagy funkciónak meg kell felelnie és meg kell felelnie annak érdekében, hogy a termék tulajdonosa/érdekelt felei elfogadják.

Ez egy nagyon fontos része a felhasználói történet befejezésének, és azt a Terméktulajdonosnak és az üzleti elemzőnek nagyon aprólékosan kell tanulmányoznia, mivel egyetlen kritérium hiánya sokba kerülhet. Ez egy egyszerű számozott vagy felsorolásos lista.

formátuma a következő:

“bizonyos előfeltételeket adva, amikor valamilyen műveletet végrehajtok, akkor várom az eredményt”.

példa (w.r.,t a fenti felhasználói történet):

• vegyük figyelembe, hogy én beszélgetni egy barátommal, és képesnek kell lennie arra, hogy elfog egy képet.
• amikor rákattintok egy képre, képesnek kell lennem feliratot hozzáadni a képhez, mielőtt elküldöm.
• ha valamilyen probléma merül fel a telefon kamerájának indításával, akkor egy hibaüzenet, például a “kamera nem indítható el”. stb., ennek megfelelően kell feltüntetni.

ezért a felhasználói történet meghatározza Bármely funkció vagy szolgáltatás követelményét, míg az Elfogadási Kritériumok meghatározzák a felhasználói történet vagy a követelmény “kész definícióját”.,

QA-ként nagyon fontos megérteni a felhasználói történetet és annak elfogadási kritériumait, még egyetlen kétség sem maradt a “tesztelés kezdetén”. Haladjunk előre nézzük megérteni, hogy miért rendkívül fontos, hogy ásni “mély” a felhasználói történetek és elfogadási kritériumok.

Ásni mélyen a Felhasználó történetek

először nézzük először megérteni, milyen fontos egy alapos vizsgálat szerint alap, alapvető dolog, azaz a Felhasználó Történetek.

a következő esetek a saját valódi tapasztalataim.,

Case #1:

3 év előtt egy mobil Alkalmazásprojekten dolgoztam, a termék pedig egy olyan alkalmazás volt, amelyet a kézbesítőknek terveztek.

látta volna, hogy egy kézbesítő érkezik a kézbesítési helyre. És van egy mobiltelefonjuk, amin megkérik, hogy adja meg az aláírását a szülés után. Ez az aláírás tükrözi a futárszolgálat portálját, mint például a DTDC, a FedEx stb.

képzeljük el, hogy a mobilalkalmazás csak most indult el, portáljaik pedig már léteznek.,

probléma: egy Sprint esetében a termék tulajdonosának felhasználói története van ehhez a mobilalkalmazáshoz, amely “portál adminisztrátorként képesnek kell lennem arra, hogy megtekintsem a kézbesítő által a kézbesítéskor készített aláírást”. Itt a portál (webalkalmazás) ennek megfelelően módosul és frissül, hogy tükrözze az aláírást.

QA-ként ellenőriznie kell, hogy a mobilalkalmazásban rögzített aláírás a portálon várt módon tükröződik-e.,

Ha megnézzük ezt a felhasználói történetet, egyszerűnek tűnik, de itt van egy rejtett követelmény, hogy ” a történelmi szállítások esetében nem volt aláírás-visszaverődés funkció, tehát mi történik, ha a portál srácok történelmi szállításokat tekintenek meg?”A történelmi adatokat ki kell törölni? Engedélyeznünk kell az ilyen adatok összeomlását vagy hibáit?

természetesen egyáltalán nem, ezt kegyesen kell kezelni.,

megoldás: amikor a megfelelő DB táblákat frissítik az aláírás helyének új oszlopának hozzáadásához, a régi adatoknak NULL vagy 0 értékkel kell rendelkezniük, amelyet ellenőrizni kell, és egy “nincs aláírás” üzenetet kell megjeleníteni.

ezt a termék tulajdonosának vagy üzleti elemzőjének hiányának lehet nevezni, de ezt meg kell tenni. Az egyik funkció sikeres végrehajtása, de az ügyfelek nem kívánják, hogy valamit megtörjenek vele együtt. Ezt ugyanazzal a felhasználói történettel együtt, ugyanabban a sprintben kell elvégezni.,

Case #2

6 évvel ezelőtt egy Nyugdíjtervezési pénzügyi alkalmazáson dolgoztam (BA nélkül), amely egy globális alkalmazás volt, ahol a pénzügyi emberek, mint például a CA, a pénzügyi tanácsadók különböző valutákhoz használhatják a befektetési tervek, megtakarítások stb., egy nagy időszak alatt az ügyfelek.

probléma: a termék tulajdonosa olyan felhasználói történetet ad neked, amely “tanácsadóként az ügyfelem jelentését a megadott pénzügyi adatok alapján szeretném megtekinteni”.,

Itt volt 2 rejtett követelményeknek, valamint azt mondaná, hogy ez egy befejezetlen történet, mert:

a] A jelentések érdemes a napi árfolyamot, nem pedig a történelmi, mint a legutoljára megtekintett jelentés

b] Ha a valuta megváltozott biztosítása után az ügyfél pénzügyi részletek, a jelentések mutatják, hogy ebben a megváltozott valuta.

megoldás: közvetlenül felvetettem ezt az aggodalmat a termék tulajdonosával, és tudatosítottam vele, hogy mindkettőt a lehető leghamarabb meg kell tenni. Egyetértett velem, és 2 különböző történetet készített a közelgő sprintekhez prioritással.,

Vedd El: Ezek kapták el, mert mindannyian nagyon jól ismerjük a termékeket, a design, szerkezet stb. Ez a tudás csak a termék teljes megértésével érhető el, a modulok interoperabilitásának megértésével, valamint a felhasználói történet alapos tanulmányozásával, még akkor is, ha ez egy 2 bélés.

jegyzeteket készít, hogy megkönnyítse a dolgokat, és megbeszélje a BA-kkal és a fejlesztőkkel a gondolkodásukat.,

alaposan nézze meg az elfogadási kritériumokat

az elfogadási kritériumok és az összes többi feltétel megértése& a szabályok kimerítően még fontosabbak, mint a felhasználói történet alulértékelése. Mert ha egy követelmény hiányos vagy homályos, akkor a következő Sprintben felvehető, de ha hiányzik egy elfogadási kritérium, akkor maga a felhasználói történet nem adható ki.

azt hiszem, valamikor mindannyian használtuk volna a netbankot, és a legtöbben minden nap használjuk, és sokat töltöm le a történelmi nyilatkozataimat., Ha gondosan megfigyeli, vannak bizonyos speciális lehetőségek a letöltéshez.

lehetőség van a fájl típusának kiválasztására a nyilatkozat letöltéséhez. Van egy lehetőség, hogy válassza ki, ha szeretné letölteni csak a kredit / Debit / mindkettő.

most képzeljük el, hogy a termék tulajdonosa megadja neked ezt a felhasználói történetet “mint ügyfél, Szeretném letölteni a fióknyilatkozatomat, hogy megtekinthessem az összes tranzakciót egy adott időszakra”.,

a következő elfogadási kritériumokkal:

• tekintettel arra, hogy a letöltési történelmi nyilatkozat oldalon vagyok, ki kell választanom azt az időszakot, amelyre le akarom tölteni a nyilatkozatot.
• figyelembe véve, hogy a letöltési történelmi nyilatkozat oldalon vagyok, ki kell választanom azt a fiókot, amelyhez le akarom tölteni a nyilatkozatot.
• figyelembe véve, hogy a letöltési történelmi nyilatkozat oldalon vagyok, nem szabad megengedni, hogy letöltsem a nyilatkozatot a jövőbeli ” To ” dátumra.,
• figyelembe véve, hogy a letöltési történelmi nyilatkozat oldalon vagyok, nem szabad megengedni, hogy a múltban 10 évvel később válasszam ki a “From” dátumot.
• figyelembe véve, hogy letöltöttem a nyilatkozatomat, képesnek kell lennem a letöltött fájl megtekintésére.
• figyelembe véve, hogy a letöltési történelmi nyilatkozat oldalon vagyok, képesnek kell lennem arra, hogy letöltsem a nyilatkozatomat doc, excel és pdf formátumban.

ha átmegy ezen az elfogadáson, 3 dolog hiányzik itt:

• a letöltött fájlnév neve és formátuma.,
• milyen információkat (oszlopneveket) kell megjeleníteni a fájlban.
• az opciók listája annak kiválasztásához, hogy milyen tranzakciót szeretne az ügyfél, azaz csak terheléseket vagy csak krediteket vagy mindkettőt.

Az ilyen esetek időnként előfordulhatnak, de még mindig jól tanulmányozzák az egyes elfogadási kritériumokat, és megpróbálják megjeleníteni a felhasználói történetre való hivatkozással. Minél mélyebben tanulmányozod a feltételeket és az üzleti szabályokat, annál többet fogsz tudni a funkcióról.

a kezdeti szakaszban talált hibák nem kerülnek semmibe ahhoz képest,ami a “tesztelési” szakaszban kerülhet.,

A felhasználói történet/Elfogadási Kritériumok eltéréseinek megtalálásának fontossága

mindig fontos, hogy még a fejlesztés vagy a tesztelés megkezdése előtt mély merülést végezzünk a felhasználói történetekben és az elfogadási kritériumokban. Mert magában foglalja:

#1) Pazarlás Idő:

Ha az eltérést vagy hibát a felhasználó történet/elfogadási kritériumok találtam, amikor fejlesztés folyik, vagy a tesztelés folyik, akkor sok utómunka lehet, meg kell tenni a fennmaradó sprint ideje.,

nem történik meg, hogy még akkor is, ha a termék tulajdonosa néhány dolgot elmulasztott, áthelyezik a felhasználói történetet a következő sprintre. 95% esély van arra, hogy felkérik a csapatot, hogy tegye meg a szükséges végrehajtást, és engedje el ugyanabban a sprintben.

ezért rémálommá válik a csapat számára, mivel extra időt kell tölteniük, hétvégén jönnek, vagy késő este dolgoznak. Ezt el lehet kerülni a felhasználói történet/Elfogadási Kritériumok tanulmányozásával és megvitatásával a lehető legkorábbi szakaszban.

# 2) Wastage erőfeszítések:

a fejlesztők és QA kell újra a végrehajtott kód és tesztesetek újra., Frissítés, hozzátéve, eltávolítása, mint a per követelmény nem könnyű feladat. Túl fájdalmas lesz, mivel már van nyomás az időben történő szállításhoz.

ilyen helyzetben vannak hibák a fejlesztési vagy tesztelési szakaszban. Ha találkoznak ilyen helyzetben megy “DevQA párosítás”. A torta jegesedéseként előfordulhat, hogy nem kap kompenzációt az extra munkáért.

következtetés

A felhasználói történet és az Elfogadási Kritériumok mély megértése csak úgy érhető el, ha hatalmas időt töltenek annak tanulmányozására.,

nincs konkrét eszköz vagy tanfolyam elérhető a piacon, hogy ezt az Ön számára, mivel ez az egész a logikus gondolkodás, tapasztalat, tudás a termékről.

aktívan részt vesz a terv előtti találkozón, beszél a BA-val, egyedül tanulva csak segíthet ennek elérésében. Minél több erőfeszítést teszel, annál többet tanulsz és nősz.

legyen szó akár a QA-ról, akár a fejlesztőkről, mindenkinek ugyanazon az oldalon kell lennie a felhasználói történetekről, azok elfogadási kritériumairól, csak akkor lehet sikeresen elérni az ügyfél elvárásait.,

van valami új, amit megoszthat velünk a felhasználói történetekkel kapcsolatos tapasztalatairól? Kérjük, fejezze ki gondolatait az alábbiakban!!