Kriteriji prihvaćanja za pisanje kriterija prihvaćanja

Kriteriji prihvaćanja za pisanje kriterija prihvaćanja

Mnogi razvojni timovi previše su upoznati s frustracijama nezadovoljavajućih kriterija prihvaćanja ili čak i samog nedostatka kriterija. Definiranje nikakvih zahtjeva je poput pripreme za bitku bez plana akcije - tim je poduzeo više koraka prema neuspjehu nego uspjehu. Nudim konkretne prijedloge za izradu kriterija prihvaćanja koji mogu poboljšati svaki okretan postupak.

Prvo, definirajmo brzo kriterije prihvaćanja.

Kriteriji prihvaćanja su "uvjeti koje softverski proizvod mora zadovoljiti da bi ih korisnik, kupac ili druge zainteresirane strane prihvatio." (Microsoft Press)

Dovoljno jednostavno, zar ne? Ne baš. U ovom bih se trenutku zapitao je li ovdje mjesto moje definicije kriterija prihvaćanja. Uz gornju definiciju, svaki vlasnik proizvoda trebao bi imati odgovore na sljedeća pitanja:

Kako izgledaju ti uvjeti? Tko stvara ove uvjete? Koliko uvjeta treba biti? Kako se mjere ishodi?

Općenito, kriterije prihvaćanja pokreće vlasnik proizvoda ili dionik. Napisani su prije bilo kakvog razvoja značajke. Njihova je uloga pružiti smjernice za poslovnu perspektivu ili perspektivu usmjerenu na korisnika.

Međutim, pisanje kriterija nije isključivo odgovornost vlasnika proizvoda. Kriteriji prihvatljivosti trebaju se razviti kao zajednički napor razvojnog tima i vlasnika proizvoda.

Zajednička izrada ovih kriterija pomaže razvojnom timu da shvati istaknutu želju. Također pomaže vlasniku proizvoda da uhvati detalje koji nedostaju. Uz to, vlasnik stječe bolje razumijevanje izvedivosti, složenosti i opsega.

Oblikovanje kriterija prihvaćanja

Kriteriji se mogu pisati u raznim formatima. Većina timova naginje prema dvije specifične vrste: orijentirane na pravila ili scenarije .

Zahtjevi usmjereni prema pravilima izravni su prema naprijed. Oni navode vidljive ishode. "Prikaži saldo izvoda nakon uspješne provjere autentičnosti."

S druge strane, kriteriji orijentirani na scenarij imaju tendenciju da slijede predložak "Dano ... Kad ... Tada ..." To je izvedeno iz razvoja usmjerenog na ponašanje (BDD). Ovaj zahtjev opisuje očekivani vidljivi rezultat. To se događa kada se određena radnja izvrši s obzirom na neki kontekst.

3 obilježja učinkovitih kriterija prihvaćanja

1. Testibilno s jasno definiranim rezultatima prolaska / neuspjeha

Imati provjerljive kriterije. To omogućava testerima da pravilno potvrde da su ispunjeni svi željeni uvjeti. Da kriteriji nisu provjerljivi, tada ne bi bilo načina za provjeru. Ti bi kriteriji trebali biti zadovoljeni ili ne. Programer bi trebao znati u kojoj je točki kriterij postignut. Svaka nejasnoća može produljiti napor u priči.

Na primjer, kriterij prihvaćanja glasi "povećati broj unosa dostupnih u padajućem izborniku". Programer ne bi imao pojma koliko novih unosa može dodati i može si uzeti slobodu da preuzme broj na temelju svog iskustva s proizvodom. Isto tako, ručni ispitivač može uzeti istu slobodu i pretpostaviti drugačiju definiciju povećanja. To rezultira zbrkom koja će kružiti natrag do vlasnika proizvoda.

2. Jednoznačno i jezgrovito

Tu kriteriji prihvaćanja pisanja postaju umjetnost. Akademski eseji ističu važnost jasnoće i sažetosti. Slično tome, pisanje kriterija prihvaćanja zahtijeva istu razinu organizacije i njege.

Slično pisanju književnog djela, publika se mora imati na umu. Oni koji čitaju kriterije prihvaćanja moraju razumjeti napisano. Inače su te riječi potpuno beskorisne. Ako su dugovječni i ispunjeni žargonom, možda se glavne točke opisanih uvjeta neće naići. Mnogi ljudi mogu previdjeti bitne detalje u moru riječi kad ih pritisne vrijeme. Čak i kad ih se ne pritisne na vrijeme, mnogi ljudi lako mogu zamagliti dugačke blurbove.

Umjesto da krivnju stavljamo na nedostatak pažljivog čitanja drugih, možemo proaktivno predstaviti kriterije prihvaćanja koji se lako čitaju, izravno do točke i bez suvišnih detalja.

3. Uspostavite zajedničko razumijevanje

To je vjerojatno najvažnija karakteristika i ona koja se najviše uzima zdravo za gotovo. Ako svi članovi tima nisu na istoj stranici, tada proces i produktivnost postaju ugroženi. Ako razvojni tim preispita kriterije prihvaćanja prije nego što krene naprijed s pričom, smanjuje zbrku. Treba pojasniti kriterije i kriterije ažurirati u skladu s tim.

Doživio sam iskustva u kojima su svi članovi tima bili dio pisanja kriterija prihvaćanja. Svima je omogućilo da razumiju sve dijelove priče. Također je pružio mogućnosti članovima tima da se preobraze s pitanjima i idejama. Međutim, takav postupak ne mora uvijek biti idealan, posebno za veće timove.

Ipak, važno je da svaki član može pročitati kriterije prihvaćanja. Odatle bi svaki član trebao steći razumijevanje kako priču dovršiti. Bez obzira je li to u razvoju ili testiranju.

Kad je previše problem

Već smo istražili opasnost od nejasnih kriterija prihvaćanja. To rezultira rizikom od uvođenja stranih značajki u priču. Međutim, može postojati i iznenađujući suprotan slučaj: kriteriji prihvaćanja mogu postati previše detaljni.

"Kriteriji prihvaćanja trebaju navoditi namjeru, a ne rješenje" ( Segue Technologies )

Navedite nacrt "što" (namjera) umjesto "kako" (provedba). Inače, razvojnom timu može se oduzeti prilika da istraži različite načine za rješavanje problema. Na tim se linijama mogu smisliti bolje implementacije nakon početnih razmišljanja o rješenju.

Nakon što napišete kriterije prihvaćanja, možete se zapitati: "Koliko je previše?"

Vidio sam priče koje se kreću od nula kriterija prihvaćanja do više od petnaest (ili se barem tako osjećalo).

U pravilu osobno volim vidjeti tri do osam kriterija prihvaćanja po priči. Međutim, prema gornjem kraju te granice, oko pet ili više kriterija prihvaćanja, provjerio bih upravljivost. Pažljivo bih provjerio vidi li da se priča ne može podijeliti na manje, upravljivije priče.

Drugi se ne bi složili i tvrdili bi da bi ih osam već bilo previše. Međutim, volim se naginjati prema pružanju što više detalja "što" bez žrtvovanja sažetosti.

Što sad?

Ok, lagala sam. Nisam napisao iscrpan popis kriterija prihvaćanja za pisanje kriterija prihvaćanja. Željene karakteristike poput sažetosti, jasnoće i razumijevanja su subjektivne. Namjeravao sam da budu.

Vjerujem da ne postoji "ispravan" format za pisanje kriterija prihvaćanja. Njihova ispravnost mjeri se učinkovitošću nečijeg tima.

Toplo preporučujem da u početku koristite predložak. Oni su mnogim timovima pružili čvrstu i sigurnu strukturu koja promiče dobro pisanje kriterija prihvaćanja. Međutim, nemojte dopustiti da vas ta struktura sprečava u napredovanju u ideje koje mogu promicati učinkovitost i djelotvornost.

Ako ste vlasnik proizvoda ili klijent koji piše kriterije prihvaćanja, izazivam vas da zamolite svog razvojnog tima za povratne informacije o trenutnim kriterijima prihvaćanja. Uz malo brige, prakse i organizacije, izrada učinkovitih kriterija prihvaćanja postaje moćan alat za poboljšanje tijeka rada bilo kojeg tima.

Više za čitanje

  • //rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important - Maryna Z. i Dmiriy G.
  • //www.leadingagile.com/2014/09/acceptance-criteria/, autor Steve Povilaitis
  • //www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ by Segue Technologies
  • //agileforgrowth.com/blog/acceptance-criteria-checklist/ - autor Kamlesh Ravlani