Šta su Acceptance Criteria — zašto su važni i kako da ih napišete kako treba?
Znate onaj trenutak kada user story deluje kao da je gotov — ali tester se ne slaže, a Product Owner nije siguran?
Tu na scenu stupaju Acceptance Criteria. Ako ste ikada radili u softverskom ili product timu, verovatno ste čuli za njih — te male stavke koje odlučuju da li je user story zaista „done“ ili je i dalje u zoni „skoro pa gotovo“.
Ali šta su zapravo Acceptance Criteria, zašto su važni i kako napisati dobre?
Šta su Acceptance Criteria i ko ih piše?
Najjednostavnije rečeno, Acceptance Criteria (AC) su uslovi po kojima Product Owner proverava da li funkcionalnost radi kako treba. Preciznije, to je skup jasnih i konkretnih uslova koje user story ili feature mora da ispuni da bi bio prihvaćen kao završen.
Zamislite ih kao checklist-u za uspeh — govore vam šta treba da radi, kako treba da izgleda ili da se ponaša da biste mogli da kažete: „Da, ovo je gotovo.“
Najčešće ih piše Product Owner, uz input tima — developera, testera i dizajnera — kako bi bili realni i testabilni.
Idealno je da se definišu pre početka razvoja, najkasnije kada je user story spreman za sprint planning. Tako tim radi sa jasnoćom i sigurnošću.
Zašto su Acceptance Criteria važni?
Acceptance Criteria nisu samo dokumentacija — oni su lepak koji drži zajedničko razumevanje tima.
Jasnoća
Svi znaju šta „done“ zaista znači — bez nagađanja i rasprava.
Kvalitet
Vode developere i testere ka tačno onome što treba da se izgradi.
Fokus
Drže tim usmeren na potrebe korisnika i očekivanja.
Lakša isporuka
Manje iznenađenja pred kraj sprinta ili release-a.
Bolje estimacije
Jasni kriterijumi olakšavaju procenu kompleksnosti i truda.
Ukratko — pomažu da Agile proces zaista ostane agilan.
Karakteristike dobrih Acceptance Criteria
Dobri AC su kao dobra komunikacija: kratki, jasni i konkretni.
Trebalo bi da budu:
Razumljivi – napisani jednostavnim jezikom
Jasni i sažeti – bez prostora za pogrešno tumačenje
Testabilni – moguće ih je proveriti sa da/ne
Relevantni – vezani za vrednost koju story donosi
Merljivi – opisuju ponašanje koje se može proveriti
Najčešće greške (i kako ih izbeći)
I iskusni timovi upadaju u ove zamke.
| Previše nejasni „Korisnik može lako da resetuje lozinku.“ Kako testirati „lako“? | Bolje: „Kada korisnik klikne na ‘Reset your password’, stara lozinka se poništava i generiše se nova.“ |
| Previše kriterijuma u jednom story-ju Preopterećen story vodi u konfuziju. | Bolje: Razbijte kompleksne story-je na manje. |
| Pisanje kriterijuma prekasno Ako ih pišete na kraju razvoja — kasno je. | Bolje: Definišite ih tokom refinement-a ili sprint planning-a. |
| Samo tehnički kriterijumi Bez korisničke perspektive story gubi vrednost. | Bolje: Uključite kriterijume koji odražavaju potrebe korisnika i biznis ciljeve. |
Primer Acceptance Criteria
User story:
Kao korisnik, kada zaboravim lozinku, želim da je resetujem kako bih ponovo pristupio nalogu.
Acceptance Criteria:
- Kada korisnik unese pogrešnu lozinku i ne može da se uloguje, može pokrenuti reset klikom na „Reset your password“.
- Nakon klika, korisnik dobija email za reset u roku od 5 minuta.
- Korisnik ne može poslati novi zahtev za reset u roku od 5 minuta.
- Link za reset ističe nakon 24 sata.
- Link vodi na stranicu za unos nove lozinke.
- Nova lozinka mora imati najmanje 8 karaktera i sadržati broj.
- Nakon resetovanja, korisnik može odmah da se uloguje novom lozinkom.
Zaključak
Acceptance Criteria su najbolji prijatelji Agile isporuke.
Drže sve na istoj strani, podižu kvalitet i osiguravaju da gradite ono što korisnicima zaista treba.
Ako želite da se oprostite od nejasnih story-ja i naučite kako da pišete jasne, testabilne i korisnički orijentisane kriterijume — možemo da pomognemo.
Javite se kada budete spremni.