Et krav er et krav er et krav
I de 20 år, jeg efterhånden har udviklet software, har der været et utal af strategier for at håndtere krav: Nummererede lister af målbare udsagn, use cases, user stories …
Men til trods for, at navnene på metoder og værktøjer har ændret sig, er det alligevel mange af de samme fejl, der begås, og ofte bliver de brugt på en måde, hvorpå det lige så godt kunne have været en anden metode, der anvendtes.
Om folk skriver en one-liner og kalder det et nummeret krav eller en user story, gør altså ikke den helt store forskel.
Men der er nogle ret klare forskelle i de forskellige tilgange, som det er vigtig at være opmærksom på.
Funktionelle krav
Et af de store problemer ved mange af de klassiske lister af krav, der blev sendt ud til budkrige i de “gode gamle dage”, var, at de for det meste kun indeholdt de funktionaliteter, systemerne skulle indeholde, og oftest også kun information om, hvad der skulle ske i de situationer, hvor alting gik, som det burde.
Det betød for eksempel, at der sjældent var informationer om, hvor mange samtidige brugere der skulle være på systemet, om systemet skulle kunne anvendes uden mus, eller om det var i orden at vise en blå skærm, når der skete et eller andet, som ikke lige var en del af den normale arbejdsgang.
Faktisk kan en ting, som at oppetiden hæves fra 95 procent til 99,99 procent, betyde meget mere for prisen end selv store funktioner.
Som leverandør var det selvfølgelig dejligt at kunne skrue på disse parametre, så man kunne finde den rigtige pris, som kunne vinde kontrakten, men det var oftest ikke befordrende for samarbejdet med kunden, når de så efterfølgende fandt ud af, hvordan leverandøren tolkede kravene.
Fokus på ikke-funktionelle krav
For at få bedre kravsspecifikationer begyndte man så i OOA/OOD at have fokus på både de funktionelle og de ikke-funktionelle krav; oftest organiseret efter huskereglerne som FURPS+ og lignende (Functionality, Usability, Reliability, Performance, Supportability…).
Når det gælder de funktionelle krav begyndte man også i højere grad at strukturere kravene til systemet ved at bruge use cases, som ikke kun havde fokus på hovedsuccesscenariet (hvor alt bare gik, som det ideelt set burde), men også beskrev, hvordan fejlsituationerne skulle håndteres.
Hermed fik man så skabt en mere detaljeret specifikation, hvor man også blev tvunget til at forholde sig til rigtig mange ting, som så gjorde, at kodningen efterfølgende blev nemmere (jeg har selv været med til at skrive kravspecifikationen til en stor del af en elektronisk patientjournal, og det blev godt nok til en del sider).
Krav i det agile mindset
Med det agile mindset er der selvfølgelig også kommet en ny tilgang til krav, hvor det hele er blevet til user stories.
Umiddelbart kan det se ud som et tilbageskridt, da man nu oftest er tilbage i en liste af one-liners uden støttehjulene med FURPS+ og use cases til at sikre, at alt kommer med.
Men fejlen er nok at se listen af user stories som en traditionel kravspecifikation.
Et af fundamenterne for user stories er nemlig antagelsen om, at delte dokumenter ikke er det samme som en delt eller fælles forståelse.
User stories er derfor mere overskrifter eller referencer, som den efterfølgende skabelse af en fælles forståelse kan hænges op på.
Hvordan man så efterfølgende mest effektivt skaber og fastholder den fælles forståelse, er meget afhængig af den konkrete situation, og det ligger egentlig uden for user story’en.
Her kan der være situationer, hvor use cases, workflows, mock-ups, personas og mange andre metodikker kan være anvendelige.
Det andet område, hvor jeg synes, at den agile tilgang tilføjer en ekstra dimension til kravstyringen, er i forhold til “definition of done”.
Her er det ikke kun eksterne parter som product owners eller kunder, der definere kravene til, hvornår en feature er færdig, men mindst lige så meget udviklingsteamet selv, der får lov til at indgå en intern kontrakt om, hvad teamet mener er godt håndværk og nødvendigt for, at kunden får det rigtige produkt.
Selvom “definition of done” er et meget vigtigt koncept i for eksempel Scrum, er der overraskende mange team, som ikke har indgået sådan en kontrakt, hvilket kan gå ud over kvaliteten og – mindst lige så vigtigt – teamgejsten.
Vær opmærksom på styrker og svagheder
Som jeg har forsøgt at eksemplificere, er der nogle ret store forskelle i tilgangene til krav i de forskellige perioder.
Det gælder lige fra antagelsen om, at kravene skal være så komplette og detaljerede som muligt, til user stories som i praksis bare er overskrifter, som man efterfølgende skal samarbejde om at skabe en fælles forståelse af (husk nu det agile manifest med “samarbejde med kunden frem for kontraktforhandling”).
Alligevel ser man mange gange User stories brugt i situationer, hvor målet er en detaljeret og komplet kravspecifikation, som vi kan styre leverandør eller kunde ud fra – hvilket det aldrig var skabt til.
Omvendt synes jeg, det er forkert at se værktøjerne fra de forskellige perioder, som om de udelukker hinanden, men formålet med at bruge dem har måske ændret sig.
For eksempel kan FURPS+ stadig være en god remse at huske på, når man skriver sine user stories, eller mens man skaber den fælles forståelse, så man også får tænkt de ikke-funktionelle aspekter ind.
Og use cases er i nogle situationer den mest effektive måde at få alle variationerne tænkt igennem og fastholdt.
Som sædvanlig handler det altså om at kende styrker og svagheder ved så mange værktøjer som muligt og så bruge det, der giver mening. Det vil sige det, som er med til at skabe den fælles forståelse – også for de sværere elementer, hvor man er som udgangspunkt er uenig.
Annonce:
