Sådan undgår I dyre fejl i specifikationer

“There is nothing so useless as doing efficiently that which should not be done at all.” Sådan lyder det fra den kendte ledelsesekspert Peter Drucker, og det gælder også inden for softwareudvikling.

Hvis teamet har brugt tid på at forstå, programmere, dokumentere og teste ud fra en specifikation, der viser sig at være forkert, hvad hjælper det så, at de arbejder hurtigt og effektivt?

Jeg har som softwareudvikler nogle gange oplevet, at man i ren ivrighed efter at komme i gang med et nyt system glemmer at sikre sig, at det er det rigtige, man kommer i gang med. Dels kan der jo allerede findes eksisterende løsninger, som med forholdsvis få tilpasninger kan udfylde det underliggende behov. Dels får man sjældent rigtig sat ord på, hvad det præcis er, der skal udvikles fra ende til anden.

Fejl kan give store omkostninger

Konsekvensen af fejl i specifikationer er ofte store omkostninger, fordi udviklingsteamet bygger funktionalitet, der enten ikke er behov for, eller som langt fra løser det grundlæggende behov.

I værste fald risikerer man med henvisning til princippet ”Vi værdsætter velfungerende software frem for omfattende dokumentation” fra det agile manifest at bilde hinanden ind, at man slet ikke behøver at specificere, hvilket er en misforståelse.

Formuler kravet i én sætning

Spørgsmålet er så, hvad man gør for at undgå fejl og oversete krav i specifikationer?

Når man vil specificere effektivt, kan userstory-begrebet hjælpe rigtig godt på vej. Hvis ikke det kan formuleres med ”Som en <given bruger> ønsker jeg <en given handling> for at opnå <et givent resultat>”, er det muligvis fordi, at problemstillingen er for kompleks og skal nedbrydes yderligere.

Omvendt skal problemstillingen ikke være så konkret, at der slet ikke er tale om en userstory. Eksempelvis: ”Som en bruger, der er logget ind, vil jeg gerne trykke på en Gem-knap for at gemme de indtastede ændringer”. Dette er en al for snæver beskrivelse, som blot er et enkelt led i en userstory – og ikke en userstory i sig selv.

Glem ikke slutresultatet

Hvor ofte glemmes det i øvrigt at definere selve slutresultatet? Det er afgørende at kunne formidle netop dette til udviklerne, fordi de ellers har en ringe chance for at vide, om det kunne løses endnu smartere. Man kunne endda argumentere for at vende helt rundt på sætningen, så man starter med det ønskede resultat: ”For at opnå <givent resultat> så <given handling> som <given bruger>”.

Inden der overhovedet skrives noget kode, kan det ofte også betale sig at teste specifikationerne. Man behøver nogle gange blot at gå igennem de forskellige brugsscenarier på et stykke papir for at finde de mest indlysende fejl.

Denne artikel er skrevet af Klaus Bjørnestad, som har fungeret som softwareudvikler og -arkitekt på softwareudviklingsprojekter i mere end 10 år. Hvis du ønsker en gennemgang af jeres udviklingsproces eller bare er nysgerrig på mere information, er du velkommen til at kontakte Klaus Bjørnestad på kb@arosit.dk eller telefon 5137 7353

Om forfatteren:

Jørgen er certificeret Scrum Master og Scrum Product Owner. Han har arbejdet med IT-udvikling siden 1996 og har været selvstændig siden 2007. I 2011 indtrådte han som medejer af Aros IT.

Læg en kommentar