Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
Giv mig så en brugbar kravspecificering... så jeg får mulighed for at gøre mit arbejde ordentligt, kunne jeg lige så godt have tilføjet.
Jeg er dødtræt af, at så mange danske virksomheder stadigvæk lever i oldtiden, hvad angår deres it-udvikling og fortsat giver deres it-projekter så dårlige levevilkår.
For vi projektledere, scrum mastere og vores teammedlemmer vil faktisk gerne levere succes og få den anerkendelse, vi fortjener. I stedet for konstant at skulle arbejde på øretævernes holdeplads.
Garbage in, Garbage out. Jeg tror, de fleste kender det udtryk. Og det er jo ret logisk, at hvis kvaliteten af dét, man propper ind i den ene ende af processen, er ringe, så vil outputtet også være det.
Og hvis man skal have højnet kvaliteten af det dårlige input, mens det processeres i maskinrummet, ja så koster det en masse ressourcer.
Derfor er det mig en gåde, at vi i Danmark bliver ved med at acceptere at starte vores softwareudviklingsprojekter med så dårlige og uklare kravspecificeringer, når vi godt ved, at garbage in resulterer i garbage out?
Måske handler det om, at vi er superoptimister, der tænker, at det hele nok skal gå alligevel, eller også arbejder vi bare på den måde, fordi vi altid har gjort det. Eller måske er sagens kerne noget helt andet – at man simpelthen ikke forstår, hvad der kendetegner en brugbar kravspecificering?
Ting der typisk fejler i en kravspecificering
De to mest kritiske ting, der ofte fejler i en kravspecificering, sådan som jeg oplever det, er, at user stories er uden forretningsværdi, eller at de ikke har test-bare acceptkriterier.
Tag eksemplet fra en spillevirksomhed, hvor en user story kunne lyde sådan her: ”Som quizdeltager ønsker jeg at modtage feedback efter hvert quizspørgsmål, så jeg kan se med det samme, om jeg svarede rigtigt eller forkert på spørgsmålet”.
Den er god, fordi forretningsværdien er tydelig, og med nogle klare acceptkriterier er det nemt for teamet at gå i gang med at udvikle på den.
De skal bare huske, at det kun kommer til at virke i praksis, hvis de samtidig erkender i teamet, at det kræver en tæt dialog med projektejeren - gerne via løbende refinement-møder.
Udviklerne har altså blot behov for at forstå de præcise forretningsmæssige krav, der skal løses, og så kan de herudfra selv udtænke, hvordan funktionaliteten kan udvikles bedst.
Men de kan ikke selv finde ud af at omsætte upræcise user stories, hvor de ikke forstår, hvad forretningen vil have og hvorfor som for eksempel i user storien: ”Det skal være intuitivt”.
Denne user story er helt umulig, for hvornår er et system eller en funktionalitet intuitiv?
Det er jo en subjektiv vurdering, og it-udviklingsteamets oplevelse af, hvad der er intuitivt, kan sagtens være en helt anden end forretningens.
Og derfor er det umuligt for udviklingsteamet at vide, om de har leveret det, som kunden ønsker.
I stedet for har de brug for user stories, der for eksempel er udtrykt således: ”Som bruger vil jeg max. opleve to klik mellem proces x og y, så jeg minimerer brugen af musen”.
Projektteamet SKAL forstå forretningsværdien
Med andre ord er det simpelthen nødvendigt, at projektteamet forstår, hvilken forretningsværdi systemet skal skabe, for at de kan levere et ordentligt stykke arbejde. Og det er noget, der så absolut må fremgå af kravspecificeringen!!!
De fire vigtigste gode råd:
1. Sørg for, at alle user stories overholder INVEST-modellen.
2. Stil krav til forretningen om, at forretningsværdien BÅDE skal være beskrevet i ord, OG sørg for, at bruge en metode til vægtning af værdien som fx WSJF-metoden.
3. Hold løbende refinement-møder, hvor ALLE i projektteamet deltager. Sørg for, at projektejeren senest dagen før oplyser, hvilke emner der skal drøftes på mødet.
4. Hvis der skal bruges tid ud over refinement-møderne til at hjælpe med kravspecificeringen, SKAL opgaven stå tydeligt på Scrumboardet.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.