Kako pisati uporabniške zgodbe (s primeri in sprejemnimi merili)

Uporabniška zgodba je kratek opis funkcije z vidika uporabnika: »Kot [vrsta uporabnika] želim [cilj], da [razlog].« Pod njo napišete sprejemna merila, nekaj specifičnih pogojev, ki morajo biti izpolnjeni, da se zgodba šteje za končano. Vsaka zgodba naj bo dovolj majhna, da jo zgradite in preizkusite naenkrat, merila pa napišite tako, da jih lahko kdorkoli preveri.

Uporabniške zgodbe so postale priljubljene v agilnih razvojnih ekipah, a so enako uporabne, ko gradite sami z orodjem za izdelavo aplikacij z AI. Dobra zgodba je dober poziv.

Oblika

Uporabniška zgodba ima tri dele:

Kot [kdo], želim [kaj] da [zakaj].

• Kdo je določena vrsta uporabnika: prvi obiskovalec, plačljivi član, recepcionistka v kliniki, administrator. Ne »uporabnik« na splošno.
• Kaj je stvar, ki jo želi narediti, z njegovimi besedami. Ne kako deluje zaslon.
• Zakaj je rezultat, ki mu je mar. To je del, ki ga ljudje preskočijo, in ta, ki vas obvaruje pred gradnjo napačne stvari.

Primer:

Kot član telovadnice želim odpovedati rezervacijo vadbe s telefona, da nekdo s čakalnega seznama lahko prevzame moje mesto in mi ni zaračunana kazen za neudeležbo.

Razlog vam pove dve stvari, ki vam »kaj« ni: mora delovati na telefonu, in vključena sta čakalni seznam in pravila o kazni.

Sprejemna merila

Zgodba pove, kaj je zaželeno. Sprejemna merila povedo, kdaj je končano. Biti morajo dovolj specifična, da bi se dve osebi strinjali, ali je vsako izpolnjeno.

Pogost način zapisa je Dano / Ko / Potem:

• Dano je neko začetno stanje
• Ko uporabnik nekaj stori
• Potem sledi ta rezultat

Za zgodbo o rezervaciji v telovadnici:

1. Dano imam rezervacijo več kot 12 ur vnaprej, ko tapnem Prekliči in potrdim, potem je rezervacija odstranjena in vidim »Rezervacija preklicana«.
2. Dano preklicem rezervacijo in ima vadba čakalni seznam, ko se preklic shrani, potem prva oseba na čakalnem seznamu dobi mesto in e-pošto.
3. Dano je rezervacija manj kot 12 ur vnaprej, ko tapnem Prekliči, potem vidim, da velja kazen za pozno odpoved, preden potrdim.
4. Dano sem na zaslonu široko kot telefon, potem je gumb Prekliči viden brez vodoravnega pomikanja.

Preprost seznam je prav tako dober, dokler je vsaka točka preverljiva. »Odpovedovanje je enostavno« ni preverljivo. »Odpoved zahteva največ dva tapa s seznama rezervacij« pa je.

Korak za korakom: pisanje dobre zgodbe

Korak 1: Začnite z resničnim uporabnikom in resničnim problemom

Izberite eno vrsto uporabnika in nekaj, kar ima danes težave. Če ste opravili razgovore s strankami, uporabite njihove besede. »Vedno pozabim odpovedati in mi zaračunajo« je boljše izhodišče kot »dodaj funkcijo odpovedi«.

Korak 2: Napišite enovrstično zgodbo

Izpolnite predlogo. Če ne morete napisati prepričljivega »da«, vprašajte, ali je funkcija sploh potrebna.

Korak 3: Dodajte tri do šest sprejemnih meril

Najprej pokrijte glavni uspešni primer, nato pomembne različice: drugo vlogo, prazno stanje, omejitev, napako. Če jih pišete več kot šest, je zgodba verjetno prevelika.

Korak 4: Zapišite, kaj je izven obsega

Ena vrstica prihrani veliko časa za nazaj in naprej: »Izven obsega: vračila za plačane vadbe; administratorji, ki odpovejo v imenu članov.« Tako zgodba med gradnjo ne raste.

Korak 5: Preverite po INVEST

INVEST je pogost kontrolni seznam za dobre zgodbe. Zgodba naj bo:

Ni treba oceniti vsake zgodbe. Najkoristnejše je, ko se zgodba zdi napačna in želite vedeti zakaj.

Dobri in slabi primeri

Kako razdeliti zgodbo, ki je prevelika

Velike zgodbe so mesto, kjer projekti obtičijo. Pogosti načini delitve:

• Po vlogi uporabnika. Člani odpovedujejo lastne rezervacije; osebje odpove katero koli.
• Po koraku v toku. Brskanje po vadbah; rezervacija vadbe; opomnik.
• Najprej preprost primer. Odpovej brezplačno vadbo zdaj; plačila in vračila obravnavajte v kasnejši zgodbi.
• Po različici podatkov. Najprej podprite eno lokacijo, pozneje več.
• Najprej srečni primer, nato napake. Najprej zgradite, da deluje, nato dodajte obravnavo polnih vadb, poteklih vstopnic in podobnega.

Vsak kos mora še vedno biti nekaj, kar bi uporabnik lahko uporabil in opazil.

Uporaba uporabniških zgodb kot pozivov

Uporabniška zgodba s sprejemnimi merili je zelo blizu dobremu pozivu za orodje za izdelavo aplikacij. AI dobi kdo, kaj, zakaj in definicijo dokončanosti. Pošljite eno zgodbo na sporočilo:

Kot član telovadnice želim odpovedati rezervacijo vadbe s telefona, da lahko nekdo s čakalnega seznama prevzame moje mesto. Sprejemna merila:

1. Odpoved je pri vsaki rezervaciji v Moje rezervacije, s korakom potrditve.
2. Odpoved več kot 12 ur pred vadbo le odstrani rezervacijo.
3. Manj kot 12 ur pred tem pokaži »Velja kazen za pozno odpoved 5 USD« pred potrditvijo in zabeleži kazen na rezervaciji.
4. Če ima vadba čakalni seznam, prva oseba dobi mesto in e-pošto.
5. Deluje na zaslonu široko kot telefon. Izven obsega: vračila, odpoved v imenu članov s strani osebja. Zgradi to, nato v predogledu preveri vsako merilo in mi povej, katera so izpolnjena.

Lahko pa AI prosite, naj iz grobe ideje pripravi zgodbe, nato pa jih uredite sami:

Tu je moja ideja aplikacije: [dva ali trije stavki]. Napiši uporabniške zgodbe za prvo različico, razvrščene po vrsti uporabnika, vsaka s 3 do 5 sprejemnimi merili v obliki Dano / Ko / Potem. Označi, katere so nujne za izdajo in katere lahko počakajo.

Rezultat vedno preberite in uredite. AI ne pozna vaših uporabnikov; vi jih poznate.

Sprejemna merila so hkrati vaš testni načrt. Ko je zgodba zgrajena, preverite vsako merilo sami. Naš vodnik o testiranju aplikacije pred izdajo temelji na tem.

Kje se uporabniške zgodbe prilegajo drugim dokumentom

• Dokument o zahtevah izdelka opisuje celoten izdelek: problem, uporabnike, obseg. Uporabniške zgodbe so podrobni kosi znotraj njega. Glejte kako napisati PRD z AI.
• Poročilo o napaki opisuje nekaj, kar je pokvarjeno glede na zgodbo, ki je bila že zgrajena. Glejte kako napisati dobro poročilo o napaki.
• MVP je najmanjši nabor zgodb, ki zagotovi osrednjo vrednost. Glejte kaj je MVP.

Pogoste napake

• »Kot uporabnik …« Preveč nejasno. Poimenujte dejansko vrsto uporabnika.
• Izpuščen »da«. Brez razloga ne morete sprejemati smiselnih kompromisov.
• Pisanje rešitve namesto potrebe. »Želim spustni seznam« zaklene zasnovo, preden je kdo sploh premislil.
• Merila, ki jih ni mogoče preveriti. »Enostavno«, »hitro« in »intuitivno« so želje, ne merila.
• Zgodbe, ki so v resnici epi. »Upravljanje računa« je deset zgodb.
• Pisanje vseh zgodb vnaprej. Podrobno napišite naslednjih nekaj; ostale ohranite kot enovrstične zapise, dokler do njih ne pridete.

Zgodbe v Mythexu

V Mythexu je način Plan dobro mesto, kjer idejo spremenite v zgodbe: agent pred urejanjem česarkoli pregleda pristop. Ko je zgodba pripravljena, preklopite na Build in jo prilepite, eno zgodbo na sporočilo. Po vsaki lahko /test klikne skozi predogled in preveri tok, vsak odgovor pa lahko z Vrni na to točko razveljavite, če je šel v napačno smer. Glejte učinkovite pozive v dokumentaciji in naš vodnik o pisanju pozivov za orodja za izdelavo aplikacij.

Kontrolni seznam uporabniške zgodbe

• Poimenuje določeno vrsto uporabnika
• Opisuje potrebo, ne zasnove
• Vključuje pravi razlog »da«
• Ima tri do šest preverljivih sprejemnih meril
• Pokriva vsaj en robni primer ali napako
• Navaja, kaj je izven obsega
• Dovolj majhna, da jo zgradite in preizkusite v enem zamahu
• Merila preverjena po gradnji, eno za drugim

Vprašanja