Pieņemšanas kritēriji rakstīšanas pieņemšanas kritērijiem

Pieņemšanas kritēriji rakstīšanas pieņemšanas kritērijiem

Daudzām izstrādātāju komandām ir pārāk zināma neapmierinātība par neapmierinošiem pieņemšanas kritērijiem vai pat pats kritēriju trūkums. Prasību nenoteikšana ir tāda pati kā gatavošanās kaujai bez rīcības plāna - komanda ir spērusi vairāk soļu pretī neveiksmei nekā panākumiem. Es piedāvāju konkrētus ieteikumus, izstrādājot pieņemšanas kritērijus, kas var uzlabot jebkuru veiklu procesu.

Pirmkārt, ātri definēsim pieņemšanas kritērijus.

Pieņemšanas kritēriji ir “nosacījumi, kuriem programmatūras produktam jāatbilst, lai lietotājs, klients vai citas ieinteresētās personas to akceptētu”. (Microsoft Press)

Pietiekami viegli, vai ne? Ne īsti. Šajā brīdī es sev jautātu, vai šeit apstājas mana pieņemšanas kritēriju definīcija. Papildus iepriekšējai definīcijai jebkura produkta īpašniekam ir jābūt gatavām atbildēm uz šādiem jautājumiem:

Kā izskatās šie apstākļi? Kas rada šos apstākļus? Cik apstākļiem jābūt? Kā tiek mērīti rezultāti?

Parasti pieņemšanas kritērijus ierosina produkta īpašnieks vai ieinteresētā persona. Tie ir uzrakstīti pirms jebkādas funkcijas izstrādes. Viņu uzdevums ir sniegt vadlīnijas uz uzņēmējdarbību vai uz lietotāju vērstai perspektīvai.

Tomēr par kritēriju rakstīšanu nav atbildīgs tikai produkta īpašnieks. Pieņemšanas kritēriji būtu jāizstrādā kā kopīgs darbs starp izstrādes komandu un produkta īpašnieku.

Izstrādājot šos kritērijus kopā, izstrādes komanda var saprast vēlmi. Tas arī palīdz produkta īpašniekam noķert trūkstošās detaļas. Turklāt īpašnieks gūst labāku izpratni par iespējamību, sarežģītību un darbības jomu.

Pieņemšanas kritēriju formatēšana

Kritērijus var rakstīt dažādos formātos. Lielākā daļa komandu orientējas uz diviem specifiskiem veidiem: uz noteikumiem vai scenārijiem .

Uz noteikumiem orientētas prasības ir tiešas. Viņi uzskaita novērojamos rezultātus. “Parādiet pārskata bilanci pēc veiksmīgas autentifikācijas.

No otras puses, uz scenārijiem orientētiem kritērijiem ir tendence sekot veidnei “Ņemot vērā ... Kad ... Tad ...”. Tas tika iegūts no uzvedības virzītas attīstības (BDD). Šī prasība iezīmē gaidāmo novērojamo rezultātu. Tas notiek, kad konkrēta darbība tiek izpildīta, ņemot vērā kādu kontekstu.

3 faktisko pieņemšanas kritēriju raksturojums

1. Pārbaudāms ar skaidri definētiem izturēšanas / neizturēšanas rezultātiem

Ir pārbaudāmi kritēriji. Tas testētājiem ļauj pareizi apstiprināt, ka ir izpildīti visi vēlamie nosacījumi. Ja kritēriji nebūtu pārbaudāmi, tad pārbaudei nebūtu iespēju. Šiem kritērijiem vajadzētu būt vai nu izpildītiem, vai arī neatbilstot. Izstrādātājam būtu jāzina, kurā brīdī kritērijs ir sasniegts. Jebkura neskaidrība var pagarināt centienus stāstā.

Piemēram, pieņemšanas kritērijā ir teikts “palielināt nolaižamajā izvēlnē pieejamo ierakstu skaitu”. Izstrādātājam nebūtu ne mazākās nojausmas, cik daudz jaunu ierakstu ir jāpievieno, un, ņemot vērā viņa pieredzi ar produktu, viņš var brīvi pieņemt numuru. Tāpat manuāls testeris var izmantot to pašu brīvību un pieņemt atšķirīgu pieauguma definīciju. Tā rezultātā rodas neskaidrības, kas atgriezīsies pie produkta īpašnieka.

2. Viennozīmīgs un kodolīgs

Šeit pieņemšanas kritēriju rakstīšana kļūst par mākslu. Akadēmiskās esejas uzsver skaidrības un kodolīguma nozīmi. Tāpat pieņemšanas kritēriju rakstīšana nosaka tādu pašu organizācijas un aprūpes līmeni.

Līdzīgi kā rakstot literāru darbu, jāpatur prātā arī auditorija. Tiem, kas lasa pieņemšanas kritērijus, ir jāsaprot rakstītais. Pretējā gadījumā šie vārdi ir pilnīgi bezjēdzīgi. Ja tie ir ilgstoši un piepildīti ar žargonu, tad galvenie izklāstīto nosacījumu punkti var nebūt sastopami. Daudzi cilvēki var nepamanīt būtiskas detaļas vārdu jūrā, kad tiek piespiests laiks. Pat tad, ja tas nav nospiests uz laiku, daudzi cilvēki var viegli iemirdzēties garos izplūdumos.

