hogyan írunk hatékony felhasználói történeteket?
vannak 5 irányadó elvek, hogy azt javaslom, következő:
- mindenkinek boldognak kell lennie
szerzés mindenki a fedélzeten fontos, így kap mindenki, aki majd ír, és használja a felhasználói történeteket, hogy adja meg ötleteiket, és egyetértenek abban, hogy a formátum akkor minden használni. - legyen következetes
miután megkapta a megállapodás szerinti struktúrát, győződjön meg róla, hogy ragaszkodik hozzá. - összpontosítson arra, ami fontos
amikor kiírja őket, kerülje el a lényegtelen részleteket., Szánjon időt arra, hogy tömör legyen, távolítsa el a gofrit, mivel csak útban van. - nincs implementációs részlet
mindig a “miért” nem a “Hogyan” – ra összpontosít. Miért akar egy felhasználó valamit, nem pedig hogyan fogjuk felépíteni. Ha technikai részleteket kell megadnia, ezeket külön spec fájlként kell csatolni. - tiszta, megvalósítható & tesztelhető
Győződjön meg róla, hogy mindenki megérti az egyes történeteket, és hogy ez elérhető az időkeretben, amellyel elégedett. Ha 2 hetes sprinteket szállít, akkor ez nem tarthat tovább, mint az a 2 hét.,
felhasználói történet anatómia
a felhasználói történetnek 3 kötelező része van, a cím, a leírás és az Elfogadási Kritériumok. A csapata egyetérthet abban, hogy a felhasználói történetnek más mezőkkel kell rendelkeznie, mielőtt a munka megkezdődhet rajta. Például lehet, hogy szükség van egy megbízottra, történetpontokra vagy az üzleti hatásra, de ezeket opcionálisnak tartom, mivel nem minden szervezet igényli ezeket.
Title
a címeknek rövidnek, egyedinek és nem félrevezetőnek kell lenniük.,
- “Add lépjen velünk kapcsolatba, panel kezdőlap”
- “Add betéti kártya támogatja, hogy bevásárlókosár”
- a”Frissítés e-mail sablon, címkézés”
Néhány kevésbé jó (sajnos valós világ) példák:
- “, Hogy elfogadott változások”
- “32072 — Frissítve Feltérképezése – Upsell Felhasználói történet (27263)”
- “Linkek — követés query string-bill ravasz, okos hozzászólás telepíteni …”
Leírás
A leírás a kezében van a valódi hatalom a felhasználó történet. Empátiát kell teremtenie a csapatban a felhasználó számára, valamint meg kell értenie a megoldandó problémát.,
a leírás nagyon népszerű struktúrája a “As A … I want … so I can …”.
Ez a struktúra megkérdezi a “mint ki”kérdést? Ki a felhasználó szembesül a problémával? Itt hivatkozhat egy személyre, ha használja őket, alternatív megoldásként megadhat egy nevet a felhasználónak, és hozzáadhat néhány kontextust a felhasználó helyzetéhez. Próbálja meg elkerülni a “mint ügyfél” vagy “mint felhasználó” használatát, mivel ez kevésbé hatékony az empátia megteremtésében egy tényleges felhasználó számára.
a leírást egyszerű, világos nyelven kell írni, technikai kifejezések vagy rövidítések nélkül., Meg kell kérdezned magadtól: “meg tudja-e érteni a Nan?”Egy új csapattagnak képesnek kell lennie arra, hogy elolvassa a leírást, és pontosan megértse, mi a probléma, amit meg kell oldani.
a következő valós példákat vesszük egy projektből, hogy funkcionalitást adjunk egy online számlarendszerhez egy brit energiavállalat ügyfelei számára.,
- “, Mint John, egy ügyfél egy hagyományos villamosenergia-mérő, azt akarom, hogy megértsd, miért nem látom a diagramok az energia használat részletesebben, hónapról-hónapra, így nem lehet eldönteni, hogy meg akarok változni, ez egy okos mérő telepítve.”
- ” mint Bart, egy proaktív hagyományos mérő ügyfél, aki meg akarja győződni arról, hogy a következő számlám pontos-e, szeretném tudni, hogy ma már benyújtották-e a mérőolvasást, és hogy nem kell benyújtanom egy másikat.,”
néhány kevésbé jó példa:
- “felhasználóként meg akarom akadályozni, hogy a tradicionális ügyfelek képesek legyenek a legmagasabb szint alá fúrni, hogy vásárlói tapasztalataikat”
- ” kezeljék, mint olyan ügyfelet, aki vagy ma olvasta a mérőt, vagy ma olvasta az üzemanyagot, nem szabad megengedni, hogy ma újabb mérőt nyújtson be, mivel az SAP nem fogadhat el több mint egy méter olvasást üzemanyagonként naponta.”
a kevésbé jó példákat valóban átírták, hogy a fenti jó példák legyenek, mivel a felvázolt problémák nem voltak egyértelműek., Ezt a finomítási folyamatot bármikor meg kell tenni a felhasználói történet bármely része nem világos. Csak győződjön meg róla, hogy a csapat minden tagja tisztában van a változásokkal.
Elfogadási Kritériumok
Elfogadási Kritériumok a felhasználói történet teljességének igazolására szolgálnak. Ez segít a fejlesztőknek és tesztelőknek.
az Elfogadási Kritériumok írása hatékony módja annak, hogy bármilyen munka megkezdése előtt átmegy a történet minden részletén. Számos lehetséges buktatót vagy váratlan munkát korán “felfedezhetünk” jó Elfogadási Kritériumok írásával.,
az elfogadási kritériumok nagyon népszerű struktúrája “adott… amikor… akkor…”, amint az az alábbi példákban látható.
ha EGY felhasználói történetnek több mint 10 elfogadási kritériuma van, ez azt jelezheti, hogy a történet túl sok dolgot csinál. Ebben az esetben azt javaslom, hogy fontolja meg a történet felosztását.
az egész csapatot be kell vonni az Elfogadási Kritériumok írásába. Ha ez nem lehetséges, Azt ajánlom, hogy mindenki olvassa el, majd beleegyezik, hogy őket, mielőtt dolgozik rajtuk. Ez különösen igaz mindenkire, aki részt vesz a munka tesztelésében.,
az Elfogadási Kritériumok számozása megkönnyíti a hivatkozást.
néhány jó példa:
- adott egy ügyfél egy hagyományos mérő az energiafelhasználás bar chart
Ha rákattint a szerszám-tip egy hónapra
akkor egy felugró jelenik meg megfelelő a megadott design. - Adott egy kettős üzemanyag ügyfél megtekintése az energiafelhasználás oszlopdiagram
Mikor hónap becsült értékek
Akkor a diagram legenda egyértelműen ki kell derülnie annak becsült villamos energia ikon a fény piros sáv
Akkor a diagram legenda egyértelműen ki kell derülnie annak becsült gáz ikon egy világoskék sáv.,
ha nincs szükségünk felhasználói történetekre
technikai feladatok
néha úgy tűnik, hogy egy műszaki feladat nem kapcsolódik az ügyfélhez. Ha ez a helyzet, ne használjon felhasználói történetet. De mindig érdemes megfontolni, hogy miért csinálsz technikai feladatot; frissítesz egy könyvtárat a felhasználók sebességének javítása érdekében? Ha igen, akkor ennek felhasználói történetnek kell lennie.
Bugs
Ha a tesztelés során egy felhasználói történet jelenleg dolgozik, akkor azt kell társítani, hogy a felhasználói történet.,
Ha egy bogarat talált valamit, ami nem az aktuális felhasználó történet, akkor nem kell társított felhasználói történet, de hozzátette, hogy a lemaradás, mint független feladat.
folyamatos fejlesztés
A felhasználói történetek fejlődni fognak, mivel többet megtudnak az elvégzendő munkáról. Ez jó, továbbra is javítsa őket egészen addig a pontig, amikor kiadja a munkát a felhasználóknak., Csak győződjön meg róla, mindenki a csapat tisztában van azzal, hogy bármilyen változás történik.
finomítsa tovább a folyamatot. Légy agilis, gondolkodj el azon, hogy a felhasználói történetek hogyan működnek a csapatod számára, beszéld meg őket retróban, és javítsd tovább az írási módot.
Vélemény, hozzászólás?