Povești utilizator: cum le scrii și le accepți corect

Povestea utilizatorului (în engleză user story) este o descriere scurtă a unei cerințe, formulată din punctul de vedere al persoanei care va folosi rezultatul. Nu este un document tehnic și nu încearcă să spună cum se face ceva; spune cine are nevoie, ce vrea să poată face și de ce. Formatul clasic are trei părți: „Ca [rol], vreau [acțiune], ca să [beneficiu]”.

Poveștile sunt unealta de bază pentru a descrie munca în echipele agile, dar le poți folosi în orice proiect în care cerințele trebuie înțelese de oameni cu pregătiri diferite. Ele schimbă tonul discuției: în loc de „adăugăm un câmp în formular”, vorbești despre nevoia reală a cuiva.

Cum arată o poveste utilizator bine scrisă?

O poveste bună are un rol precis, o acțiune concretă și un beneficiu pe care îl poți verifica. Compară două formulări pentru aceeași cerință dintr-un magazin online.

• Slab: „Sistemul trebuie să trimită e-mailuri.”
• Bun: „Ca client, vreau să primesc un e-mail de confirmare după plasarea comenzii, ca să știu că plata a fost înregistrată.”

A doua versiune spune cui folosește, ce vede și de ce contează. Din ea echipa poate deduce momentul trimiterii, conținutul minim și ce se întâmplă dacă plata eșuează.

Un lucru care contează mult: rolul trebuie să fie real. „Ca utilizator” spune puțin; „ca administrator de magazin”, „ca vânzător nou” sau „ca contabil” ajută la deciziile de design. Dacă nu poți numi persoana care beneficiază, e posibil ca cerința să nu aibă valoare.

Ce sunt criteriile de acceptare și cum le formulezi?

Criteriile de acceptare sunt condițiile concrete pe care povestea trebuie să le îndeplinească pentru a fi considerată terminată. Ele transformă o intenție într-un test clar: fie sunt îndeplinite, fie nu.

Un format popular este Dat fiind – Când – Atunci (în engleză Given – When – Then), care descrie un scenariu pas cu pas:

1. Dat fiind că clientul a plătit comanda cu cardul,
2. când plata este confirmată de bancă,
3. atunci primește un e-mail cu numărul comenzii și cu produsele cumpărate.

Alternativ, poți folosi o listă simplă de condiții verificabile. Regulile bune pentru ambele variante:

• Fiecare criteriu are un răspuns clar da/nu, fără „rapid” sau „ușor” lăsate fără măsură.
• Sunt scrise în limbajul beneficiarului, nu al programatorilor.
• Acoperă și situațiile neplăcute: ce se întâmplă când datele lipsesc sau când plata este respinsă.
• Sunt convenite înainte de începerea lucrului, nu după.

Ce înseamnă regula INVEST?

INVEST este o listă de șase calități pe care ar trebui să le aibă o poveste bună. Cuvântul este un acronim și funcționează ca verificare rapidă la rafinarea backlogului.

Poveștile prea mari se numesc epice și se sparg în povești mai mici. O poveste de tipul „ca client, vreau să gestionez contul meu” este un epic: conține schimbarea parolei, istoricul comenzilor, adresele salvate. Fiecare dintre ele poate fi o poveste separată, livrabilă în câteva zile.

Sfat: Dacă echipa nu poate estima o poveste, de obicei nu o înțelege încă. Nu forța o cifră; organizează o discuție scurtă cu persoana care a cerut-o.

Cum se leagă poveștile de backlog și de planificare?

Poveștile se adună în backlogul produsului, o listă ordonată după prioritate, din care echipa alege ce intră în fiecare ciclu de lucru. Ordinea o stabilește responsabilul de produs, folosind criterii precum valoarea pentru client și riscul; pentru un instrument concret de sortare vezi Metoda MoSCoW: cum prioritizezi cerințele proiectului.

În Scrum, poveștile alese pentru ciclul următor ajung în backlogul sprintului la planificare, iar rolurile și evenimentele sunt explicate în Scrum pe înțeles: roluri, sprinturi și ceremonii. În Kanban, ele devin cartonașe care circulă pe tablă; modul de organizare îl găsești în Kanban pentru echipe: cum organizezi vizual fluxul de lucru. Dacă te întrebi cum se potrivește acest mod de lucru cu un plan clasic, comparația din Agile și Waterfall: comparație între metodologiile de proiect te ajută.

Pentru felul în care îți planifici timpul de discuție cu beneficiarul, ajută și Ședințele eficiente: cum le pregătești, conduci și închei. Un obicei sănătos este rafinarea backlogului: o ședință scurtă, regulată, în care echipa citește poveștile viitoare, pune întrebări, le sparge și adaugă criterii. Poveștile din vârful listei trebuie să fie clare cu un ciclu înainte de a fi începute, altfel echipa pierde timp cu clarificări în mijlocul lucrului.

Ce greșeli apar când scrii povești?

Cea mai comună greșeală este să scrii sarcini tehnice deghizate în povești, de exemplu „Ca dezvoltator, vreau să actualizez baza de date”. Sarcinile tehnice există, dar ele susțin o poveste cu valoare pentru utilizator și se leagă de ea.

Alte erori întâlnite:

• Poveștile sunt scrise de o singură persoană și nu sunt discutate cu cei care vor lucra la ele.
• Lipsesc criteriile de acceptare, așa că „gata” înseamnă lucruri diferite pentru fiecare.
• Poveștile sunt prea detaliate și devin un contract rigid, ceea ce omoară flexibilitatea.
• Se pierde legătura cu obiectivul proiectului: echipa livrează o sumă de funcții care nu rezolvă problema inițială.

Pentru imaginea de ansamblu a unui proiect, de la obiective la închidere, vezi Managementul de proiect: ghid complet pentru începători.