Acceptkriterierne for skrivning af acceptkriterier

Acceptkriterierne for skrivning af acceptkriterier

Mange udviklingsteam er for bekendt med frustrationerne ved utilfredsstillende acceptkriterier eller endda manglen på kriterier i sig selv. At definere ingen krav er som at forberede sig på kamp uden en handlingsplan - holdet har taget flere skridt mod fiasko end succes. Jeg tilbyder specifikke forslag til udformning af acceptkriterier, der kan forbedre enhver smidig proces.

Lad os først definere acceptkriterier.

Acceptkriterier er de "betingelser, som et softwareprodukt skal opfylde for at blive accepteret af en bruger, kunde eller andre interessenter." (Microsoft Press)

Let nok, ikke? Ikke helt. På dette tidspunkt vil jeg spørge mig selv, om det er her min definition af acceptkriterier stopper. Ud over definitionen ovenfor bør enhver produktejer have svar klar til følgende spørgsmål:

Hvordan ser disse forhold ud? Hvem skaber disse betingelser? Hvor mange betingelser skal der være? Hvordan måles resultaterne?

Generelt er acceptskriterier initieret af produktejeren eller interessenten. De er skrevet før enhver udvikling af funktionen. Deres rolle er at give retningslinjer for et forretnings- eller brugercentreret perspektiv.

Imidlertid er det ikke kun produktindehaverens ansvar at skrive kriterierne. Acceptkriterier bør udvikles som en fælles indsats mellem udviklingsteamet og produktejeren.

At udarbejde disse kriterier sammen hjælper udviklingsholdet med at forstå ønsket om ønsket. Det hjælper også produktejeren med at fange manglende detaljer. Derudover får ejeren en bedre forståelse af gennemførligheden, kompleksiteten og omfanget.

Formatering af acceptkriterier

Kriterier kan skrives i en række forskellige formater. De fleste hold læner sig mod to specifikke typer: regelorienteret eller scenarieorienteret .

Regelorienterede krav er ligetil. De viser de observerbare resultater. "Vis kontosaldo ved vellykket godkendelse."

På den anden side har scenarieorienterede kriterier tendens til at følge skabelonen "givet ... hvornår ... så ...". Dette stammer fra adfærd-drevet udvikling (BDD). Dette krav skitserer det forventede observerbare resultat. Dette sker, når en bestemt handling udføres i en vis sammenhæng.

3 karakteristika ved effektive acceptkriterier

1. Testes med klart definerede bestå / ikke-resultater

Har testbare kriterier. Dette giver testere mulighed for korrekt at bekræfte, at alle de ønskede betingelser er opfyldt. Hvis kriterier ikke kunne testes, ville der ikke være nogen måde at verificere. Disse kriterier skal enten være opfyldt eller ikke opfyldt. En udvikler skal kende det punkt, hvor kriteriet er nået. Enhver tvetydighed kan forlænge historiens indsats.

For eksempel angiver et acceptkriterium "øg antallet af tilgængelige poster i en rullemenu". Udvikleren ville ikke have nogen idé om, hvor mange nye poster der skal tilføjes, og kan tage friheden til at antage et nummer baseret på hans erfaring med produktet. Ligeledes kan en manuel tester tage den samme frihed og antage en anden definition af stigning. Dette resulterer i en forvirring, der vil cirkulere tilbage til produktejeren.

2. utvetydig og kortfattet

Dette er hvor skrivning af acceptkriterier bliver en kunst. Akademiske essays understreger vigtigheden af ​​klarhed og kortfattethed. Tilsvarende kræver skrivning af acceptkriterier det samme niveau af organisation og pleje.

I lighed med at skrive et litterært stykke skal publikum holdes for øje. De, der læser acceptkriterierne, skal forstå, hvad der er skrevet. Ellers er disse ord helt ubrugelige. Hvis de er langvarige og fyldte med jargon, kan hovedpunkterne i de skitserede forhold muligvis ikke komme på tværs. Mange mennesker kan overse vigtige detaljer i et hav af ord, når de presses til tiden. Selv når de ikke trykkes i tide, kan mange mennesker let glansere over lange uskarphed.

