Cum scrii povestiri de utilizator (cu exemple și criterii de acceptare)

O povestire de utilizator este o descriere scurtă a unei funcționalități din punctul de vedere al utilizatorului: „Ca [tip de utilizator], vreau [obiectiv], ca să [motiv].” Sub ea scrii criteriile de acceptare, câteva condiții specifice care trebuie să fie adevărate pentru ca povestirea să fie considerată terminată. Păstrează fiecare povestire suficient de mică încât să o construiești și să o testezi dintr-o dată, și scrie criteriile astfel încât oricine să le poată verifica.

Povestirile de utilizator au devenit populare în echipele agile de software, dar sunt la fel de utile când construiești singur cu un generator de aplicații AI. O povestire bună este un prompt bun.

Formatul

O povestire de utilizator are trei părți:

Ca [cine], vreau [ce] ca să [de ce].

• Cine este un tip specific de utilizator: un vizitator care vine prima dată, un membru plătitor, un recepționer de clinică, un administrator. Nu „utilizatorul”.
• Ce este lucrul pe care vrea să îl facă, în cuvintele lui. Nu cum funcționează ecranul.
• De ce este rezultatul care îl interesează. Este partea pe care oamenii o sar și cea care te oprește să construiești lucrul greșit.

Exemplu:

Ca membru de sală, vreau să anulez o rezervare de curs de pe telefon ca să cineva de pe lista de așteptare să îmi ia locul și să nu fiu taxat pentru neprezentare.

Motivul îți spune două lucruri pe care „ce”-ul nu ți le spunea: trebuie să funcționeze pe telefon și sunt implicate lista de așteptare și regulile de taxare.

Criterii de acceptare

O povestire spune ce se dorește. Criteriile de acceptare spun când este gata. Ar trebui să fie suficient de specifice încât două persoane să fie de acord dacă fiecare trece sau nu.

O modalitate comună de a le scrie este Dat / Când / Atunci:

• Dat o situație de start
• Când utilizatorul face ceva
• Atunci acesta este rezultatul

Pentru povestirea despre rezervarea la sală:

1. Dat că am o rezervare cu mai mult de 12 ore înainte, când apăs Anulează și confirm, atunci rezervarea este eliminată și văd „Rezervare anulată”.
2. Dat că anulez o rezervare și cursul are listă de așteptare, când anularea se salvează, atunci prima persoană de pe lista de așteptare primește locul și un e-mail.
3. Dat o rezervare cu mai puțin de 12 ore înainte, când apăs Anulează, atunci văd că se aplică o taxă pentru anulare târzie înainte să confirm.
4. Dat că sunt pe un ecran de lățimea unui telefon, atunci butonul Anulează este vizibil fără să derulez lateral.

O listă simplă de verificare merge și ea, atâta timp cât fiecare element poate fi testat. „Anularea este ușoară” nu poate fi testată. „Anularea durează cel mult două apăsări din lista de rezervări” poate.

Pas cu pas: cum scrii o povestire bună

Pasul 1: Pornește de la un utilizator real și o problemă reală

Alege un tip de utilizator și ceva cu care se chinuie astăzi. Dacă ai făcut interviuri cu clienții, folosește cuvintele lor. „Uit mereu să anulez și mi se ia bani” este un punct de plecare mai bun decât „adaugă funcționalitate de anulare”.

Pasul 2: Scrie povestirea dintr-o linie

Completează șablonul. Dacă nu poți scrie un „ca să” convingător, întreabă-te dacă funcționalitatea este necesară.

Pasul 3: Adaugă trei până la șase criterii de acceptare

Acoperă mai întâi cazul principal de succes, apoi variațiile importante: alt rol, o stare goală, o limită, o eroare. Dacă scrii mai mult de șase, povestirea este probabil prea mare.

Pasul 4: Notează ce este în afara domeniului

O linie economisește multe reveniri: „În afara domeniului: rambursări pentru cursuri plătite; administratorii care anulează în numele membrilor.” Oprește povestirea să crească în timp ce o construiești.

Pasul 5: Verific-o cu INVEST

INVEST este o listă de verificare comună pentru povestiri bune. O povestire ar trebui să fie:

Nu trebuie să notezi fiecare povestire. Este cel mai util când o povestire pare greșită și vrei să știi de ce.

Exemple bune și slabe

Cum împarți o povestire prea mare

Povestirile mari sunt locul unde proiectele se blochează. Moduri comune de a le împărți:

• După rolul utilizatorului. Membrii își anulează propriile rezervări; personalul anulează rezervările oricui.
• După pasul din flux. Răsfoiește cursurile; rezervă un curs; primește un memento.
• Cazul simplu întâi. Anulează un curs gratuit acum; tratează taxele și rambursările într-o povestire ulterioară.
• După variația datelor. Susține mai întâi o singură locație; mai multe mai târziu.
• Cazul fericit, apoi erorile. Construiește-l să funcționeze, apoi adaugă gestionarea pentru cursuri pline, abonamente expirate și așa mai departe.

Fiecare bucată ar trebui să fie în continuare ceva ce un utilizator ar putea folosi și ar observa.

Folosirea povestirilor de utilizator ca prompturi

O povestire de utilizator cu criterii de acceptare este foarte aproape de un prompt bun pentru un generator de aplicații AI. Îi oferă AI-ului cine, ce, de ce și o definiție a terminării. Trimite câte o povestire pe mesaj:

Ca membru de sală, vreau să anulez o rezervare de curs de pe telefon, ca să poată cineva de pe lista de așteptare să îmi ia locul. Criterii de acceptare:

1. Anularea este la fiecare rezervare din Rezervările mele, cu un pas de confirmare.
2. Anularea cu mai mult de 12 ore înainte de curs doar elimină rezervarea.
3. Cu mai puțin de 12 ore înainte, arată „Se aplică o taxă de anulare târzie de 5 USD” înainte de confirmare și înregistrează taxa pe rezervare.
4. Dacă cursul are listă de așteptare, prima persoană primește locul și un e-mail.
5. Funcționează pe un ecran de lățimea unui telefon. În afara domeniului: rambursări, personal care anulează pentru membri. Construiește asta, apoi verifică fiecare criteriu în previzualizare și spune-mi care trec.

Poți cere și AI-ului să redacteze povestiri dintr-o idee brută, apoi să le editezi tu:

Iată ideea mea de aplicație: [două sau trei propoziții]. Scrie povestirile de utilizator pentru o primă versiune, grupate pe tip de utilizator, fiecare cu 3 până la 5 criterii de acceptare Dat/Când/Atunci. Marchează care sunt esențiale pentru lansare și care pot aștepta.

Citește și editează întotdeauna rezultatul. AI-ul nu îi cunoaște pe utilizatorii tăi; tu îi cunoști.

Criteriile de acceptare servesc și drept plan de testare. Când povestirea este construită, parcurge tu fiecare criteriu. Ghidul nostru despre cum îți testezi aplicația înainte de lansare se bazează pe asta.

Unde se potrivesc povestirile de utilizator cu alte documente

• Un document de cerințe de produs descrie întregul produs: problema, utilizatorii, domeniul. Povestirile de utilizator sunt piesele detaliate din interiorul lui. Vezi cum scrii un PRD cu AI.
• Un raport de eroare descrie ceva care este defect față de o povestire deja construită. Vezi cum scrii un raport de eroare bun.
• Un MVP este cel mai mic set de povestiri care livrează valoarea de bază. Vezi ce este un MVP.

Greșeli frecvente

• „Ca utilizator…” Prea vag. Numește tipul real de utilizator.
• Sărirea peste „ca să”. Fără motiv, nu poți face compromisuri sensibile.
• Scrierea soluției în loc de nevoie. „Vreau un meniu derulant” blochează un design înainte ca cineva să se fi gândit la el.
• Criterii care nu pot fi testate. „Ușor”, „rapid” și „intuitiv” sunt dorințe, nu criterii.
• Povestiri care sunt de fapt epopei. „Gestionează-mi contul” înseamnă zece povestiri.
• Scrierea tuturor povestirilor dinainte. Scrie-le detaliat pe următoarele câteva; păstrează restul ca o linie până ajungi la ele.

Povestiri în Mythex

În Mythex, modul Plan este un loc bun pentru a transforma o idee în povestiri: agentul discută abordarea înainte să modifice ceva. Când o povestire este gata, treci în Build și o lipești, câte o povestire pe mesaj. După fiecare, /test poate parcurge previzualizarea și verifica fluxul, iar poți reveni la orice răspuns cu Revino la acest punct dacă a mers pe drumul greșit. Vezi prompturi eficiente în documentație și ghidul nostru despre cum scrii prompturi pentru generatoarele de aplicații AI.

Listă de verificare pentru povestiri de utilizator

• Numește un tip specific de utilizator
• Descrie o nevoie, nu un design
• Include un motiv „ca să” real
• Are trei până la șase criterii de acceptare testabile
• Acoperă cel puțin un caz limită sau o eroare
• Precizează ce este în afara domeniului
• Suficient de mică pentru a fi construită și testată dintr-o dată
• Criteriile sunt verificate după construire, unul câte unul

Întrebări