de Elijah Valenciano

Criteriile de acceptare pentru scrierea criteriilor de acceptare
Imagine de DirectWorksMedia

Criteriile de acceptare pentru scrierea criteriilor de acceptare

Multe echipe de dezvoltare sunt prea familiarizați cu frustrările unor criterii de acceptare nesatisfăcătoare sau chiar cu lipsa criteriilor în sine. A nu defini cerințe înseamnă a te pregăti pentru luptă fără un plan de acțiune – echipa a făcut mai mulți pași spre eșec decât succes. Ofer sugestii specifice în elaborarea criteriilor de acceptare care pot îmbunătăți orice proces agil.

În primul rând, să definim rapid criteriile de acceptare.

Criteriile de acceptare sunt „condițiile pe care trebuie să le îndeplinească un produs software pentru a fi acceptate de un utilizator, client sau alte părți interesate”. (Microsoft Press)

Destul de ușor, nu? Nu chiar. În acest moment, m-aș întreba dacă aici se oprește definiția mea a criteriilor de acceptare. Pe lângă definiția de mai sus, orice proprietar de produs ar trebui să aibă răspunsuri pregătite pentru următoarele întrebări:

Cum arată aceste condiții? Cine creează aceste condiții? Câte condiții ar trebui să existe? Cum se măsoară rezultatele?

În general, criteriile de acceptare sunt inițiate de proprietarul sau de părțile interesate. Acestea sunt scrise înainte de orice dezvoltare a caracteristicii. Rolul lor este de a oferi linii directoare pentru o perspectivă centrată pe afaceri sau pe utilizator.

Cu toate acestea, scrierea criteriilor nu este doar responsabilitatea proprietarului produsului. Criteriile de acceptare ar trebui elaborate ca un efort comun între echipa de dezvoltare și proprietarul produsului.

Crearea împreună a acestor criterii ajută echipa de dezvoltare să înțeleagă dorința prezentată. De asemenea, ajută proprietarul produsului să prindă detaliile lipsă. În plus, proprietarul dobândește o mai bună înțelegere a fezabilității, complexității și domeniului de aplicare.

Criteriile de acceptare pentru scrierea criteriilor de acceptare
Imagine de Maryna Z. și Dmiriy G.

Formatarea criteriilor de acceptare

Criteriile pot fi scrise într-o varietate de formate. Majoritatea echipelor înclină spre două tipuri specifice: orientat spre reguli sau orientate spre scenarii.

Cerințele orientate către reguli sunt directe. Acestea enumeră rezultatele observabile. „Afișați soldul extrasului după autentificarea cu succes.”

Pe de altă parte, criteriile orientate către scenarii tind să urmeze șablonul „Dat … Când … Atunci …”. Aceasta a fost derivată din dezvoltarea bazată pe comportament (BDD). Această cerință prezintă rezultatul observabil așteptat. Acest lucru se întâmplă când se execută o anumită acțiune dat un anumit context.

3 caracteristici ale criteriilor efective de acceptare

1. Testabil cu rezultate clar aprobate / nereușite

Au criterii testabile. Acest lucru permite testerilor să confirme în mod corespunzător că toate condițiile dorite au fost îndeplinite. Dacă criteriile nu ar putea fi testate, atunci nu ar exista nicio modalitate de verificare. Aceste criterii ar trebui fie să fie îndeplinite, fie să nu fie îndeplinite. Un dezvoltator ar trebui să cunoască punctul în care a fost atins criteriul. Orice ambiguitate poate prelungi efortul asupra poveștii.

De exemplu, un criteriu de acceptare prevede „creșteți numărul de intrări disponibile într-un meniu derulant”. Dezvoltatorul nu ar avea nicio idee câte intrări noi trebuie adăugate și poate lua libertatea de a-și asuma un număr pe baza experienței sale cu produsul. La fel, un tester manual poate lua aceeași libertate și își poate asuma o definiție diferită de creștere. Acest lucru duce la o confuzie care va reveni la proprietarul produsului.

2. Neambigu și concis

Aici criteriile de acceptare a scrisului devin o artă. Eseurile academice subliniază importanța clarității și succintității. În mod similar, scrierea criteriilor de acceptare impune același nivel de organizare și îngrijire.

