Sådan skriver du acceptkriterier: eksempler og bedste praksis

Her hos Mobindustry arbejder vi med en smidig tilgang. Det betyder, at vi bruger Agile komponenter som brugerhistorier og acceptkriterier. Højtydende teams og organisationer har disse komponenter i deres produkt backlogs, og de ved, hvordan man opretter dem og bruge dem effektivt.

Hvis dit produkt backlog mangler brugerhistorier og acceptkriterier — eller hvis de ikke er klart defineret — risikerer du, at dine forventninger ikke konvergerer med virkeligheden., Brugerhistorier og acceptkriterier er ansvarlige for at repræsentere, hvordan slutbrugeren vil bruge din app, og hvordan dit udviklingsteam skal udføre hver udviklingsopgave. Når vi begynder at arbejde på et nyt produkt, samarbejder vores team med klienten for at definere brugerhistorier.

en brugerhistorie er en kort, enkel beskrivelse af en produktfunktion set fra en person, der ønsker at bruge denne funktion. Brugerhistorier bruges til at definere product backlog i en agil udviklings workorkflo..,

product Backloggen er i det væsentlige en samling af brugerhistorier, der informerer funktionsspecifikationen og udviklingen af funktioner til et bestemt produkt eller en tjeneste. Brugerhistorier består af tre dele: en persona af brugeren historien bliver skrevet til, en beskrivelse af funktionen brugeren kræver, og en forklaring på behovet funktionen opfylder.

Sådan skriver du en brugerhistorie:

som bruger vil jeg have en (funktion), så jeg kan (tilfredsstille et behov).

lad os se på, hvordan en brugerhistorie kan se ud., Vi tager Airbnb som et eksempel. Lad os forestille os, hvordan en typisk brugerhistorie kan se efter et produkt som Airbnb.

“som bruger vil jeg søge efter en destination, så jeg kan booke indkvartering i en fremmed by.”

Definition af acceptkriterier

nu skal vi sørge for, at brugerhistorier udfyldes korrekt og imødekommer klientens krav.

acceptkriterier er de betingelser, som et Soft .areprodukt skal opfylde for at blive accepteret af en bruger, kunde eller, i tilfælde af systemniveaufunktionalitet, det forbrugende system.,

acceptkriterier er et sæt udsagn, hver med et klart bestået / mislykket resultat, der kan måles og specificere både funktionelle og ikke-funktionelle krav.

skrivning acceptkriterier er vigtigt ikke kun for at fastslå, hvad kunden forventer af produktet, men for udviklingsprocessen. Naturligvis ser forskellige mennesker det samme problem fra forskellige vinkler. Veldefinerede acceptkriterier giver et ensartet overblik over den funktionalitet, du planlægger at implementere.,

alle bør være i stand til at gå op til et Scrum board, få fat i et produkt backlog element, læse acceptkriterierne og tydeligt se alt, hvad der skal udfyldes for at den pågældende vare skal flyttes til den færdige kolonne. Acceptkriterier fortæller dig, hvad der skal gøres for at en bestemt del af et produkt skal være færdig.

Hvorfor har vi brug for acceptkriterier?,

• definere grænser. Acceptkriterier hjælper udviklingsholdet med at definere grænserne for en brugerhistorie. De tjener som en form for bekræftelse af, at appen fungerer som forventet, hvilket betyder, at brugerhistorien er komplet.
• nå konsensus. Acceptkriterier gør det muligt for udviklingsteamet at være på samme side som klienten. De informerer udviklingsholdet om nøjagtigt, hvilke betingelser der skal opfyldes, og sikrer, at klienten ved, hvad han kan forvente af applikationen.
• strømlining accept test., Acceptkriterier er grundlaget for test af accept af brugerhistorier. Hvert acceptkriterium skal testes uafhængigt og have klare scenarier for succes eller fiasko.
• planlægning og estimering. Acceptkriterier giver dig mulighed for at distribuere brugerhistorier på tværs af opgaver, så de vurderes korrekt og planlægges.
• beskriver negative scenarier. Acceptkriterier kan kræve, at systemet identificerer en svag adgangskode og forhindrer en bruger i at fortsætte, for eksempel., Indtastning af et forkert adgangskodeformat er et eksempel på et negativt scenarie, hvor en bruger indtaster forkerte data eller opfører sig uventet. Acceptkriterier Identificer disse scenarier og forklar, hvordan systemet skal reagere på dem.

Hvem skriver acceptkriterier?,

skrivning af acceptkriterier hjælper med at etablere en fælles forståelse mellem produktejeren og udviklingsteamet med hensyn til at løse en kundes problem eller skabe produktfunktioner. Da acceptkriterier vedrører klienten og teamet, skal de skrives enten af klienten eller et teammedlem. hos Mobindustry skriver vores forretningsanalytikere alle acceptkriterier for brugerhistorier. Forretningsanalytikere forstår kundens behov, og hvad udviklere har brug for at vide for at imødekomme projektkravene.,

acceptkriterier dokumenteres og bekræftes inden projektets start, da teamet og klienten skal blive enige om, hvilke resultater der opfylder kundens krav.

eksempler på brugerhistorier med acceptkriterier

nu hvor du har en klar forståelse af, hvad brugerhistorier og acceptkriterier er, lad os se på nogle eksempler.,

eksempel 1

brugerhistorie: som bruger vil jeg være i stand til at registrere mig i tjenesten, så jeg kan begynde at handle online.

acceptkriterier:

• brugere kan kun indsende en formular ved at udfylde alle de krævede felter.
• den e-mail, brugeren giver, må ikke leveres af en gratis e-mail-tjeneste.
• indsendelser fra den samme IP kan kun foretages tre gange inden for 30 minutter.
• brugere modtager underretnings-e-mails efter korrekt registrering.,

eksempel 2

brugerhistorie: som bruger kan jeg få adgang til en meddelelse på min enhed umiddelbart efter at have modtaget den.

acceptkriterier:

• hvis du stryger / trykker på en meddelelse, føres brugeren direkte til meddelelsen.
• Vis viser samtale – hvis den nye meddelelse var et svar, vises den over originalen.
• besked tæller er opdateret.
• en meddelelse er markeret læst efter den vises.

7 tip til skrivning af gode acceptkriterier

acceptkriterier er ikke lette at skrive., På trods af det enkle format er det en udfordring at skrive teksten. Her er syv tip, der hjælper dig med at undgå almindelige fejl, mens du skriver acceptkriterier eller til at gennemgå kriterier skrevet af et medlem af dit team.

• dokument kriterier før udviklingsprocessen starter. På denne måde er teamet mere tilbøjelige til at fange alle kundens behov på forhånd. I første omgang er det nok at sætte kriterier for et lille antal brugerhistorier for at fuldføre efterslæb for to sprints. De dokumenterede acceptkriterier bruges derefter af udviklere til at planlægge den tekniske proces.,
• gør ikke acceptkriterier for snævre. Acceptkriterier, der er for specifikke, giver udviklere lidt plads til at manøvrere. For at undgå dette skal du huske, at acceptkriterier skal være et udtryk for hensigt, ikke en endelig beslutning. Desuden tager smalle acceptkriterier muligvis ikke hensyn til alle brugerhandlinger.
• Hold dine kriterier opnåelige. Effektive acceptkriterier definerer et rimeligt minimum af funktionalitet, som du kan levere. Men hvis du fortsætter med at beskrive alle de små detaljer, er der risiko for, at dit team sidder fast på hundredvis af små opgaver.,
• undgå for brede acceptkriterier. Brede acceptkriterier gør en brugerhistorie vag. Effektive acceptkriterier skal skitsere arbejdsomfanget, så udviklere korrekt kan planlægge og estimere deres indsats.
• undgå tekniske detaljer. Acceptkriterier skal skrives på almindeligt sprog. Dine interessenter og ledere har muligvis ikke teknisk baggrund, så brug af almindeligt sprog vil gøre kriterierne forståelige for alle.
• nå konsensus., Det samme problem kan løses på forskellige måder af teammedlemmer og interessenter afhængigt af deres synspunkter. Sørg for at kommunikere dine acceptkriterier til interessenter og teammedlemmer og nå til en gensidig aftale.
• skriv testbare acceptkriterier. Dette giver testere muligheden for at sikre, at alle krav er opfyldt, og giver udviklere mulighed for at vide, om brugerhistorien er komplet.,

Hvordan til at skrive accept kriterier

Her er fem almindelige regler, der vil hjælpe dig med at løse problemer med formulering af kriterier for accept. Disse regler giver dig mulighed for at spare værdifuld tid og etablere en forståelse mellem produktejeren og udviklingsholdet.

regel #1: Undgå “ikke”

“ikke” betyder “under ingen omstændigheder”, og derfor vil der ikke være nok tid til at verificere overholdelse af en sådan betingelse., Hvis du omskriver kravet uden at bruge “ikke”, bliver det klarere og vigtigst verificerbart.

eksempel:

brugerhistorie

må ikke: som bruger ønsker jeg ikke at skulle indtaste min adgangskode, hver gang jeg får adgang til min konto.
Do: som bruger vil jeg have min adgangskode husket og automatisk udfyldt, så jeg kan få adgang til min konto uden at indtaste min adgangskode igen.

acceptkriterier

må ikke: systemet må ikke mislykkes.
Do: systemet skal have en tilgængelighed på ikke mindre end 90%.,

undtagelse

Du kan bruge “ikke” i acceptkriterier til at introducere en logisk indsigelse, såsom “login-formularen skal ikke være rød.”I de fleste tilfælde gælder dette for ikke-funktionelle krav. I dette eksempel formulerer vi en begrænsning, der let kan verificeres, hvis rækkevidden af røde nuancer er klart defineret (for eksempel angivet i RGB-format).,

Regel #2: Brug aktive stemme

Aktiv stemme, når motivet i en sætning, er den udøvende kunstner i aktion. Hvis den enhed, der er ansvarlig for at udføre handlingen, ikke er tydeligt angivet, vil det være uklart, hvem eller hvad der skal udføre handlingen, og det vil være vanskeligere for dig at kontrollere, om et krav er opfyldt.,

