Ako písať používateľské príbehy (s príkladmi a kritériami prijatia)

Používateľský príbeh je krátky opis funkcie z pohľadu používateľa: „Ako [typ používateľa] chcem [cieľ], aby [dôvod].“ Pod ním napíšete kritériá prijatia, niekoľko konkrétnych podmienok, ktoré musia platiť, aby sa príbeh považoval za hotový. Každý príbeh udržujte dostatočne malý na to, aby sa dal postaviť a otestovať naraz, a kritériá píšte tak, aby ich mohol skontrolovať ktokoľvek.

Používateľské príbehy sa rozšírili vďaka agilným softvérovým tímom, ale sú rovnako užitočné, keď stavate sami s AI nástrojom na tvorbu aplikácií. Dobrý príbeh je dobrá výzva.

Formát

Používateľský príbeh má tri časti:

Ako [kto], chcem [čo], aby [prečo].

• Kto je konkrétny typ používateľa: návštevník, ktorý je tu prvýkrát, platiaci člen, recepčná v klinike, administrátor. Nie „používateľ“.
• Čo je to, čo chce urobiť, vlastnými slovami. Nie ako funguje obrazovka.
• Prečo je výsledok, na ktorom mu záleží. Je to časť, ktorú ľudia preskakujú, a práve tá vás zabráni stavať nesprávnu vec.

Príklad:

Ako člen posilňovne, chcem zrušiť rezerváciu hodiny z telefónu, aby niekto z čakacej listiny mohol zaujať moje miesto a nebol mi účtovaný poplatok za neúčasť.

Dôvod vám prezradí dve veci, ktoré vám „čo“ neprezradilo: musí to fungovať na telefóne a zapájajú sa pravidlá čakacej listiny a poplatku.

Kritériá prijatia

Príbeh hovorí, čo sa chce. Kritériá prijatia hovoria, kedy je hotovo. Mali by byť dostatočne konkrétne, aby sa dvaja ľudia zhodli, či každé z nich prejde.

Bežný spôsob zápisu je Keď / Ak / Potom:

• Keď východiskový stav
• Ak používateľ niečo urobí
• Potom tento výsledok

Pre príbeh o rezervácii v posilňovni:

1. Keď mám rezerváciu viac ako 12 hodín vopred, ak klepnem na Zrušiť a potvrdím, potom sa rezervácia odstráni a uvidím „Rezervácia zrušená“.
2. Keď zruším rezerváciu a hodina má čakaciu listinu, ak sa zrušenie uloží, potom prvý človek z čakacej listiny dostane miesto a e-mail.
3. Keď rezervácia je menej ako 12 hodín vopred, ak klepnem na Zrušiť, potom pred potvrdením uvidím, že sa uplatní poplatok za neskoré zrušenie.
4. Keď som na obrazovke so šírkou telefónu, potom je tlačidlo Zrušiť viditeľné bez posúvania do strán.

Obyčajný zoznam funguje tiež, pokiaľ je každá položka overiteľná. „Rušiť je jednoduché“ nie je overiteľné. „Zrušenie trvá najviac dve klepnutia zo zoznamu rezervácií“ overiteľné je.

Krok za krokom: ako napísať dobrý príbeh

Krok 1: Začnite od skutočného používateľa a skutočného problému

Vyberte jeden typ používateľa a niečo, s čím dnes bojuje. Ak ste robili rozhovory so zákazníkmi, použite ich slová. „Vždy zabudnem zrušiť a zaplatím“ je lepší východiskový bod než „pridať funkciu zrušenia“.

Krok 2: Napíšte jednoriadkový príbeh

Vyplňte šablónu. Ak neviete napísať presvedčivé „aby“, opýtajte sa, či funkcia vôbec treba.

Krok 3: Pridajte tri až šesť kritérií prijatia

Najprv pokryte hlavný úspešný prípad, potom dôležité variácie: iná rola, prázdny stav, limit, chyba. Ak píšete viac ako šesť, príbeh je pravdepodobne príliš veľký.

Krok 4: Poznačte, čo je mimo rozsahu

Jeden riadok ušetrí veľa zbytočného vybavovania: „Mimo rozsahu: vrátenie peňazí za platené hodiny; administrátori rušiaci rezervácie za členov.“ Zabráni tomu, aby príbeh rástol počas stavby.

Krok 5: Skontrolujte podľa INVEST

INVEST je bežný kontrolný zoznam pre dobré príbehy. Príbeh by mal byť:

Nie je treba bodovať každý príbeh. Je to najužitočnejšie, keď príbeh pôsobí zle a chcete vedieť prečo.

Dobré a zlé príklady

Ako rozdeliť príliš veľký príbeh

Veľké príbehy sú miesto, kde projekty uviazajú. Bežné spôsoby rozdelenia:

• Podľa role používateľa. Členovia rušia svoje vlastné rezervácie; zamestnanci rušia ktorékoľvek.
• Podľa kroku v toku. Prezerať hodiny; rezervovať hodinu; dostať pripomienku.
• Najprv jednoduchý prípad. Zrušiť bezplatnú hodinu teraz; poplatky a vrátenia peňazí rieši neskorší príbeh.
• Podľa variácie dát. Najprv podporiť jednu pobočku, neskôr viac.
• Šťastná cesta, potom chyby. Najprv postaviť funkčný tok, potom doplniť spracovanie plných hodín, expirovaných permanentiek a podobne.

Každý kúsok by mal byť stále niečo, čo by používateľ mohol využiť a čo by si všimol.

Používateľské príbehy ako výzvy

Používateľský príbeh s kritériami prijatia je veľmi blízko dobrej výzve pre AI nástroj na tvorbu aplikácií. Dáva AI kto, čo, prečo a definíciu hotovosti. Jeden príbeh posielajte v jednej správe:

Ako člen posilňovne chcem zrušiť rezerváciu hodiny z telefónu, aby niekto z čakacej listiny mohol zaujať moje miesto. Kritériá prijatia:

1. Zrušiť je pri každej rezervácii v Mojich rezerváciách, s krokom potvrdenia.
2. Zrušenie viac ako 12 hodín vopred len odstráni rezerváciu.
3. Menej ako 12 hodín vopred zobraz „Uplatní sa poplatok za neskoré zrušenie 5 USD“ pred potvrdením a poplatok zapíš k rezervácii.
4. Ak má hodina čakaciu listinu, prvý človek dostane miesto a e-mail.
5. Funguje na obrazovke so šírkou telefónu. Mimo rozsahu: vrátenia peňazí, zrušenia zamestnancami za členov. Postav to, potom v náhľade over každé kritérium a povedz mi, ktoré prechádzajú.

AI môžete tiež požiadať, aby z hrubej myšlienky navrhla príbehy, a potom ich sami upravte:

Tu je môj nápad na aplikáciu: [dve alebo tri vety]. Napíš používateľské príbehy pre prvú verziu, zoskupené podľa typu používateľa, každý s 3 až 5 kritériami Keď/Ak/Potom. Označ, ktoré sú nevyhnutné pre spustenie a ktoré môžu počkať.

Výsledok vždy prečítajte a upravte. AI nepozná vašich používateľov; vy áno.

Kritériá prijatia slúžia aj ako plán testov. Keď je príbeh postavený, prejdite každé kritérium sami. Náš návod o testovaní aplikácie pred spustením na to nadväzuje.

Kde používateľské príbehy zapadajú k ostatným dokumentom

• Dokument o požiadavkach na produkt opisuje celý produkt: problém, používateľov, rozsah. Používateľské príbehy sú podrobné časti v ňom. Pozrite si ako napísať PRD s AI.
• Hlásenie chyby opisuje niečo, čo je pokazené oproti príbehu, ktorý už bol postavený. Pozrite si ako napísať dobré hlásenie chyby.
• MVP je najmenšia množina príbehov, ktorá prináša základnú hodnotu. Pozrite si čo je MVP.

Časté chyby

• „Ako používateľ…“ Príliš vágne. Pomenujte skutočný typ používateľa.
• Vynechanie „aby“. Bez dôvodu nemôžete rozumne robiť kompromisy.
• Písanie riešenia namiesto potreby. „Chcem rozbaľovací zoznam“ zamkne dizajn skôr, než o ňom niekto premýšľal.
• Kritériá, ktoré sa nedajú otestovať. „Jednoduché“, „rýchle“ a „intuitívne“ sú želania, nie kritériá.
• Príbehy, ktoré sú v skutočnosti epiky. „Spravovať svoj účet“ je desať príbehov.
• Písanie každého príbehu vopred. Najbližšie pár napíšte podrobne; zvyšok nechajte ako jednoriadkové zhrnutie, kým sa k nemu nedostanete.

Príbehy v Mythex

V Mythex je režim Plan dobré miesto na premenu nápadu na príbehy: agent pred úpravou čohokoľvek prerokuje prístup. Keď je príbeh pripravený, prepnite na Build a vložte ho, jeden príbeh na správu. Po každom môže /test preklikať náhľad a overiť tok a ak odpoveď dopadne zle, môžete ju vrátiť cez Vrátiť sa k tomuto bodu. Pozrite si účinné výzvy v dokumentácii a náš návod o písaní výziev pre AI nástroje na tvorbu aplikácií.

Kontrolný zoznam používateľského príbehu

• Pomenúva konkrétny typ používateľa
• Opisuje potrebu, nie dizajn
• Obsahuje skutočný dôvod v časti „aby“
• Má tri až šesť overiteľných kritérií prijatia
• Pokrýva aspoň jeden okrajový prípad alebo chybu
• Uvádza, čo je mimo rozsahu
• Je dostatočne malý na to, aby sa postavil a otestoval naraz
• Kritériá sa po stavbe kontrolujú jedno po druhom

Otázky