I stedet for at lægge skylden på andres mangel på omhyggelig læsning, kan man proaktivt præsentere acceptkriterier, der er lette at læse, lige til sagen og blottet for overflødige detaljer.

3. Etabler fælles forståelse

Dette er sandsynligvis den vigtigste egenskab og den mest taget for givet. Hvis alle medlemmerne af teamet ikke er på samme side, bringes proces og produktivitet i fare. At have udviklingsteamet til at gennemgå acceptkriterier, inden vi går videre med historien, minimerer forvirring. Afklaring bør foretages om kriterierne, og kriterierne bør opdateres i overensstemmelse hermed.

Jeg har haft erfaringer, hvor alle teammedlemmer har været med til at skrive acceptkriterier. Det tillod alle at forstå alle dele af historien. Det gav også muligheder for teammedlemmer til at ringe ind med spørgsmål og ideer. En sådan proces er dog ikke altid ideel, især for større hold.

Ikke desto mindre er det vigtigt, at hvert medlem kan læse acceptkriterierne. Derefter skal hvert medlem få en forståelse af, hvordan historien afsluttes. Uanset om det er under udvikling eller test.

Når for meget er et problem

Vi har allerede undersøgt faren for uklare acceptkriterier. Dette resulterer i risikoen for at introducere fremmede funktioner i en historie. Imidlertid kan det overraskende modsatte tilfælde også eksistere: acceptskriterier kan blive for detaljerede.

"Acceptkriterier skal angive hensigt, ikke en løsning" ( Segue Technologies )

Giv en plan for "hvad" (intention) i stedet for "hvordan" (implementering). Ellers kan udviklingsteamet fratages muligheden for at udforske forskellige måder at løse problemet på. På disse linjer kan bedre implementeringer blive tænkt op efter de indledende tanker om en løsning.

Når du har skrevet dine acceptkriterier, kan du spørge dig selv: "Hvor mange er for mange?"

Jeg har set historier, der spænder fra nul acceptkriterier til mere end femten (eller i det mindste føltes det sådan).

Som en tommelfingerregel kan jeg personligt se tre til otte acceptkriterier pr. Historie. Imidlertid ville jeg kontrollere håndterbarheden mod den øvre ende af denne grænse omkring fem eller flere acceptkriterier. Jeg kontrollerede omhyggeligt for at se, at historien ikke kunne opdeles i mindre, mere håndterbare historier.

Andre ville være uenige og hævde, at otte allerede ville være for mange. Jeg kan dog lide at læne mig mod at give så meget "hvad" detaljer som jeg kan uden at ofre koncisitet.

Hvad nu?

Ok, jeg løj. Jeg leverede ikke en udtømmende liste over acceptkriterier til skrivning af acceptkriterier. De ønskede egenskaber som kortfattethed, klarhed og forståelse er subjektive. Jeg tænkte, at de skulle være.

Jeg mener, at der ikke er noget "korrekt" format til at skrive acceptkriterier. Deres rigtighed måles ved effektiviteten i ens team.

Jeg kan varmt anbefale oprindeligt at bruge en skabelon. De har forsynet mange hold med en solid og sikker struktur, der fremmer skrivning af gode acceptkriterier. Men lad ikke denne struktur forhindre dig i at komme videre til ideer, der kan fremme effektivitet og effektivitet.

Hvis du er en produktejer eller klient, der skriver acceptkriterier, udfordrer jeg dig til at bede dit udviklingsteam om feedback på de nuværende acceptkriterier. Med lidt omhu, praksis og organisering bliver udformning af effektive acceptkriterier et stærkt værktøj til forbedring af ethvert teams arbejdsgang.

Mere at læse

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