eksempel:

brugerhistorie

må ikke: som en online shopper ønsker jeg, at filtre skal anvendes, så jeg kan finde det, jeg vil have.
Do: som bruger vil jeg anvende søgefiltre, så jeg kan finde varer.

acceptkriterier

må ikke: kundens identitet skal bekræftes. (Det er uklart, hvem eller hvad der er ansvarlig for at bekræfte kundens identitet.)
Do: Accounting_System skal bekræfte Customer_Indentity. (Bemærk, at definitionerne af udtrykkene “Accounting_System ” og” Customer_Indentity ” skal tilføjes til ordlisten.,)

regel #3: Undgå at bruge pronomen (især udefinerede)

brug navneord i stedet for pronomen, når der henvises til elementer, der henvises til i andre krav. Pronomen bør undgås, fordi de kan indføre tvetydighed.,

Dette er især vigtigt, når acceptkriterier gemmes i kravstyringsværktøjer (såsom Jira) som separate udsagn, der ikke nødvendigvis er organiseret. Brug altid navneord i stedet for pronomen, og du vil undgå dette problem.

eksempel:

brugerhistorie

må ikke: som medlem af siteebstedet vil jeg dele oplysninger om mig selv, så andre kan se det.
Do: som medlem af siteebstedet vil jeg tilføje en profilbeskrivelse, så andre kan lære om mig.

acceptkriterier

må ikke: controlleren skal sende føreren Rejseplanen for dagen., Det skal leveres mindst 8 timer før skiftet.
Do: controlleren skal sende Driver_Itinerary for dagen til føreren mindst 8 timer før Driver_Shift.

Regel #4: Undgå konjunktioner

Konjunktioner er ord og vendinger som “og” “eller” “men,” og “, samt” at kombinere enkle sætninger ind i komplekse., Deres anvendelse i krav er normalt et tegn på, at et krav kan opdeles i flere separate krav.

eksempel:

brugerhistorie

må ikke: som UI-designer vil jeg oprette og se et problem, så jeg ved, hvad jeg skal teste.
Do: som UI-designer vil jeg oprette et problem, så jeg ved, hvad jeg skal teste. / Som UI-designer vil jeg se et problem, så jeg ved, hvad jeg skal teste.

acceptkriterier

ikke: brugeren skal enten have tillid til eller ikke have tillid til.
Do: Security_System skal kategorisere hver bruger som enten betroet eller Not_Trusted.,

undtagelse

“og” “eller” og “ikke” kan bruges til at beskrive logiske forhold og tilføje kvalifikatorer.

regel #5: undgå uopnåelige absolutter

et absolut (såsom 100% tilgængelighed) er uopnåeligt. Tænk på, hvordan du kontrollerer indikatoren: vil det være muligt at bevise, at niveauet for systemtilgængelighed er nøjagtigt 100%?, Og selvom et sådant system kunne oprettes, har du råd til det?

undgå ordene “Alle”, “altid” og “aldrig”, da kontrol af sådanne absolutte krav vil kræve et uendeligt antal tests.

eksempel:

brugerhistorie

må ikke: som rejsende vil jeg vide Min præcise placering opdateret i realtid, så jeg ikke går tabt. (“Realtid” kan fortolkes på forskellige måder. For eksempel kan det ses som et absolut (fraværet af forsinkelse), som ikke kan opnås, og som ikke kan verificeres.,)
Do: som rejsende vil jeg vide Min præcise placering, opdateret hvert sekund, så jeg ikke går tabt.

acceptkriterier

må ikke: systemet skal have 100% tilgængelighed. (100% er et absolut, der ikke kan nås og ikke kan verificeres.
Do: systemet skal have en tilgængelighed på mindst 98%.

hurtig oversigt over acceptkriterier

Vi håber, at denne artikel har kastet lys over verden af acceptkriterier og brugerhistorier., Her er de vigtige grillbarer:

• Accept kriterier, er betingelserne for et software-produkt skal opfylde for at blive accepteret af brugeren, kunden, eller i tilfælde af system-niveau funktionalitet, tidskrævende system.
• acceptkriterier skal dokumenteres og udfyldes inden starten af et projekt, da teamet og kunden skal blive enige om, hvilke resultater der opfylder kundens krav.
• Husk, at acceptkriterier skal være et udtryk for hensigt, ikke en endelig beslutning.
• effektive acceptkriterier definerer et rimeligt minimum af funktionalitet.,
• gode acceptkriterier skal skitsere omfanget af arbejdet, så udviklere korrekt kan planlægge og estimere deres indsats.
• acceptkriterier skal skrives på almindeligt sprog.
• sørg for at kommunikere dine acceptkriterier til interessenter og teammedlemmer og nå til en gensidig aftale.
• mens du skriver acceptkriterier, skal du undgå at bruge “ikke” konjunktioner og uopnåelige absolutter. Formuler sætninger ved hjælp af aktiv stemme.,

Hvis du vil oprette acceptkriterier og brugerhistorier til din mobilapp, eller hvis du har spørgsmål vedrørende dette emne, skal du kontakte Mobindustry for en gratis konsultation.