Indledning

Når vi arbejder med softwareudvikling er det en naturlig del af processen, at vi må beskrive opgaver for vores udvikler, eller udviklingsteam. Altså, hvilke features vi gerne vil have dem til at udvikle, hvordan de skal virke og gerne hvorfor.

Præcist beskrevne opgaver er en hjørnesten i succesen af vores system, fordi det gør det lettere for vores udviklere at forstå hvordan vi ønsker vores system skal fungere, og i sidste ende hvilken oplevele vores brugere/kunder skal have.

Hvis udviklerne ikke forstår hvad vi prøver at opnå eller er nødt til at tolke for meget, så vil udvikligen tage længere tid, resultatet vil variere meget fra vores intention, og ofte også være fejlbehæftet.

Derfor giver det mening at dykke lidt ned i, hvordan vi kommunikerer bedst muligt med udviklerne omkring opgaver, så vi kan undgå ægrelserne der opstår når opgaverne er forløst eller upræcsist formuleret.

Her er gode accept kriterier et effektivt greb, og det er værd at blive skarp på:

• Hvad er formålet med accept kriterier og hvorfor er de så vigtige i udvikling

• Hvordan formulerer man entydige og præcise accept kriterier?

• Hvordan identificerer man utydelige eller upræcise kriterier?

Lad os først definere hvad et accept kriterie egentlig er og hvilken rolle de spiller i vores udviklingsproces.

Hvad er accept kriterier?

Et accept kriterie er nøjagtig hvad det lyder som: Det er et kriterie for at vi kan acceptere en ting. Et krav om at noget skal være opfyldt, før vi kan acceptere opgaven som udført korrekt.

Accept kriteriet har altså til opgave at formulere tydeligt for læseren af opgaven, hvad der forventes løst og hvordan oplevelsen skal være efter opgaven er løst. Det fungerer således som en form for kontrakt imellem den der stiller opgaven og den der udfører eller kontrollerer leverancen af den.

Målet er altså at gøre det helt tydeligt for modtageren af opgaven, hvordan vi ønsker brugeroplevelsen skal være, og hvordan vi verificerer at opgaven er løst korrekt. Bid her mærke i det handler om at beskrive hvad brugeren skal opleve, ikke hvordan det skal udvikles.

Gode accept kriterier har en række egenskaber, der er værd at huske på:

• De er brugervendte og beskriver hvad brugeren oplever, ikke hvordan det laves

• De er præcise og hver krav kommunikerer ét entydigt aspekt af opgaven

• De er konkluderende og formulerer helt sort/hvidt hvornår kravet er opfyldt

Der kræves altså ingen tekniske færdigheder for at skrive gode accept kriterier, så længe man er i stand til at beskrive brugeroplevelsen præcist og entydigt.

Hvorfor er accept kriterier vigtige?

Når vi skriver gode og præcise accept kriterier opnår vi en klarhed omkring forventninger til hinanden og det bliver klart for alle læsere af opgaven, hvordan brugeroplevelsen skal være når opgaven er løst. Det er et godt afsæt for kommunikation og dialog i teamet.

Hvis en opgave bliver meget omkostningstung at udføre, kan udvikleren f.eks. anbefale alternative muligheder der er billigere at implementere, men som måske giver samme eller næsten brugeroplevelse.

Når vi formulerer accept kriterier på denne måde opnår vi nogle positive dynamikker i vorres team:

1. Opgavestilleren behøver ikke være teknisk og kan fokusere på at beskrve hvad brugeren skal opleve, ikke hvordan det løses.

2. Udvikleren har metodefrihed til at beslutte, hvordan opgave løses og kan fokusere på at skabe den brugeroplevelse der er beskrevet i opgaven.

3. Andre kan læse og forstå opgave, f.eks. den QA-person der senere skal godkende opgaven før den går live.

Teamet kan således byde ind med deres individuelle ekspertise og synspunkter, og sammen finde frem til den bedst mulige løsning for både brugeren og forretningen. Dette øger arbejdsglæden for alle parter, fordi de hver især kan fokusere på det de er gode til, samtidig med at de har en større følelse af klarhed omkring opgaver og kommunikation.

Hvem skriver accept kriterierne?

Der florerer en generel mistforståelse om at opgavestilleren skal være teknisk funderet for at kunne formulere opgaver ordenligt til udviklerne. Det er en myte og absolut ikke nødvendigt.

Opgavestilleren skal have en forståelse for, hvordan systemudvikling foregår og hvilke udfordringer et udviklingsteam møder, men der er intet krav om at have teknisk baggrund for at skrive gode accept kriterier.

Misforståelsen fører nogle gange til at teams beslutter at det er udviklerne der skal formulere accept kriterierne fordi "Det er jo dem der ved, hvordan det skal laves", og så slipper opgavestilleren jo også for at gøre det.

