Læsning tid: 7 minutter

Succes for ethvert projekt, afhænger muligheden for en udvikling team til at opfylde deres kunders behov. Kommunikationen mellem kunden og udviklingsteamet spiller en afgørende rolle i at levere en løsning, der passer til produkt-og markedskrav., Problemerne opstår, hvis kunderne forklarer deres behov for vagt, og teamet ikke kan forstå klare krav og til sidst forretningsproblemet bag dem. Forestil dig, at du beder dit team om at give brugerne mulighed for at søge efter et produkt i en online boghandel efter kategorier. Du forventer at have en klar grænseflade med Kategori links til at klikke på dem (f.eks fantasy, non-fiction, historisk, etc.) Efter to ugers udvikling modtager du en søgefeltfunktion, hvor brugerne skal indtaste den kategori, de er interesseret i, i stedet for at gennemse forudlistede kategorier., Selvom dette også fungerer, var dit oprindelige mål at afsløre alle tilgængelige kategorier og lade brugerne udforske yderligere.

Dette er, når soft .aredokumentation af høj kvalitet kan hjælpe med at undgå problemet. Brugerhistorier og acceptkriterier (AC) som de vigtigste formater for dokumenteringskrav. En brugerhistorie er en naturlig sprogbeskrivelse af en funktion. Det er normalt ledsaget af acceptkriterier.

acceptkriterier (AC) er de betingelser, som et Soft .areprodukt skal opfylde for at blive accepteret af en bruger, en kunde eller et andet system., De er unikke for hver bruger historie og definere funktionen adfærd fra slutbrugerens perspektiv. Velskrevne acceptkriterier hjælper med at undgå uventede resultater i slutningen af et udviklingsstadium og sikre, at alle interessenter og brugere er tilfredse med det, de får.

Accept kriterier er det laveste niveau funktionelle krav

Accept kriterier vigtigste formål

Afklaring af interessenternes krav er et højt mål. For at gøre AC ‘ s formål klarere, lad os bryde dem ned.,

Funktionsomfang detalisering. AC definerer grænserne for brugerhistorier. De giver præcise detaljer om funktionalitet, der hjælper teamet med at forstå, om historien er afsluttet og fungerer som forventet.

beskriver negative scenarier. Yor AC kan kræve, at systemet genkender usikre adgangskodeindgange og forhindrer en bruger i at fortsætte videre. Ugyldigt adgangskodeformat er et eksempel på et såkaldt negativt scenarie, når en bruger foretager ugyldige input eller opfører sig uventet. AC definerer disse scenarier og forklarer, hvordan systemet skal reagere på dem.

Indstilling af kommunikation., Acceptkriterier synkroniserer visionerne for klienten og udviklingsteamet. De sikrer, at alle har en fælles forståelse af kravene: udviklere ved nøjagtigt, hvilken slags adfærd funktionen skal demonstrere, mens interessenter og klienten forstår, hvad der forventes af funktionen.

strømlining accept test. AC er grundlaget for test af brugerhistoriens accept. Hvert acceptkriterium skal være uafhængigt testbart og således have et klart bestået eller mislykket scenario. De kan også bruges til at verificere historien via automatiserede test.

funktion estimering., Acceptkriterier angiver, hvad der nøjagtigt skal udvikles af teamet. Når teamet har præcise krav, kan de opdele brugerhistorier i opgaver, der kan estimeres korrekt.

acceptkriterier typer og strukturer

AC kan skrives i forskellige formater. Der er to mest almindelige, og den tredje mulighed er at udarbejde din egen format:

• scenario-orienterede (Da/Da/Da)
• regel-orienteret (checkliste)
• brugerdefinerede formater

Som den første og den anden formater har meget specifikke strukturer, vil vi primært fokusere på dem., Du kan dog opleve, at andre formater passer bedre til dit produkt, så vi vil også kort berøre dem.

Scenarieorienterede acceptkriterier

Scenarieorienteret format for at skrive AC er kendt som den givne/hvornår / derefter (G .t) type.

• Får nogle forudsætning
• Hvornår jeg gøre nogle handling
• Så jeg forventer et resultat

