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

Korisnička priča je kratak opis funkcije iz ugla 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. Držite svaku priču dovoljno malom da se napravi i testira odjednom, i pišite kriterijume tako da ih svako može proveriti.

Korisničke priče su postale popularne u agilnim timovima za softver, ali su podjednako korisne kada sami gradite uz AI alat za izgradnju aplikacija. Dobra priča je dobar prompt.

Format

Korisnička priča ima tri dela:

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

• Ko je određen tip korisnika: posetilac koji prvi put dolazi, član koji plaća, recepcionar u klinici, administrator. Ne „korisnik“.
• Šta je ono što želi da uradi, rečima koje on koristi. Ne kako ekran radi.
• Zašto je ishod do kojeg mu je stalo. To je deo koji ljudi preskoče, a upravo on sprečava da napravite pogrešnu stvar.

Primer:

Kao član teretane, želim da otkažem rezervaciju časa sa telefona kako bih osoba sa liste čekanja mogla da preuzme moje mesto i kako ne bih platio kaznu za nedolazak.

Razlog vam govori dve stvari koje „šta“ nije: mora da radi na telefonu, i u igri su lista čekanja i pravila o kazni.

Kriterijumi prihvatanja

Priča kaže šta se traži. Kriterijumi prihvatanja kažu kada je to urađeno. Treba da budu dovoljno konkretni da bi dvoje ljudi složili da li svaki prolazi.

Uobičajen način da ih napišete je Dato / Kada / Onda:

• Dato početno stanje
• Kada korisnik nešto uradi
• Onda je ovo rezultat

Za priču o rezervaciji teretane:

1. Dato da 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 da otkažem rezervaciju i čas ima listu čekanja, kada otkazivanje bude sačuvano, onda prva osoba sa liste čekanja dobija mesto i imejl.
3. Dato da je rezervacija manje od 12 sati udaljena, kada dodirnem Otkaži, onda vidim da se naplaćuje kazna za kasno otkazivanje pre nego što potvrdim.
4. Dato da sam na ekranu širine telefona, onda je dugme Otkaži vidljivo bez pomeranja u stranu.

Obična lista provere takođe radi, sve dok je svaka stavka proverljiva. „Otkazivanje je jednostavno“ nije proverljivo. „Otkazivanje traje najviše dva dodira sa liste rezervacija“ jeste.

Korak po korak: pisanje dobre priče

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

Izaberite jedan tip korisnika i nešto što mu danas predstavlja muku. Ako ste razgovarali sa korisnicima, koristite njihove reči. „Uvek zaboravim da otkažem pa naplate ostanu“ je bolja polazna tačka od „dodaj funkciju za otkazivanje“.

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

Popunite šablon. Ako ne možete da napišete uverljivo „kako bih“, pitajte se da li je funkcija uopšte potrebna.

Korak 3: Dodajte tri do šest kriterijuma prihvatanja

Prvo pokrijte glavni uspešan slučaj, pa onda važne varijacije: druga uloga, prazno stanje, ograničenje, greška. Ako pišete više od šest, priča je verovatno prevelika.

Korak 4: Zabeležite šta je van obima

Jedna linija štedi dosta vraćanja unazad: „Van obima: povraćaji za plaćene časove; administratori koji otkazuju u ime članova.“ Ona sprečava da priča raste dok gradite.

Korak 5: Proverite je prema INVEST

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

Ne morate da ocenjujete svaku priču. Najkorisnije je kada priča deluje pogrešno, pa želite da znate zašto.

Dobri i loši primeri

Kako podeliti priču koja je prevelika

Velike priče su mesto gde projekti zapnu. Uobičajeni načini deljenja:

• Po ulozi korisnika. Članovi otkazuju sopstvene rezervacije; osoblje otkazuje bilo čije.
• Po koraku u toku. Pregled časova; rezervacija časa; podsetnik.
• Prvo jednostavan slučaj. Otkaži besplatan čas sada; kazne i povraćaje obradi u kasnijoj priči.
• Po varijaciji podataka. Podržite prvo jednu lokaciju, pa kasnije više.
• Srećan tok, pa greške. Napravite da radi, pa dodajte obradu za popunjene časove, istekle paketa i tako dalje.

Svaki deo i dalje treba da bude nešto što bi korisnik mogao da koristi i primeti.

Korišćenje korisničkih priča kao promptova

Korisnička priča sa kriterijumima prihvatanja veoma je blizu dobrom promptu za AI alat za izgradnju aplikacija. Daje AI-ju ko, šta, zašto i definiciju završenog. Pošaljite jednu priču po poruci:

Kao član teretane, želim da otkažem rezervaciju časa sa telefona kako bi osoba sa liste čekanja mogla da preuzme moje mesto. Kriterijumi prihvatanja:

1. Otkazivanje je dostupno uz svaku rezervaciju na stranici Moje rezervacije, sa korakom potvrde.
2. Otkazivanje više od 12 sati pre časa samo uklanja rezervaciju.
3. Manje od 12 sati pre, prikaži „Važi kazna za kasno otkazivanje od 5 USD“ pre potvrde i zabeleži kaznu uz rezervaciju.
4. Ako čas ima listu čekanja, prva osoba dobija mesto i imejl.
5. Radi na ekranu širine telefona. Van obima: povraćaji, osoblje koje otkazuje za članove. Napravi ovo, zatim proveri svaki kriterijum u pregledu i reci mi koji prolaze.

AI možete i da zamolite da napiše priče na osnovu grube ideje, pa ih sami izmenite:

Evo moje ideje za aplikaciju: [dve 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 nužne za lansiranje, a koje mogu da sačekaju.

Uvek pročitajte i izmenite rezultat. AI ne zna vaše korisnike; vi znate.

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

Gde se korisničke priče uklapaju sa drugim dokumentima

• Dokument sa zahtevima za proizvod opisuje ceo proizvod: problem, korisnike, obim. Korisničke priče su detaljni delovi unutar njega. Pogledajte kako napisati PRD uz AI.
• Izveštaj o grešci opisuje nešto što je pokvareno u odnosu na priču koja je već napravljena. Pogledajte kako napisati dobar izveštaj o grešci.
• MVP je najmanji skup priča koji isporučuje osnovnu vrednost. Pogledajte šta je MVP.

Česte greške

• „Kao korisnik…“ Preširoko. Imenujte stvarni tip korisnika.
• Preskakanje „kako bih“. Bez razloga ne možete da pravite razumne kompromise.
• Pisanje rešenja umesto potrebe. „Želim padajući meni“ zaključava dizajn pre 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“ su deset priča.
• Pisanje svih priča unapred. Napišite sledećih nekoliko detaljno; ostale držite kao jednolinijske opise dok ne stignete do njih.

Priče u Mythex-u

U Mythex-u je režim Plan dobro mesto da ideju pretvorite u priče: agent razgovara o pristupu pre nego što bilo šta promeni. Kada je priča spremna, pređite na Build i nalepite je, jednu priču po poruci. Posle svake, /test može da prođe kroz pregled i proveri tok, a bilo koji odgovor možete da vratite sa Vrati na ovu tačku ako je pošao naopako. Pogledajte efikasne promptove u dokumentaciji i naš vodič o pisanju promptova za AI alate za izgradnju aplikacija.

Kontrolna lista za korisničke priče

• Imenuje konkretan tip korisnika
• Opisuje potrebu, a ne dizajn
• Uključuje pravi razlog „kako bih“
• Ima tri do šest kriterijuma prihvatanja koji se mogu testirati
• Pokriva bar jedan granični slučaj ili grešku
• Navodi šta je van obima
• Dovoljno mala da se napravi i testira u jednom zamahu
• Kriterijumi se proveravaju posle izrade, jedan po jedan

Pitanja