Asemănător cu scrierea unei piese literare, publicul trebuie avut în vedere. Cei care citesc criteriile de acceptare trebuie să înțeleagă ceea ce este scris. În caz contrar, aceste cuvinte sunt complet inutile. Dacă sunt lungi și pline de jargon, atunci punctele principale ale condițiilor subliniate pot să nu se întâlnească. Mulți oameni pot trece cu vederea detaliile esențiale într-o mare de cuvinte atunci când sunt apăsate pentru timp. Chiar și atunci când nu sunt apăsate pentru timp, mulți oameni pot trece cu ușurință peste blurbs lungi.

În loc să pună vina pe lipsa de lectură atentă a altora, se pot prezenta proactiv criterii de acceptare ușor de citit, direct la obiect și lipsite de detalii inutile.

3. Stabiliți o înțelegere comună

Aceasta este probabil cea mai importantă caracteristică și cea mai luată ca atare. Dacă toți membrii echipei nu sunt pe aceeași pagină, atunci procesul și productivitatea sunt periclitate. Având echipa de dezvoltare să revizuiască criteriile de acceptare înainte de a continua cu povestea, minimizează confuzia. Ar trebui făcute clarificări cu privire la criterii, iar criteriile ar trebui actualizate în consecință.

Am avut experiențe în care toți membrii echipei au făcut parte din criteriile de acceptare a scrierii. A permis tuturor să înțeleagă toate părțile poveștii. De asemenea, le-a oferit membrilor echipei oportunități de a chime cu întrebări și idei. Cu toate acestea, un astfel de proces ar putea să nu fie întotdeauna ideal, în special pentru echipele mai mari.

Cu toate acestea, este important ca fiecare membru să poată citi criteriile de acceptare. De acolo, fiecare membru ar trebui să înțeleagă cum să aducă povestea în final. Indiferent dacă este în dezvoltare sau testare.

1611938648 722 Criteriile de acceptare pentru scrierea criteriilor de acceptare

Când prea mult este o problemă

Am explorat deja pericolul unor criterii de acceptare neclare. Acest lucru duce la riscul introducerii unor caracteristici străine într-o poveste. Cu toate acestea, poate exista și cazul opus surprinzător: criteriile de acceptare pot deveni prea detaliate.

„Criteriile de acceptare trebuie să menționeze intenția, nu o soluție” (Segue Technologies)

Furnizați un plan de „ce” (intenție) în loc de „cum” (implementare). În caz contrar, echipei de dezvoltare i se poate priva posibilitatea de a explora diferite modalități de a rezolva problema. Pe aceste linii, implementări mai bune pot fi gândite după gândurile inițiale privind o soluție.

După ce ați scris criteriile de acceptare, vă puteți întreba: „Câți sunt prea mulți?”
Am văzut povești care variază de la zero criterii de acceptare la peste cincisprezece (sau cel puțin s-a simțit așa).

De regulă, personal îmi place să văd trei până la opt criterii de acceptare pe poveste. Cu toate acestea, spre capătul superior al acestei limite, aproximativ cinci sau mai multe criterii de acceptare, aș verifica gestionabilitatea. Aș verifica cu atenție pentru a vedea dacă povestea nu poate fi împărțită în povești mai mici și mai ușor de gestionat.

Alții nu ar fi de acord și susțin că opt ar fi deja prea mulți. Cu toate acestea, îmi place să mă aplec spre a oferi cât mai multe detalii „ce” pot, fără a sacrifica concizia.

Acum ce?

Ok, am mințit. Nu am furnizat o listă exhaustivă a criteriilor de acceptare pentru scrierea criteriilor de acceptare. Caracteristicile dorite precum concizia, claritatea și înțelegerea sunt subiective. Am intenționat să fie.

Cred că nu există un format „corect” pentru criteriile de acceptare a scrierii. Corectitudinea lor este măsurată de eficiența în echipa cuiva.

Vă recomand cu tărie să utilizați inițial un șablon. Au oferit multor echipe o structură solidă și sigură care promovează scrierea unor criterii de acceptare bune. Cu toate acestea, nu lăsați această structură să vă împiedice să avansați în idei care pot promova eficiența și eficacitatea.

Dacă sunteți proprietarul unui produs sau un client care scrie criterii de acceptare, vă provoc să solicitați feedback echipei dvs. de dezvoltare cu privire la criteriile actuale de acceptare. Cu un pic de grijă, practică și organizare, elaborarea unor criterii de acceptare eficiente devine un instrument puternic în îmbunătățirea fluxului de lucru al oricărei echipe.

Mai multe de citit