Denne tilgang var arvet fra behavior-driven development (BDD) og giver en ensartet struktur, der hjælper med testere definere, hvornår man skal begynde og ende afprøvning af en bestemt funktion., Det reducerer også den tid, der bruges på at skrive testcases, da systemets opførsel beskrives på forhånd.,

Hver accept kriterier, der er skrevet i dette format har følgende udsagn:

1. Scenario – navnet for den adfærd, der vil blive beskrevet
2. i Betragtning – begyndelsen tilstand af scenariet
3. Hvornår specifikke handlinger, som brugeren gør
4. Så – resultatet af handling i “Da”
5. Og – bruges til at fortsætte nogen af de tre foregående redegørelser

Når det kombineres disse udsagn omfatter alle handlinger, som en bruger tager for at fuldføre en opgave, og oplever udfald.

lad os se på nogle eksempler.,eksempel 1

brugerhistorie: som bruger vil jeg være i stand til at gendanne adgangskoden til min konto, så jeg kan få adgang til min konto, hvis jeg har glemt adgangskoden.,igated til login-side

Når: Den valgte bruger glemt adgangskode

Og: Indtastet en gyldig e-mail for at modtage et link til gendannelse af adgangskode

Så: systemet har sendt link til den indtastede e-mail

i Betragtning: brugeren har modtaget linket via e-mail

Når: Brugeren navigeres gennem de link, der er modtaget i e-mail

Så: systemet giver brugeren mulighed for at angive en ny adgangskode

Eksempel 2:

Bruger historie: Som en bruger, jeg ønsker at være i stand til at anmode om penge fra min konto i ATM, så jeg vil være i stand til at modtage penge fra min konto hurtigt og på forskellige steder.,låg

Og: dispenseren indeholder kontanter

Når: kunden anmoder om den kontante

Så: sikre konto debiteres

Og: sikre kontanter er doseret

Og: sørg for at kortet er vendt tilbage

Accept-kriterium 2:

i Betragtning: at kontoen overtrækkes

Og: kortet er gyldigt

Når: kunden anmoder om den kontante

Dernæst: sørg for afvisning meddelelse vises

Og: sikre kontanter er ikke udleveres

Regel-orienteret accept kriterier format

I nogle tilfælde, det er svært at passe accept kriterier, der i Givet/Når/Så-struktur., For eksempel ville g .t næppe være nyttigt i følgende tilfælde:

• du arbejder med brugerhistorier, der beskriver systemniveaufunktionaliteten, der har brug for andre metoder til kvalitetssikring.
• målgruppen for acceptkriterier har ikke brug for præcise detaljer om testscenarierne.
• g .t-scenarier passer ikke til at beskrive design-og brugeroplevelsesbegrænsninger for en funktion. Udviklere kan gå glip af en række kritiske detaljer.

Du kan løse disse sager med det regelorienterede AC-format.,

den regelorienterede form indebærer, at der er et sæt regler, der beskriver et systems adfærd. Baseret på disse regler kan du tegne specifikke scenarier.

normalt ser kriterier, der er sammensat ved hjælp af denne formular, ud som en simpel kugleliste. Lad os se på et eksempel.eksempel

brugerhistorie: som bruger vil jeg bruge et søgefelt til at skrive en by, navn eller gade, så jeg kunne finde matchende hotelindstillinger.,

grundlæggende kriterier for accept af søgegrænsefladen

• søgefeltet er placeret på øverste bjælke
• søgning Starter, når brugeren klikker på “Søg”
• feltet indeholder en pladsholder med en grå tekst: “hvor skal du hen?”
• Den pladsholder, der forsvinder, når brugeren begynder at skrive
• Søgning er udført, hvis en bruger typer i en by, hotel navn, en gade eller alle tilsammen
• Søgningen er i engelsk, fransk, tysk og ukrainsk
• brugeren kan ikke skrive mere end 200 symboler
• søg ikke støtte specielle symboler (bogstaver)., Hvis brugeren har indtastet et specielt symbol, skal du vise advarselsmeddelelsen: “Søgeindgang kan ikke indeholde specielle symboler .”

andre formater

de fleste brugerhistorier kan dækkes med to ovennævnte formater. Du kan dog opfinde dine egne acceptkriterier, da de tjener deres formål, er skrevet tydeligt på almindeligt engelsk og ikke kan fortolkes forkert. Nogle hold bruger endda almindelig tekst.,