Dette er en klar dysfunktion i et team, og fører næsten altid til skyttegravskrige imellem opgavestiller og udviklere - vi vil det modsatte.

Opgavestilleren er personen der skriver accept kriterierne som en del af processen med at beskrive opgaver. Det er helt centralt, fordi det er opgavestilleren der har ansvar for at designe brugeroplevelsen (forhåbenligt i samråd med en UX-designer), og dermed også ansvaret for at beskrive den så udviklerne kan forstå det.

Sådan skrives Gode Acceptkriterier

Nu skulle vi gerne være helt klare på, hvad accept kritierier er, hvem der har ansvaret for at skrive dem og hvad vi prøver at opnå med dem. Så lad os zoome lidt ind og kigge på dna'et i de gode accept kriterier og hvordan de hjælper os i at beskrive opgaver med et eksempel.

Eksempel: Den ryddelige have

Vi bruger en analogi som de fleste vil kunne relatere til: en have med græs, hække og så videre.

Lad os endvidere sige at vi vil forberede vores have til en stor fest, og vi har derfor hyret en gartner til at tage sig af det. Målet er naturligvis at haven står kniv-skarpt til vores event, og vi skal formulere, hvilken oplevelse vi gerne vil have.

Vi kunne skrive en opgaveliste til gartnere på følgende måde: "Hækkene skal være klippet og græsset være slået" - og selvom det naturligvis fortæller overordnet, hvad vi gerne vil opnå, så er det stadigvæk ret upræcist og med rigelig plads til fortolkning.

Lad os i stedet kommunikere i accept kriterier, som gør det lettere for gartneren at forstå, hvordan vores gæster skal opleve haven.

Opgave: Hækkene skal klippes så de står pænt og nydelige

Acceptance kriterier:

• Hækkene er klippet til 180 cm i højden

• Hækkene er klippet til 80 cm i bredden

• Ukrudt under hækkene er luget

• Jorden under hækkene er revet, så det fremstår pænt

• Ukrudt og afklip fra hækkene er fjernet fra grunden

Lad os nu evaluere om vi overholder de fire egenskaber:

• Brugervendte: Ja, de beskriver hvordan en gæst vil opleve haven

• Præcise: Ja, hvert krav fokuserer på ét afspekt hver

• Konkluderende: Ja, man kan tydligt svare ja eller nej til hver enkelt.

Så, ja, opgaven lader til at være meget nem at forstå og en anden person, f.eks. festplanlæggeren, ville også kunne læse accept kriterierne og gennemgå haven sammen med gartneren og kontrollere af om opgaven er korrekt udført.

Eneste afvigelse fra kravet om sort/hvide svar er formuleringen i punkt 4 ..., så det fremstår pænt. Her udtrykker vi vores subjektive mening, men overlader det i virkeligheden op til gartnerens vurdering om jorden fremstår pænt. Det er svært for os at klandre gartneren, hvis vi ikke opfatter resultatet som pænt, men har samtidig signaleret at han/hun skal gøre sig umage med det.

Har vi en en sund dialog med gartneren og måske lidt historik, så vil gartneren fint være i stand til at tolke, hvad vi mener med "fremstår pænt".

Lad os gå videre med græsplænen.

Opgave: Græsset skal trimmes, så det står skarpt

Accept kriterier:

• Hele græsplænen er slået med en maks højde på 5 cm

• Kanterne langs huset er trimmet til samme højde som græsset

• Afklippet græs er samlet sammen og fjernet fra grunden

Igen, opgaven er klart udspecificeret, så der er meget lidt at være i tvivl om. Kravene forholder sig ikke til hvordan gartneren skal udføre opgaven, hvem der skal gøre det eller hvilket værktøj der skal bruges. Det giver gartneren metodefrihed til at løse opgaven som forgodtbefindende, så længe kravene opfyldes.

Bemærk også at opgaverne er delt op i hække og græsplæne. Det kan være fristende at skrive alle kravene i én lang liste, men det er værd at undgå, da det binder succesen til hele haven, selvom bare det at få klippet hækkene i sig, eller slået græsset individuelt er et win. Det ser vi nærmere på i næste afsnit.

Almindelige fejl og hvordan man undgår dem

Lad os nu vende blikket mod nogle af de almindelig fejl der opstår, når opgavestillere skal formulere opgaver til udviklere, og som er værd at undgå. Her ser vi på nogle klassiske eksempler, da de opstår ofte og derfor er værd at bruge lidt til på at kunne genkende.

Undgå: One-lineren

Det er ikke ualmindeligt for opgavestillere at vælge den lidt dovne tilgang, og bruge den klassike one-liner, som eneste opgave beskrivelse. Altså, man skriver én eller måske to linjer, der løst beskriver et ønske, men ofte meget løst og upræcist - gerne med intention om at vende tilbage med mere info, hvilket dog ofte udebliver.

