Kako napisati korisničke priče (s primjerima i kriterijima prihvaćanja)

Korisnička priča je kratak opis značajke iz perspektive korisnika: "Kao [vrsta korisnika], želim [cilj] kako bih [razlog]." Ispod nje pišete kriterije prihvaćanja, nekoliko specifičnih uvjeta koji moraju biti ispunjeni da bi se priča smatrala gotovom. Neka svaka priča bude dovoljno mala da se izgradi i testira odjednom, a kriterije pišite tako da ih svatko može provjeriti.

Korisničke priče popularizirali su agilni softverski timovi, ali jednako su korisne kad sami gradite s AI alatom za izradu aplikacija. Dobra priča je dobar upit.

Format

Korisnička priča ima tri dijela:

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

• Tko je određena vrsta korisnika: posjetitelj koji dolazi prvi put, plaćeni član, recepcionar klinike, administrator. Ne "korisnik".
• Što je ono što želi učiniti, njegovim riječima. Ne kako ekran funkcionira.
• Zašto je ishod koji mu je važan. To je dio koji ljudi preskoče, a upravo on vas sprječava da gradite krivu stvar.

Primjer:

Kao član teretane, želim otkazati rezervaciju treninga s telefona kako bih netko s liste čekanja mogao preuzeti moje mjesto i ne bih platio naknadu za izostanak.

"Zašto" vam govori dvije stvari koje "što" nije: mora raditi na telefonu, a u igri su lista čekanja i pravila o naknadi.

Kriteriji prihvaćanja

Priča kaže što se želi. Kriteriji prihvaćanja kažu kada je to gotovo. Trebaju biti dovoljno specifični da se dvije osobe mogu složiti prolazi li svaki od njih.

Uobičajen način pisanja je Ako je dano / Kada / Onda:

• Ako je dano početna situacija
• Kada korisnik nešto učini
• Onda je ovo rezultat

Za priču o rezervaciji u teretani:

1. Ako je dano da imam rezervaciju više od 12 sati unaprijed, kada dodirnem Otkaži i potvrdim, onda se rezervacija uklanja i vidim "Rezervacija otkazana".
2. Ako otkažem rezervaciju i trening ima listu čekanja, kada se otkazivanje spremi, onda prva osoba na listi čekanja dobiva mjesto i e-poruku.
3. Ako je dano da je rezervacija manje od 12 sati unaprijed, kada dodirnem Otkaži, onda prije potvrde vidim da se primjenjuje naknada za kasno otkazivanje.
4. Ako sam na ekranu širine telefona, onda gumb Otkaži je vidljiv bez pomicanja u stranu.

Običan popis također radi, sve dok je svaka stavka provjerljiva. "Otkazivanje je jednostavno" nije provjerljivo. "Otkazivanje traje najviše dva dodira s popisa rezervacija" jest.

Korak po korak: pisanje dobre priče

Korak 1: Krenite od stvarnog korisnika i stvarnog problema

Odaberite jednu vrstu korisnika i nešto s čime se danas muči. Ako ste razgovarali s kupcima, koristite njihove riječi. "Uvijek zaboravim otkazati pa me naplate" bolja je polazna točka od "dodaj značajku otkazivanja".

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

Popunite predložak. Ako ne možete napisati uvjerljivo "kako bih", pitajte se uopće treba li ta značajka.

Korak 3: Dodajte tri do šest kriterija prihvaćanja

Pokrijte prvo glavni slučaj uspjeha, a zatim važne varijante: drugu ulogu, prazno stanje, ograničenje, grešku. Ako pišete više od šest, priča je vjerojatno prevelika.

Korak 4: Zabilježite što je izvan opsega

Jedan redak uštedi puno razmjene poruka: "Izvan opsega: povrati za plaćene treninge; administratori koji otkazuju u ime članova." Sprječava da priča naraste dok gradite.

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

INVEST je uobičajen popis za dobre priče. Priča bi trebala biti:

Ne morate ocijeniti svaku priču. Najkorisnije je kad priča djeluje krivo i želite znati 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 tijeku. Pregled treninga; rezervacija treninga; podsjetnik.
• Jednostavan slučaj prvo. Otkaži besplatan trening sada; naknade i povrate obradi u kasnijoj priči.
• Po varijaciji podataka. Prvo podrži jednu lokaciju, kasnije više.
• Ispravan tijek, pa greške. Izgradi da radi, pa dodaj obradu za pune treninge, istekle paketi i slično.

Svaki dio i dalje mora biti nešto što bi korisnik mogao koristiti i primijetiti.

Korištenje korisničkih priča kao upita

Korisnička priča s kriterijima prihvaćanja vrlo je slična dobrom upitu za AI alat za izradu aplikacija. Daje AI-ju tko, što, zašto i definiciju gotovog. Pošaljite jednu priču po poruci:

Kao član teretane, želim otkazati rezervaciju treninga s telefona kako bih netko s liste čekanja mogao preuzeti moje mjesto. Kriteriji prihvaćanja:

1. Otkazivanje je na svakoj rezervaciji u Mojim rezervacijama, uz korak potvrde.
2. Otkazivanje više od 12 sati prije treninga 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 uz rezervaciju.
4. Ako trening ima listu čekanja, prva osoba dobiva mjesto i e-poruku.
5. Radi na ekranu širine telefona. Izvan opsega: povrati, osoblje koje otkazuje za članove. Izgradi ovo, zatim u pregledu provjeri svaki kriterij i reci mi koji prolaze.

Možete i zamoliti AI da napiše nacrt priča 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, grupirane po vrsti korisnika, svaka s 3 do 5 kriterija Ako je dano / Kada / Onda. Označi koje su nužne za lansiranje, a koje mogu čekati.

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

Kriteriji prihvaćanja ujedno služe i kao vaš plan testiranja. Kad je priča izgrađena, prođite svaki kriterij sami. Naš vodič o testiranju aplikacije prije lansiranja nadovezuje se na to.

Gdje korisničke priče stoje uz druge dokumente

• Dokument o zahtjevima proizvoda opisuje cijeli proizvod: problem, korisnike, opseg. Korisničke priče su detaljni dijelovi unutar njega. Vidi kako napisati PRD uz AI.
• Prijava greške opisuje nešto što je pokvareno u odnosu na priču koja je već izgrađena. Vidi kako napisati dobru prijavu greške.
• MVP je najmanji skup priča koji isporučuje osnovnu vrijednost. Vidi što je MVP.

Česte greške

• "Kao korisnik…" Preopćenito. Navedite stvarnu vrstu korisnika.
• Preskakanje "kako bih". Bez razloga ne možete donositi razumne kompromise.
• Pisanje rješenja umjesto potrebe. "Želim padajući izbornik" zaključava dizajn prije nego što je itko o njemu razmislio.
• Kriteriji koji se ne mogu testirati. "Jednostavno", "brzo" i "intuitivno" su želje, a ne kriteriji.
• Priče koje su zapravo epovi. "Upravljaj mojim računom" je deset priča.
• Pisanje svih priča unaprijed. Detaljno napišite sljedeće nekoliko; ostale držite kao jednoredne opise dok ne dođete do njih.

Priče u Mythexu

U Mythexu je način Plan dobro mjesto za pretvaranje ideje u priče: agent raspravlja o pristupu prije nego što išta uredi. Kad je priča spremna, prebacite se na Build i zalijepite je, jednu po poruci. Nakon svake, /test može kliknuti kroz pregled i provjeriti tijek, a bilo koji odgovor možete vratiti pomoću Revert to this point ako je pošao krivim putem. Pogledajte učinkovite upite u dokumentaciji i naš vodič o pisanju upita za AI alate za izradu aplikacija.

Kontrolni popis korisničke priče

• Navodi određenu vrstu korisnika
• Opisuje potrebu, a ne dizajn
• Uključuje pravi razlog "kako bih"
• Ima tri do šest provjerljivih kriterija prihvaćanja
• Pokriva barem jedan rubni slučaj ili grešku
• Navodi što je izvan opsega
• Dovoljno mala da se izgradi i testira odjednom
• Kriteriji provjereni nakon izgradnje, jedan po jedan

Pitanja