nogle gange, dine kriterier kan angives som et eksempel på system adfærd:

Et simpelt sæt af AC for stærke adgangskoder af Mark Levison for agilepainpainrelief.com

Denne tilgang giver klare retningslinjer til adgangskode-funktion test.

roller ansvarlige og hvordan acceptkriterier oprettes

nogle af kriterierne er defineret og skrevet af produktejeren, når han eller hun opretter Product backlog. Og de andre kan specificeres yderligere af teamet under diskussioner om brugerhistorier efter sprintplanlægning., Der er ingen strenge anbefalinger til at vælge den person, der er ansvarlig for at skrive kriterierne. Kunden kan dokumentere dem, hvis han eller hun har rigelig teknisk og produkt dokumentation viden. I dette tilfælde forhandler klienten kriterierne med holdet for at undgå gensidige misforståelser. Ellers oprettes kriterierne af en produktejer, forretningsanalytiker, kravanalytiker eller en projektleder.,

processen starter med, at brugeren historie prioritering og ender med at forhandle detaljer med hele holdet

Største udfordringer og bedste praksis for at skrive accept kriterier

Accept kriterier ser ud som om de er meget nem at skrive. På trods af deres forenklede formater udgør skrivningen en udfordring for mange hold. Lad os få et dybere kig på den bedste praksis, der hjælper med at undgå almindelige fejl.

dokument kriterier før udvikling. Acceptkriterier skal dokumenteres, før den faktiske udvikling starter., På denne måde vil teamet sandsynligvis fange alle kundebehov på forhånd. I starten er det nok at indstille kriterierne for et lille antal brugerhistorier til at udfylde backlogs for to sprints (hvis du praktiserer Scrum eller en lignende metode). De skal aftales af begge parter. Derefter bruges de dokumenterede acceptkriterier af udviklere til at planlægge den tekniske proces.

lav ikke AC for smal. Acceptkriterier kan være alt for specifikke, der lever lidt til ingen manøvreringsmuligheder for udviklere. For at undgå dette skal du huske, at AC skal formidle hensigten, men ikke en endelig løsning., Desuden kan smal AC være berøvet flere brugeradfærd, der ikke er dækket.

Hold dine kriterier opnåelige. Dette punkt skærer tæt sammen med den forrige. Effektive acceptkriterier definerer det rimelige minimum af funktionalitet, som du er i stand til at levere. Men hvis du bukker under for at beskrive alle små detaljer, er der risiko for, at dit team sidder fast med hundredvis af små opgaver.

hold AC målbar og ikke for bred. Brede acceptkriterier gør en brugerhistorie vag., Effektive acceptkriterier skal skitsere arbejdsomfanget, så udviklerne kan planlægge og estimere deres indsats korrekt.

undgå tekniske detaljer. Som vi nævnte, skal acceptkriterier skrives på almindeligt engelsk. Dette vil gøre dem klare og lette at forstå for alle: dine interessenter eller ledere har muligvis ikke teknisk baggrund.

nå konsensus. Det samme problem kan løses forskelligt af et team og interessenter, afhængigt af deres udsigtspunkter. Sørg for, at du har kommunikeret din AC til interessenter og nået en gensidig aftale., Det samme gælder for teammedlemmer. Alle skal gennemgå AC og bekræfte, at de forstår og er enige med hver linje.

skriv testbar AC. Dette giver testere mulighed for at kontrollere, at alle krav var opfyldt. Ellers forstår udviklere ikke, om brugerhistorien er afsluttet.

sidste ord

Undlad at forsømme acceptkriterierne, da de – at være enkle og tilgængelige – løser flere problemer på .n gang., De dokumenterer kundens forventninger, giver et slutbrugerperspektiv, afklarer krav og forhindrer tvetydighed og hjælper til sidst kvalitetssikring med at verificere, om udviklingsmålene blev opfyldt. Uanset om du bruger Agile metoder eller ej, skal du sørge for at vælge det bedste format eller eksperimentere med dine egne. Forskellige typer af brugerhistorier og i sidste ende funktioner kan kræve forskellige fromats og teste de nye, der arbejder for dig er en god praksis.