Tā vietā, lai vainotu citu uzmanīgas lasīšanas trūkumu, var proaktīvi uzrādīt pieņemamības kritērijus, kas ir viegli lasāmi, tieši līdz lietai un bez liekām detaļām.

3. Ieviesiet kopīgu izpratni

Tas, iespējams, ir vissvarīgākā īpašība, un tā ir pašsaprotama. Ja visi komandas locekļi neatrodas vienā lapā, process un produktivitāte tiek apdraudēta. Ja izstrādes komanda pirms stāšanās uz priekšu pārskata pieņemšanas kritērijus, mazina neskaidrības. Būtu jāprecizē kritēriji, un kritēriji attiecīgi jāatjaunina.

Man ir bijusi pieredze, kad visi komandas locekļi ir piedalījušies, rakstot pieņemšanas kritērijus. Tas ļāva visiem saprast visas stāsta daļas. Tas arī nodrošināja komandas locekļiem iespēju uzdot jautājumus un idejas. Tomēr šāds process ne vienmēr var būt ideāls, it īpaši lielākām komandām.

Tomēr ir svarīgi, lai katrs dalībnieks varētu izlasīt pieņemšanas kritērijus. No turienes katram dalībniekam vajadzētu iegūt izpratni par to, kā stāstu pabeigt. Neatkarīgi no tā, vai tas tiek izstrādāts vai testēts.

Kad jautājums ir par daudz

Mēs jau esam izpētījuši neskaidru pieņemšanas kritēriju bīstamību. Tā rezultātā pastāv risks, ka stāstā tiek ieviestas svešas pazīmes. Tomēr var būt arī pārsteidzoši pretējs gadījums: pieņemšanas kritēriji var kļūt pārāk detalizēti.

“Pieņemšanas kritērijos jānorāda nodoms, nevis risinājums” ( Segue Technologies )

Norādiet “kas” (nodoms), nevis “kā” (ieviešana) plānu. Pretējā gadījumā izstrādes komandai var tikt laupīta iespēja izpētīt dažādus problēmas risināšanas veidus. Šajās līnijās labākas ieviešanas iespējas var tikt izdomātas pēc sākotnējām domām par risinājumu.

Kad esat uzrakstījis pieņemšanas kritērijus, varat sev uzdot jautājumu: "Cik daudz ir par daudz?"

Esmu redzējis stāstus, kas svārstās no nulles pieņemšanas kritērijiem līdz vairāk nekā piecpadsmit (vai vismaz tā jutās).

Parasti es personīgi vēlētos redzēt trīs līdz astoņus pieņemšanas kritērijus katram stāstam. Tomēr, tuvojoties šīs robežas augšējai daļai, aptuveni pieciem vai vairāk pieņemšanas kritērijiem, es pārbaudītu vadāmību. Es uzmanīgi pārbaudītu, vai stāstu nevar sadalīt mazākos, vieglāk pārvaldāmos stāstos.

Citi nepiekristu un apgalvotu, ka astoņu jau būtu par daudz. Tomēr man patīk nosvērties, lai sniegtu pēc iespējas vairāk “ko” detaļu, nezaudējot lakonismu.

Ko tagad?

Labi, es meloju. Es nesniedzu izsmeļošu pieņemšanas kritēriju sarakstu, lai rakstītu pieņemšanas kritērijus. Vēlamās īpašības, piemēram, kodolīgums, skaidrība un izpratne, ir subjektīvas. Es tos biju iecerējis.

Es uzskatu, ka nav “pareiza” formāta, lai rakstītu pieņemšanas kritērijus. Viņu pareizību mēra pēc efektivitātes vienā komandā.

Es ļoti iesaku sākotnēji izmantot veidni. Viņi daudzām komandām ir nodrošinājuši stabilu un drošu struktūru, kas veicina labu pieņemšanas kritēriju rakstīšanu. Tomēr neļaujiet šai struktūrai atturēt jūs virzīties uz idejām, kas var veicināt efektivitāti un lietderību.

Ja esat produkta īpašnieks vai klients, kurš raksta pieņemšanas kritērijus, es izaicinu jūs lūgt izstrādātāju komandu sniegt atsauksmes par pašreizējiem pieņemšanas kritērijiem. Ar nelielu rūpību, praksi un organizāciju efektīvu pieņemšanas kritēriju izstrāde kļūst par spēcīgu instrumentu jebkuras komandas darbplūsmas uzlabošanā.

Vairāk lasāms

  • //rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important - autori Maryna Z. un Dmiriy G.
  • //www.leadingagile.com/2014/09/acceptance-criteria/ Autors: Stīvs Povilaitis
  • //www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/, autors: Segue Technologies
  • //agileforgrowth.com/blog/acceptance-criteria-checklist/ - autore Kamleja Ravlani