Kako napisati korisničke priče (sa primjerima i kriterijumima prihvatanja)

Korisnička priča je kratak opis funkcije iz perspektive korisnika: "Kao [tip korisnika], želim [cilj] kako bih [razlog]." Ispod nje pišete kriterijume prihvatanja, nekoliko konkretnih uslova koji moraju biti ispunjeni da bi priča važila kao završena. Svaku priču držite dovoljno malom da se izgradi i testira odjednom, a kriterijume pišite tako da ih svako može provjeriti.

Korisničke priče su postale popularne u agilnim timovima za razvoj softvera, ali su jednako korisne kada gradite sami uz AI alat za izradu aplikacija. Dobra priča je dobar upit.

Format

Korisnička priča ima tri dijela:

Kao [ko], želim [šta] kako bih [zašto].

• Ko je konkretna vrsta korisnika: prvi put posjetilac, plaćajući član, recepcionar u klinici, administrator. Ne "korisnik".
• Šta je ono što korisnik želi da uradi, njegovim riječima. Ne kako funkcioniše ekran.
• Zašto je ishod koji mu je važan. To je dio koji ljudi preskoče, a koji sprječava da gradite pogrešnu stvar.

Primjer:

Kao član teretane, želim da otkažem rezervaciju časa sa telefona kako bih neko sa liste čekanja mogao zauzeti moje mjesto i ne bih platio naknadu za izostanak.

Razlog vam govori dvije stvari koje "šta" nije: mora raditi na telefonu, i u igri su lista čekanja i pravila o naknadama.

Kriterijumi prihvatanja

Priča kaže šta se želi. Kriterijumi prihvatanja kažu kada je to završeno. Trebaju biti dovoljno konkretni da bi se dvije osobe složile da li svaki prolazi.

Uobičajen način pisanja je Dato / Kada / Onda (Given / When / Then):

• Dato neko polazno stanje
• Kada korisnik nešto uradi
• Onda je ovo rezultat

Za priču o rezervaciji teretane:

1. Dato imam rezervaciju koja je više od 12 sati udaljena, kada dodirnem Otkaži i potvrdim, onda se rezervacija uklanja i vidim "Rezervacija otkazana".
2. Dato otkažem rezervaciju i čas ima listu čekanja, kada se otkazivanje sačuva, onda prva osoba na listi čekanja dobija mjesto i e-poruku.
3. Dato rezervacija je manje od 12 sati udaljena, kada dodirnem Otkaži, onda vidim da se prije potvrde primjenjuje naknada za kasno otkazivanje.
4. Dato sam na ekranu širine telefona, onda je dugme Otkaži vidljivo bez horizontalnog pomjeranja.

Obična lista provjera također funkcioniše, sve dok je svaka stavka provjerljiva. "Otkazivanje je jednostavno" nije provjerljivo. "Otkazivanje traje najviše dva dodira s liste rezervacija" jeste.

Korak po korak: pisanje dobre priče

Korak 1: Počnite od stvarnog korisnika i stvarnog problema

Izaberite jednu vrstu korisnika i nešto što mu danas predstavlja problem. Ako ste razgovarali s korisnicima, koristite njihove riječi. "Uvijek zaboravim da otkažem i naplate mi se" je bolja polazna tačka nego "dodaj funkciju otkazivanja".

Korak 2: Napišite priču u jednoj rečenici

Popunite šablon. Ako ne možete napisati uvjerljivo "kako bih", pitajte se da li je funkcija uopšte potrebna.

Korak 3: Dodajte tri do šest kriterijuma prihvatanja

Pokrijte prvo glavni uspješan slučaj, pa onda važne varijante: druga uloga, prazno stanje, ograničenje, greška. Ako pišete više od šest, priča je vjerovatno prevelika.

Korak 4: Zabilježite šta je van obima

Jedan red uštedi mnogo naknadnog dogovaranja: "Van obima: povrati za plaćene časove; administratori koji otkazuju u ime članova." Sprječava da priča raste dok je gradite.

Korak 5: Provjerite je li u skladu s INVEST-om

INVEST je uobičajena lista za dobre priče. Priča treba biti:

Ne morate ocjenjivati svaku priču. Najkorisnije je kada priča djeluje pogrešno i želite da saznate zašto.

Dobri i loši primjeri

Kako podijeliti priču koja je prevelika

Velike priče su mjesto gdje projekti zapinju. Uobičajeni načini dijeljenja:

• Po ulozi korisnika. Članovi otkazuju svoje rezervacije; osoblje otkazuje bilo čije.
• Po koraku u toku. Pregledaj časove; rezerviši čas; primi podsjetnik.
• Prvo jednostavan slučaj. Otkaži besplatan čas sada; naknade i povrate obradi u kasnijoj priči.
• Po varijaciji podataka. Podrži prvo jednu lokaciju, kasnije više.
• Glavni tok, pa greške. Izgradi da radi, pa onda dodaj obradu za pun čas, istekle pakete i slično.

Svaki dio i dalje treba biti nešto što korisnik može koristiti i primijetiti.

Korištenje korisničkih priča kao upita

Korisnička priča s kriterijumima prihvatanja vrlo je blizu dobrom upitu za AI alat za izradu aplikacija. Daje AI-ju ko, šta, zašto i definiciju završenog. Šaljite jednu priču po poruci:

Kao član teretane, želim da otkažem rezervaciju časa sa telefona kako bih neko sa liste čekanja mogao zauzeti moje mjesto. Kriterijumi prihvatanja:

1. Otkaži se nalazi na svakoj rezervaciji u Mojim rezervacijama, uz korak potvrde.
2. Otkazivanje više od 12 sati prije časa samo uklanja rezervaciju.
3. Manje od 12 sati prije, prikaži "Primjenjuje se naknada za kasno otkazivanje od 5
   quot; prije potvrde, i zabilježi naknadu na rezervaciji.
4. Ako čas ima listu čekanja, prva osoba dobija mjesto i e-poruku.
5. Radi na ekranu širine telefona. Van obima: povrati, otkazivanje od strane osoblja u ime članova. Izgradi ovo, zatim provjeri svaki kriterijum u pregledu i reci mi koji prolaze.

Možete i zamoliti AI da napiše priče iz grube ideje, a zatim ih sami uredite:

Evo moje ideje za aplikaciju: [dvije ili tri rečenice]. Napiši korisničke priče za prvu verziju, grupisane po tipu korisnika, svaka sa 3 do 5 kriterijuma Dato/Kada/Onda. Označi koje su obavezne za lansiranje, a koje mogu sačekati.

Uvijek pročitajte i uredite rezultat. AI ne poznaje vaše korisnike; vi ih poznajete.

Kriterijumi prihvatanja služe i kao plan testiranja. Kada je priča izgrađena, prođite kroz svaki kriterijum sami. Naš vodič o testiranju aplikacije prije lansiranja se nadovezuje na ovo.

Gdje korisničke priče stoje u odnosu na druge dokumente

• Dokument o zahtjevima proizvoda opisuje cijeli proizvod: problem, korisnike, obim. Korisničke priče su detaljni dijelovi unutar njega. Pogledajte kako napisati PRD uz AI.
• Izvještaj o grešci opisuje nešto što ne radi u odnosu na priču koja je već izgrađena. Pogledajte kako napisati dobar izvještaj o grešci.
• MVP je najmanji skup priča koji isporučuje osnovnu vrijednost. Pogledajte šta je MVP.

Česte greške

• "Kao korisnik…" Previše neodređeno. Imenujte stvarnu vrstu korisnika.
• Preskakanje "kako bih". Bez razloga ne možete donositi razumne kompromise.
• Pisanje rješenja umjesto potrebe. "Želim padajući meni" zaključava dizajn prije nego što iko razmisli o njemu.
• Kriterijumi koji se ne mogu testirati. "Lako", "brzo" i "intuitivno" su želje, a ne kriterijumi.
• Priče koje su zapravo epovi. "Upravljaj svojim nalogom" je deset priča.
• Pisanje svih priča unaprijed. Napišite sljedeće nekoliko detaljno; ostale držite kao jednorečenične stavke dok ne dođete do njih.

Priče u Mythexu

U Mythexu je režim Plan dobro mjesto za pretvaranje ideje u priče: agent raspravlja o pristupu prije nego što išta promijeni. Kada je priča spremna, pređite na Build i zalijepite je, jednu po poruci. Nakon svake, /test može kliknuti kroz pregled i provjeriti tok, a bilo koji odgovor možete vratiti pomoću Revert to this point ako je krenuo pogrešnim putem. Pogledajte efikasne upite u dokumentaciji i naš vodič o pisanju upita za AI alate za izradu aplikacija.

Lista za korisničku priču

• Imenuje konkretnu vrstu korisnika
• Opisuje potrebu, a ne dizajn
• Uključuje pravi razlog "kako bih"
• Ima tri do šest provjerljivih kriterijuma prihvatanja
• Pokriva bar jedan rubni slučaj ili grešku
• Navodi šta je van obima
• Dovoljno mala da se izgradi i testira odjednom
• Kriterijumi provjereni nakon izgradnje, jedan po jedan

Pitanja