itt a Mobindustry-nál agilis megközelítéssel dolgozunk. Ez azt jelenti, hogy olyan agilis komponenseket használunk, mint a felhasználói történetek és az Elfogadási Kritériumok. A nagy teljesítményű csapatok és szervezetek rendelkeznek ezekkel az összetevőkkel a termék-háttérvilágításban, és tudják, hogyan kell őket létrehozni és hatékonyan használni.
Ha a termék lemaradásából hiányoznak a felhasználói történetek és az elfogadási kritériumok-vagy ha nincsenek egyértelműen meghatározva -, akkor azt kockáztatja, hogy elvárásai nem konvergálnak a valósággal., A felhasználói történetek és az Elfogadási Kritériumok felelősek azért, hogy a végfelhasználó hogyan fogja használni az alkalmazást, valamint hogy a Fejlesztőcsapatnak hogyan kell végrehajtania az egyes fejlesztési feladatokat. Amikor elkezdünk dolgozni egy új terméken, csapatunk együttműködik az ügyféllel a felhasználói történetek meghatározása érdekében.
a felhasználói történet egy termékfunkció rövid, egyszerű leírása egy olyan személy szemszögéből, aki ezt a funkciót használni akarja. A felhasználói történetek a termék elmaradásának meghatározására szolgálnak egy agilis fejlesztési munkafolyamatban.,
a Termék backlog lényegében felhasználói történetek gyűjteménye, amely tájékoztat egy adott termék vagy szolgáltatás funkcionális specifikációjáról és funkcióinak fejlesztéséről. A felhasználói történetek három részből állnak: a felhasználó személyisége, amelyre a történetet írják, a felhasználó által igényelt szolgáltatás leírása,valamint a szolgáltatás igényének magyarázata.
itt van, hogyan kell írni egy felhasználói történetet:
mint (felhasználó) szeretnék egy (funkciót), hogy képes legyek (kielégíteni egy igényt).
vessünk egy pillantást arra, hogyan nézhet ki egy felhasználói történet., Példaként az Airbnb-t vesszük. Képzeljük el, hogy egy tipikus felhasználói történet hogyan kereshet olyan terméket, mint az Airbnb.
“mint felhasználó, szeretnék keresni egy rendeltetési helyet, így foglalhatok szállást egy idegen városban.”
az elfogadási kritériumok meghatározása
most meg kell győződnünk arról, hogy a felhasználói történetek helyesen készültek, és megfelelnek az ügyfél igényeinek.
az Elfogadási Kritériumok azok a feltételek, amelyeket egy szoftverterméknek meg kell felelnie ahhoz, hogy a felhasználó, az ügyfél, vagy rendszerszintű funkcionalitás esetén a fogyasztó rendszer elfogadja.,
az Elfogadási Kritériumok olyan kijelentések halmaza, amelyek mindegyike egyértelmű pass/fail eredménnyel rendelkezik, amely mérhető és meghatározható mind a funkcionális, mind a nem funkcionális követelmények tekintetében.
az Elfogadási Kritériumok írása nemcsak annak megállapításához fontos, hogy az ügyfél mit vár el a terméktől, hanem a fejlesztési folyamathoz is. Természetesen a különböző emberek ugyanazt a problémát látják különböző szögekből. A jól meghatározott Elfogadási Kritériumok egységes képet adnak a megvalósítandó funkciókról.,
bárki számára lehetővé kell tenni, hogy gyalog akár egy Scrum fórumon, megragad egy termék lemaradás elem, olvassa el az elfogadási kritériumok, és világosan látni mindent, amit be kell fejezni, hogy az adott elem kell mozgatni a kész oszlop. Az Elfogadási Kritériumok megmondják, mit kell tenni a termék egy adott részének befejezéséhez.
mobil-és webalkalmazás fejlesztés
tervezi online üzleti tevékenységének bővítését? Ötleteit intelligens és hatékony megoldásokká alakítjuk át.
miért van szükségünk elfogadási kritériumokra?,
- határok meghatározása. Az elfogadási kritériumok segítenek a fejlesztő csapatnak meghatározni a felhasználói történet határait. Ezek egyfajta megerősítésként szolgálnak arra, hogy az alkalmazás a várt módon működik, ami azt jelenti, hogy a felhasználói történet befejeződött.
- konszenzus elérése. Az elfogadási kritériumok lehetővé teszik a fejlesztő csapat számára, hogy ugyanazon az oldalon legyen, mint az ügyfél. Tájékoztatják a Fejlesztőcsapatot arról, hogy pontosan milyen feltételeknek kell megfelelni, és biztosítják, hogy az ügyfél tudja, mire számíthat az alkalmazástól.
- az elfogadás tesztelésének egyszerűsítése., Az elfogadási kritériumok a felhasználói történet elfogadási tesztelésének alapját képezik. Minden elfogadási kritériumot önállóan kell tesztelni, és világos forgatókönyvekkel kell rendelkeznie a sikerre vagy a kudarcra vonatkozóan.
- tervezés és becslés. Az elfogadási kritériumok lehetővé teszik a felhasználói történetek feladatokon keresztüli terjesztését, így azok megfelelően kiértékelhetők és ütemezhetők.
- negatív forgatókönyvek leírása. Az Elfogadási Kritériumok megkövetelhetik a rendszertől, hogy azonosítson egy gyenge jelszót, és például megakadályozza a felhasználó folytatását., A helytelen jelszóformátum megadása egy olyan negatív forgatókönyv példája, amelyben a felhasználó helytelen adatokat ad meg, vagy váratlanul viselkedik. Az Elfogadási Kritériumok meghatározzák ezeket a forgatókönyveket, és elmagyarázzák, hogyan kell a rendszernek reagálnia rájuk.
nem funkcionális és funkcionális követelményeket szeretne írni a szoftverprojektjéhez? Ebben a cikkben a funkcionális és nem funkcionális követelmények
ki írja az elfogadási kritériumokat?,
az Elfogadási Kritériumok írása segít abban, hogy a termék tulajdonosa és a fejlesztő csapat közös megértést alakítson ki az ügyfél problémájának megoldása vagy a termék képességeinek megteremtése tekintetében. Mivel az elfogadási kritériumok az ügyfélre és a csapatra vonatkoznak, azokat az ügyfélnek vagy a csapattagnak kell megírnia.
a Mobindustry – nál üzleti elemzőink írják a felhasználói történetek elfogadási kritériumait. Az üzleti elemzők megértik az ügyfél igényeit, valamint azt, amit a fejlesztőknek tudniuk kell, hogy megfeleljenek a projekt követelményeinek.,
az elfogadási kritériumokat a projekt megkezdése előtt dokumentálják és megerősítik, mivel a csapatnak és az ügyfélnek meg kell állapodnia arról, hogy milyen eredmények felelnek meg az ügyfél igényeinek.
mobil-és webalkalmazás fejlesztés
tervezi online üzleti tevékenységének bővítését? Ötleteit intelligens és hatékony megoldásokká alakítjuk át.
felhasználói történetek példái elfogadási kritériumokkal
most, hogy világos megértése van arról, hogy milyen felhasználói történetek és elfogadási kritériumok vannak, vessünk egy pillantást néhány példára.,
1. példa
felhasználói történet: felhasználóként szeretnék regisztrálni a szolgáltatásba, hogy online vásárolhassak.
Elfogadási Kritériumok:
- a felhasználók csak az összes szükséges mező kitöltésével küldhetnek be űrlapot.
- az e-mailt, amelyet a felhasználó nyújt, nem szabad ingyenes e-mail szolgáltatással biztosítani.
- az azonos IP-ből származó beadványok csak háromszor készíthetők 30 percen belül.
- a felhasználók értesítési e-maileket kapnak a sikeres regisztráció után.,
2. példa
felhasználói történet: felhasználóként azonnal hozzáférhetek egy értesítéshez a készüléken, miután megkaptam.
Elfogadási Kritériumok:
- az értesítés elcsúsztatása/megérintése közvetlenül az üzenethez viszi a felhasználót.
- nézet beszélgetés megjelenítése-ha az új üzenet válasz volt, akkor az az eredeti felett jelenik meg.
- az Üzenetszám frissül.
- egy üzenet a megjelenítés után olvasható.
7 tipp a jó Elfogadási Kritériumok írásához
az elfogadási kritériumokat nem könnyű írni., Az egyszerű formátum ellenére a szöveg írása kihívás. Íme hét tipp, amelyek segítenek elkerülni a gyakori hibákat az Elfogadási Kritériumok írása közben, vagy a csapat tagja által írt kritériumok áttekintésében.
- dokumentumkritériumok a fejlesztési folyamat megkezdése előtt. Ily módon a csapat nagyobb valószínűséggel fogja előre az ügyfél összes igényét. Kezdetben elegendő kritériumokat meghatározni egy kis számú felhasználói történethez, hogy két sprintre teljes holtjáték legyen. A dokumentált elfogadási kritériumokat a fejlesztők a műszaki folyamat megtervezéséhez használják.,
- ne tegye túl szűkre az elfogadási kritériumokat. Az elfogadási kritériumok, amelyek túl specifikusak, kevés mozgásteret hagynak a fejlesztőknek. Ennek elkerülése érdekében ne feledje, hogy az Elfogadási Kritériumoknak szándéknyilatkozatnak kell lenniük, nem pedig végső döntésnek. Ezenkívül a szűk elfogadási kritériumok nem veszik figyelembe az összes felhasználói műveletet.
- tartsa a kritériumokat elérhető. A hatékony Elfogadási Kritériumok ésszerű minimális mennyiségű funkciót határoznak meg, amelyet megadhat. De ha továbbra is leírja az összes apró részletet, fennáll annak a veszélye,hogy csapata több száz kis feladatra ragadhat.,
- kerülje az Elfogadási Kritériumok túl széles körét. A széles körű Elfogadási Kritériumok homályossá teszik a felhasználói történetet. A hatékony Elfogadási Kritériumoknak körvonalazniuk kell a munka körét, hogy a fejlesztők megfelelően megtervezhessék és becsülhessék erőfeszítéseiket.
- kerülje a műszaki részleteket. Az elfogadási kritériumokat egyszerű nyelven kell írni. Lehet, hogy az érdekelt felek és a vezetők nem rendelkeznek technikai háttérrel, így az egyszerű nyelv használata mindenki számára érthetővé teszi a kritériumokat.
- konszenzus elérése., Ugyanezt a problémát a csapat tagjai és az érdekelt felek álláspontjuktól függően különböző módon oldhatják meg. Győződjön meg róla, hogy közli az elfogadási kritériumokat az érdekelt felekkel és a csapat tagjaival, és kölcsönös megállapodásra jut.
- tesztelhető Elfogadási Kritériumok írása. Ez lehetőséget ad a tesztelőknek annak biztosítására, hogy minden követelmény teljesüljön, és lehetővé teszi a fejlesztők számára, hogy megtudják, befejeződött-e a felhasználói történet.,
Ismerje meg, hogyan lehet megtudni, hogy az outsourcing vállalkozó megbízható-e
hogyan írhat elfogadási kritériumokat
íme öt általános szabály, amelyek segítenek megoldani az Elfogadási Kritériumok megfogalmazásával kapcsolatos problémákat. Ezek a szabályok lehetővé teszik, hogy értékes időt takarítson meg, és megértést alakítson ki a termék tulajdonosa és a fejlesztő csapat között.
1. szabály: kerülje a”nem”
” nem “azt jelenti, hogy” semmi esetre sem”, ezért nem lesz elegendő idő az ilyen feltétel betartásának ellenőrzésére., Ha átírja a követelményt a ” nem ” használata nélkül, akkor világosabb lesz, ami a legfontosabb, ellenőrizhető.
példa:
felhasználói történet
ne: felhasználóként nem akarom, hogy minden alkalommal meg kell adnom a jelszavamat, amikor hozzáférek a fiókomhoz.
Do: mint felhasználó, azt akarom, hogy a jelszavam emlékezzenek meg, majd automatikusan kitöltsék, hogy hozzáférhessek a fiókomhoz anélkül, hogy újra beírnám a jelszavamat.
Elfogadási Kritériumok
ne: a rendszer nem hibázhat.
Do: a rendszernek legalább 90% – os rendelkezésre állással kell rendelkeznie.,
kivétel
a logikai kifogás bevezetéséhez az elfogadási kritériumokban a “nem” kifejezést használhatja, például: “a bejelentkezési űrlap nem lehet piros.”A legtöbb esetben ez a nem funkcionális követelményekre vonatkozik. Ebben a példában olyan korlátozást fogalmazunk meg, amely könnyen ellenőrizhető, ha a vörös árnyalatok tartománya egyértelműen meg van határozva (például RGB formátumban megadva).,
Ismerje meg, hogyan optimalizáltuk az ügyfélélményt egy mobilalkalmazással
szabály #2: aktív hang használata
aktív hang, amikor a mondatban szereplő alany a cselekvés előadója. Ha a művelet végrehajtásáért felelős szervezet nincs egyértelműen feltüntetve, nem lesz világos, hogy ki vagy mit kell végrehajtania a műveletet, és nehezebb lesz ellenőrizni, hogy teljesül-e egy követelmény.,
példa:
felhasználói történet
NE: online vásárlóként szűrőket kell alkalmazni, hogy megtaláljam, amit akarok.
Do: mint felhasználó, keresési szűrőket akarok alkalmazni, hogy megtalálhassam az elemeket.
Elfogadási Kritériumok
ne: az ügyfél személyazonosságát meg kell erősíteni. (Nem világos, hogy ki vagy mi felelős az ügyfél személyazonosságának megerősítéséért.)
Do: a Accounting_System-nek meg kell erősítenie a Customer_Indentity-t. (Vegye figyelembe, hogy a fogalommeghatározások a “Accounting_System” és “Customer_Indentity” hozzá kell adni a szószedet.,)
mobil-és webalkalmazás fejlesztés
tervezi online üzleti tevékenységének bővítését? Ötleteit intelligens és hatékony megoldásokká alakítjuk át.
3.szabály: kerülje a névmások használatát (különösen a meghatározatlanokat)
névmások helyett főneveket használjon, ha más követelményekben hivatkozott tételekre hivatkozik. A névmásokat kerülni kell, mert kétértelműséget okozhatnak.,
Ez különösen akkor fontos, ha az elfogadási kritériumokat a követelménykezelő eszközökben (például a Jira-ban) tárolják különálló kijelentésekként, amelyek nem feltétlenül szervezettek. A névmások helyett mindig főneveket használjon, így elkerülheti ezt a problémát.
példa:
felhasználói történet
ne: webhelytagként szeretnék megosztani magamról szóló információkat, hogy mások láthassák.
Do: mint webhelytag, szeretnék hozzáadni egy profilleírást, hogy mások megismerhessenek rólam.
Elfogadási Kritériumok
ne: a vezérlőnek el kell küldenie a járművezetőnek a napi útvonalat., A műszak előtt legalább 8 órával kell szállítani.
Do: a vezérlőnek a Driver_Itinerary-t naponta legalább 8 órával a Driver_Shift előtt kell elküldenie a vezetőnek.
távoli csapatok kezelése, legjobb gyakorlatok. A Mobindustry IT outsourcing vállalatként osztja meg tapasztalatait
szabály #4: Kerülje el a konjunkciókat
a Konjunkciók olyan szavak és kifejezések, mint például “és” vagy””, “de” És”, valamint”, amelyek az egyszerű mondatokat összetett mondatokká egyesítik., A követelményekben való felhasználásuk általában azt jelzi, hogy egy követelmény több különálló követelményre bontható.
példa:
felhasználói történet
ne: UI tervezőként szeretnék létrehozni és megtekinteni egy problémát, hogy tudjam, mit kell tesztelni.
Do: UI tervezőként szeretnék létrehozni egy problémát, hogy tudom, mit kell tesztelni. / Mint UI tervező, szeretnék megtekinteni egy kérdést, hogy tudom, mit kell tesztelni.
Elfogadási Kritériumok
ne: a felhasználónak megbízhatónak vagy megbízhatónak kell lennie.
Do: a Security_System minden Felhasználót megbízható vagy Not_Trusted kategóriába sorol.,
Exception
“és,” “vagy”, “és” nem ” használható logikai feltételek leírására és selejtezők hozzáadására.
mobil-és webalkalmazás fejlesztés
tervezi online üzleti tevékenységének bővítését? Ötleteit intelligens és hatékony megoldásokká alakítjuk át.
5. szabály: Kerülje el az elérhetetlen abszolutumokat
az abszolút (például 100% – os rendelkezésre állás) elérhetetlen. Gondolj arra, hogyan ellenőrizheted a mutatót: lehet-e bizonyítani, hogy a rendszer rendelkezésre állásának szintje pontosan 100%?, És még ha létre is lehetne hozni egy ilyen rendszert, megengedheti magának?
kerülje a “minden”, “mindig” és “soha” szavakat, mivel az ilyen abszolút követelmények ellenőrzése végtelen számú tesztet igényel.
példa:
felhasználói történet
ne: utazóként szeretném tudni, hogy pontos helyem valós időben frissül, hogy ne vesszek el. (A “valós idő” különböző módon értelmezhető. Például abszolút értéknek tekinthető (késedelem hiánya), amelyet nem lehet elérni, és amely nem ellenőrizhető.,)
Do: utazóként szeretném tudni a pontos helyemet, minden másodpercben frissítve, hogy ne veszítsek el.
Elfogadási Kritériumok
ne: a rendszernek 100% – os rendelkezésre állással kell rendelkeznie. (A 100% olyan abszolút, amelyet nem lehet elérni, és nem lehet ellenőrizni.)
Do: a rendszernek legalább 98% – os rendelkezésre állással kell rendelkeznie.
az Elfogadási Kritériumok gyors összefoglalása
reméljük, hogy ez a cikk rávilágított az elfogadási kritériumok és a felhasználói történetek világára., Itt vannak a legfontosabb elvitelek:
- az Elfogadási Kritériumok azok a feltételek, amelyeket a szoftverterméknek meg kell felelnie ahhoz, hogy a felhasználó, az ügyfél, vagy rendszerszintű funkcionalitás esetén a fogyasztó rendszer elfogadja.
- az elfogadási kritériumokat a projekt megkezdése előtt dokumentálni kell és be kell fejezni, mivel a csapatnak és az ügyfélnek meg kell állapodnia arról, hogy milyen eredmények felelnek meg az ügyfél igényeinek.
- ne feledje, hogy az Elfogadási Kritériumoknak szándéknyilatkozatnak kell lenniük, nem pedig végső döntésnek.
- a hatékony Elfogadási Kritériumok ésszerű minimális funkcionalitást határoznak meg.,
- A jó Elfogadási Kritériumoknak körvonalazniuk kell a munka hatókörét, hogy a fejlesztők megfelelően megtervezhessék és megbecsülhessék erőfeszítéseiket.
- az elfogadási kritériumokat egyszerű nyelven kell írni.
- győződjön meg róla, hogy az elfogadási kritériumokat közli az érdekelt felekkel és a csapat tagjaival, és kölcsönös megállapodásra jut.
- az Elfogadási Kritériumok írása közben kerülje a “nem”, a konjunktúrák és az elérhetetlen abszolútumok használatát. Fogalmazza meg a mondatokat aktív hanggal.,
ha elfogadási kritériumokat és felhasználói történeteket szeretne létrehozni a mobilalkalmazásához, vagy ha bármilyen kérdése van ezzel a témával kapcsolatban, forduljon a Mobindustry-hoz egy ingyenes konzultációhoz.
mobil-és webalkalmazás fejlesztés
tervezi online üzleti tevékenységének bővítését? Ötleteit intelligens és hatékony megoldásokká alakítjuk át.