Denne opgaveform er værd at undgå, fordi:

1. Det kræver meget efterfølgende dialog mellem opgavestiller og udvikler at udrede, præcis hvad opgaven handler om

2. Den ekstra dialog foregår ofte mundtligt og forbliver altså mellem opgavestiller og den specifikke udvilker - resten af teamet er ikke i stand til at overtage opgaven med samme viden, uden at spørge.

3. Det er udfordrende at estimere opgaver der er så løst beskrevet

One-lineren kan godt bruges som placeholder, for opgavestilleren som en del af deres proces, men er altså problematisk når vi skal til at overlevere information til teamet.

Undgå: Den altomfagnende opgave

Den altomfagnende opgave kendetegnes ved at prøve at mase en masse separate opgaver ned i én og sammen opgave. Det er på en måde en modpol til one-lineren fra før. I eksemplet med gartneren vill det være at skrive alle krav ind i én stor opgave, med overskriften "Klargør haven".

Denne opgaveform er udfordret, og værd at undgå, fordi:

1. Med mange krav og del-opgaver i én opgave, binder mand succes og fiasko op på én opgave

2. Opgaven til ofte være in progress, i lang tid før den afsluttes som hindrer teamets agilitet og evne til at manøvrere

3. Den er svær at overlevere, da den er i konstant tilstand af in progress og overlevering kræver koordinering

4. Den er ofte løst beskrevet, simpelthen fordi der er så meget at beskrive

Den altomfagnende opgave er uproduktiv, fordi som vi allerede har rørt ved, så binder det succes og fiasko til én stor event, lidt i stil med æggene i én kurv - vi vil hellere have mange små og beholde vores agilitet

Undgå: Den den tekniske to-do liste

En anden almindelig fejl er at formulere opgaven som en bageopskrift af gøremål udviklerne skal udføre, for at opgaven kan løses. Altså, en liste af konkrete kodeopgaver eller lignende i stil med "Lav API til at modtage data" eller "Opdater stored procedure til at modtage svensk telefonnummer".

Selvom det er en almindelig praksis, så er der en del udfordringer forbundet med denne form:

1. Fokus er flyttet væk fra brugeroplevelsen og ned i teknikken - vil gerne holde fokus på brugeren.

2. Det kræver at opgave stilleren nu skal være teknisk nok til at beskrive på et så detaljeret niveau

3. Udvikleren har mistet sin metodefrihed til at implementere opgaven på bedst mulig vis - det er de færreste udvilkere der bryder sig om det.

Den tekniske to-do liste kan udviklerne fint udforme et sted, hvis de mener det hjælper dem, men det hører ikke hjemme som accept kriterierne for en opgave - de skal handle om brugeren.

Undgå: Fritekst-formatet

Fritekst-formatet er, hvor vi beskriver kravene til vores opgave i fri form, med beskrivelser og analogier og så videre. Som almindelig tekst, dybest set.

Dette format er bedre end one-lineren, da det ofte indeholder bedre beskrivelser, men møder en række andre udfordringer:

1. Meget lange tekster at svære for udviklere at tage ind forstå - kort og præcist vinder

2. På trods af lange og grundige beskrivelser, opstår der ofte tvivl om, hvordan udvikleren skal tolke de enkelte krav

3. Krav kan være modstridende, uden at opgavestilleren er opmærksom på det - det kræver så udredning med udvikleren

4. Lange tekster gør det sværere at verificere enkelt krav, når koden skal testes på vej til produktion

Så, selvom fritekst-formatet ypisk bærer mere information med, er det altså heller ikke optimalt til at kommunikere krav til opgaver.

Der findes mange flere, men disse er i hvert fald på listen over meget almindelig fejl, der er værd at undgå.

Konklusion

Nu har vi set på, hvad et godt accept kriterie er, hvorfor det er vigtigt, hvem der skriver det, samt et par eksempler og ting der er værd at undgå.

Så lad os opsummere egenskaberne ved gode accept kriterier:

• De er skrevet af opgavestilleren som formidling til udviklerne

• De formidler hvad brugeren skal opleve - ikke koden eller teknikken

• De er fokuserede helt sort/hvidt på ét krav ad gangen og kan svares ja eller nej til

• De kan løses uden yderligere kommunikation med opgavestilleren

• De kan verficeres af en anden person end udvikleren, når opgaven er løst

Overholder vi disse enkle regler, når vi stiller opgaver, så vil både udviklere, opgavestiller og QA'ere have nemmere ved at arbejde med opgaverne, hvilket gør alle gladere og i sidste ende øger produktiviteten og agiliten i teamet.

Rigtig god fornøjelse med at skrive bedre accept kriterier og bedre opgaver :)