Cum să Scrie Criterii de Acceptare: Exemple și Bune Practici

Aici, la Mobindustry, operăm cu o abordare Agile. Asta înseamnă că folosim componente Agile, cum ar fi poveștile utilizatorilor și criteriile de acceptare. Echipele și organizațiile de înaltă performanță au aceste componente în jurnalele lor de produse și știu cum să le creeze și să le utilizeze eficient.

dacă produsul dvs. nu are povești despre utilizatori și criterii de acceptare — sau dacă nu sunt clar definite — riscați ca așteptările dvs. să nu convergă cu realitatea., Poveștile utilizatorilor și criteriile de acceptare sunt responsabile pentru reprezentarea modului în care utilizatorul final va utiliza aplicația dvs. și a modului în care echipa dvs. de dezvoltare ar trebui să execute fiecare sarcină de dezvoltare. Când începem să lucrăm la un produs nou, echipa noastră colaborează cu clientul pentru a defini poveștile utilizatorilor.

o poveste de utilizator este o descriere scurtă și simplă a unei caracteristici de produs din perspectiva unei persoane care dorește să utilizeze acea caracteristică. Poveștile utilizatorilor sunt utilizate pentru a defini întârzierea produsului într-un flux de lucru de dezvoltare agil., lista de produse este, în esență, o colecție de povești de utilizator care informează specificația funcțională și dezvoltarea de caracteristici pentru un anumit produs sau serviciu. Poveștile utilizatorilor constau din trei părți: o persoană a utilizatorului pentru care este scrisă povestea, o descriere a caracteristicii pe care utilizatorul o cere și o explicație a necesității pe care o satisface caracteristica.

Iată cum se scrie o poveste de utilizator:

ca (utilizator) vreau o (caracteristică), astfel încât să pot (satisface o nevoie).

Să aruncăm o privire la modul în care ar putea arăta o poveste de utilizator., Vom lua Airbnb ca exemplu. Să ne imaginăm cum ar putea arăta o poveste tipică de utilizator pentru un produs precum Airbnb.

„ca utilizator, vreau să caut o destinație pentru a putea rezerva cazare într-un oraș străin.”

Definirea criteriilor de acceptare

acum, trebuie să ne asigurăm că poveștile utilizatorilor sunt completate corect și se potrivesc cerințelor clientului. criteriile de acceptare sunt condițiile pe care un produs software trebuie să le îndeplinească pentru a fi acceptat de un Utilizator, Client sau, în cazul funcționalității la nivel de sistem, Sistemul consumator.,

criteriile de acceptare sunt un set de declarații, fiecare cu un rezultat clar de trecere / eșec, care poate fi măsurat și specifică atât cerințele funcționale, cât și cele nefuncționale.

scrierea criteriilor de acceptare este importantă nu numai pentru stabilirea așteptărilor clientului de la produs, ci și pentru procesul de dezvoltare. Firește, oameni diferiți văd aceeași problemă din unghiuri diferite. Criteriile de acceptare bine definite oferă o imagine uniformă a funcționalității pe care intenționați să o implementați.,

oricine ar trebui să poată merge până la o placă Scrum, să apuce un articol din lista de produse, să citească criteriile de acceptare și să vadă clar tot ce trebuie completat pentru ca acel articol să fie mutat în coloana done. Criteriile de acceptare vă spun ce trebuie făcut pentru ca o anumită parte a unui produs să fie terminată.

De ce avem nevoie de criterii de acceptare?,

• definirea limitelor. Criteriile de acceptare ajută echipa de dezvoltare să definească limitele unei povești de utilizator. Acestea servesc ca o formă de confirmare a faptului că aplicația funcționează așa cum era de așteptat, ceea ce înseamnă că povestea utilizatorului este completă.
• atingerea consensului. Criteriile de acceptare permit echipei de dezvoltare să fie pe aceeași pagină cu clientul. Aceștia informează echipa de dezvoltare despre exact ce condiții trebuie îndeplinite și se asigură că clientul știe la ce să se aștepte de la aplicație.
• raționalizarea testării de acceptare., Criteriile de acceptare sunt fundamentul testării acceptării poveștii utilizatorului. Fiecare criteriu de acceptare ar trebui să fie testat independent și să aibă scenarii clare de succes sau eșec.
• planificarea și estimarea. Criteriile de acceptare vă permit să distribuiți poveștile utilizatorilor în activități, astfel încât acestea să fie evaluate și programate corespunzător.
• descriind scenarii negative. Criteriile de acceptare pot necesita ca sistemul să identifice o parolă slabă și să împiedice un utilizator să continue, de exemplu., Introducerea unui format incorect de parolă este un exemplu de scenariu negativ în care un utilizator introduce date incorecte sau se comportă în mod neașteptat. Criteriile de acceptare identifică aceste scenarii și explică modul în care sistemul ar trebui să răspundă la acestea.

cine scrie criteriile de acceptare?,

scrierea criteriilor de acceptare ajută la stabilirea unei înțelegeri comune între proprietarul produsului și echipa de dezvoltare în ceea ce privește rezolvarea problemei unui client sau crearea capabilităților produsului. Deoarece criteriile de acceptare se referă la client și la echipă, acestea trebuie scrise fie de client, fie de un membru al echipei. la Mobindustry, analiștii noștri de afaceri scriu toate criteriile de acceptare pentru poveștile utilizatorilor. Analiștii de afaceri înțeleg nevoile clientului și ce trebuie să știe dezvoltatorii pentru a îndeplini cerințele proiectului., criteriile de acceptare sunt documentate și confirmate înainte de începerea proiectului, deoarece echipa și clientul trebuie să convină asupra rezultatelor care vor satisface cerințele clientului.

Exemple de povești de utilizator cu criterii de acceptare

acum, că aveți o înțelegere clară a ceea ce povești de utilizator și criteriile de acceptare sunt, să aruncăm o privire la câteva exemple.,

Exemplul 1

povestea utilizatorului: ca utilizator, vreau să mă pot înregistra în serviciu, astfel încât să pot începe cumpărăturile online.

criterii de acceptare:

• utilizatorii pot trimite un formular doar completând toate câmpurile obligatorii.
• E-mailul pe care utilizatorul îl furnizează nu trebuie furnizat de un serviciu de e-mail gratuit.
• trimiterile din același IP pot fi făcute doar de trei ori în 30 de minute.
• utilizatorii primesc e-mailuri de notificare după înregistrarea cu succes.,

Exemplul 2

povestea utilizatorului: ca utilizator, pot accesa o notificare pe dispozitivul meu imediat după primirea acesteia.

criterii de acceptare:

• glisarea / atingerea unei notificări duce utilizatorul direct la mesaj.vizualizarea afișează conversația — dacă mesajul nou a fost un răspuns, atunci este afișat deasupra originalului.
• Numărul de mesaje este actualizat.
• un mesaj este marcat citit după ce este afișat.

7 sfaturi despre scrierea criteriilor de acceptare bune

criteriile de acceptare nu sunt ușor de scris., În ciuda formatului simplu, scrierea textului este o provocare. Iată șapte sfaturi pentru a vă ajuta să evitați greșelile comune în timp ce scrieți criterii de acceptare sau să revizuiți criteriile scrise de un membru al echipei dvs.

• Document criterii înainte de începerea procesului de dezvoltare. În acest fel, echipa are mai multe șanse să surprindă toate nevoile clientului în avans. Inițial, este suficient să setați criterii pentru un număr mic de povești ale utilizatorilor pentru a finaliza întârzierile pentru două sprinturi. Criteriile de acceptare documentate sunt apoi utilizate de dezvoltatori pentru a planifica procesul tehnic.,
• nu face criteriile de acceptare prea înguste. Criteriile de acceptare care sunt prea specifice lasă dezvoltatorilor puțin spațiu de manevră. Pentru a evita acest lucru, amintiți-vă că criteriile de acceptare ar trebui să fie o expresie a intenției, nu o decizie finală. Mai mult, este posibil ca criteriile de acceptare restrânse să nu țină cont de toate acțiunile utilizatorilor.
• păstrați criteriile realizabile. Criteriile de acceptare eficiente definesc o cantitate minimă rezonabilă de funcționalitate pe care o puteți furniza. Dar dacă continuați să descrieți toate detaliile mici, există riscul ca echipa dvs. să se blocheze în sute de sarcini mici.,
• evitați prea larg de criterii de acceptare. Criteriile generale de acceptare fac ca o poveste de utilizator să fie vagă. Criteriile eficiente de acceptare trebuie să contureze domeniul de activitate, astfel încât dezvoltatorii să își poată planifica și estima în mod corespunzător eforturile.
• evitați detaliile tehnice. Criteriile de acceptare trebuie scrise într-un limbaj simplu. Este posibil ca părțile interesate și managerii dvs. să nu aibă cunoștințe tehnice, astfel încât utilizarea unui limbaj simplu va face criteriile ușor de înțeles pentru toată lumea.
• ajunge la un consens., Aceeași problemă poate fi rezolvată în moduri diferite de către membrii echipei și părțile interesate, în funcție de punctele lor de vedere. Asigurați-vă că comunicați criteriile de acceptare părților interesate și membrilor echipei și ajungeți la un acord reciproc.
• scrie criterii de acceptare testabile. Acest lucru va oferi testerilor posibilitatea de a se asigura că toate cerințele sunt îndeplinite și va permite dezvoltatorilor să știe dacă povestea utilizatorului este completă.,

cum se scrie criteriile de acceptare

Iată cinci reguli generale care vă vor ajuta să rezolvați problemele cu formularea criteriilor de acceptare. Aceste reguli vă vor permite să economisiți timp prețios și să stabiliți o înțelegere între proprietarul produsului și echipa de dezvoltare.

Regula #1: Evitați ” nu ”

„nu ” înseamnă” în niciun caz ” și, prin urmare, nu va fi suficient timp pentru a verifica respectarea unei astfel de condiții., Dacă rescrieți cerința fără a utiliza „nu”, aceasta va fi mai clară și, cel mai important, verificabilă.

exemplu:

poveste utilizator

nu: ca utilizator, nu vreau să trebuiască să introduc parola de fiecare dată când îmi accesez contul.
Do: în calitate de utilizator, vreau ca parola mea să fie memorată și completată automat, astfel încât să pot accesa Contul meu fără a reintroduce parola.

criterii de acceptare

Nu: sistemul nu trebuie să eșueze.
Do: sistemul ar trebui să aibă o disponibilitate de cel puțin 90%.,

excepție

puteți utiliza ” nu „în criteriile de acceptare pentru a introduce o obiecție logică, cum ar fi” formularul de conectare nu trebuie să fie roșu.”În cele mai multe cazuri, acest lucru se va aplica cerințelor nefuncționale. În acest exemplu, formulăm o constrângere care poate fi ușor verificată dacă gama de nuanțe de roșu este clar definită (de exemplu, specificată în format RGB).,