Nej! Gu’ er den ej! Jeg er ved at være træt af at læse blogindlæg på blogindlæg om agile metoder, der konkluderer at kravspecifikationen er fortiden til. Intet kan være mere forkert!
Dette lyder nok som et rimeligt surt fredagsopstød ovenpå en nat, hvor min datter har holdt sine forældre løbende orienteret omkring nattens eskapader fra sin seng i det tilstødende børneværelse, når de helst gerne bare vil sove. En hård juleperiode er i vente, ikke blot på grund af det årlige panikgaveræs, snestorm og familietamtam hos tante tut, men også fordi at der både er store projekter skal afleveres og store projekter er ved at blive opstartet. Når jeg så læser, at kravspecifikationen er død og borte, til fordel for agile metoder, ja, så har jeg svært ved at holde igen.
Jeg vil gerne forklare mit synspunkt herunder. Det hører sjældenhederne til, at kunden ikke gerne vil kende en smule til økonomien i et projekt inden opstart. Ja, faktisk, har jeg ikke mødt en kunde endnu, der ikke har spurgt “hva’ koster’d?” Jeg tror ikke, at dette er unikt for vores branche, men må være et rimelig generisk og fair krav. Personligt ville jeg nok heller ikke bede en leverandør om bare at gå i gang, og tales ved efter to måneder, når fakturaen kommer dumpende. Kravspecifikationen er yderst vigtig i dette scenario, og her kommer f.eks. SCRUMS product backlog efter min overbevisning desværre til korte.
Jeg havde en snak med en kunde omkring funktionalitet til den kommende hjemmeside. Han havde ikke rigtigt noget fast budget og han havde nogle klare overordnede forventninger til hvad hjemmesiden skal kunne kunne. Et krav gik på at han gerne ville sende et nyhedsbrev til sine kunder pr. e-mail. Et meget basalt krav, som mange hjemmesider understøtter. Men skal nyhedsbrevet også kunne sendes pr. SMS? Skal han kunne vedhæftet en fil? Skal han kunne opdele modtagerne i segmenter, så han kan sende forkellige nyhedsbreve al efter hvilke karakteristika modtageren har? Skal nyhedsbrevet sendes som PLAIN TEXT eller skal det være HTML, så det kan have et visuelt udtryk? Svarene var nej, ja, ja og ja. Denne løsning giver én økonomi, men havde svarene været ja, nej, ja, nej, så havde økonomien været en anden. Desuden giver kravspecifikationen en forventning om hvad nyhedsbrevet kan, _inden_ udviklerne går i gang. Kundens røde lamper vil straks lyse, hvis han havde en klar forventning om, at han skulle kunne vedhæfte et PDF dokument til sit nyhedsbrev, og ikke kan det efter implementeringen. Derfor kan kunden forholde sig til den økonomi han har fået første gang, og skal ikke vente på ubehageligheder, når vi først efterfølgende finder ud af, at han også har et behov for at vedhæfte PDF dokumenter. Samtidigt er der en klar forventning, leverandør og kunde imellem, om hvad kunden får for den estimerede økonomi.
For at jeg kan estimere en økonomi, skal jeg kende alle projektets omstændigheder – ergo skal ubekendte og risici minimeres, for ellers kan jeg komme til at under- eller overestimere og projektet går ikke op. Underestimerer jeg bærer jeg en risiko, hvilket betyder at jeg må gå på kompromis med kvalitet for at holde mig indenfor økonomien. Overestimerer jeg betaler kunden for meget i forhold til hvad han får af værdi. Samtidigt kan jeg skitsere en forkert løsningsmodel, der ikke tilfredsstiler kundens reelle behov. Og det er er værre, end at projektet ikke går op. Dette afhjælpes ved at skrive en fyldestgørende kravspecifikation, hvor hvert eneste krav til hjemmesiden er specificeret entydigt og konkret. Jeg er tilhænger af planlægning og mener ikke at udviklingsmodeller, som QADAD (Quick-and-Dirty-Application-Development) eller CAF (Code-and-Fix) afføder stabile eller særligt kvalitetsorienterede løsninger – giver det ikke lidt sig selv? Desværre kan SCRUM hurtigt blive QADAD eller CAF, da analysefasen begrænser sig til en product backlog, der udetaljeret skitserer løsningens overordnende design. Misforstå mig ikke, dette har også sine helt klare fordele i visse situationer, som jeg nok skal komme ind på i et fremtidigt blogindlæg. Men man har tendens til at kaste sig over tastaturet og kode derudaf. Det kan også være fint nok i nogle situationer, men hvis ikke kunden føler sig særlig hjemme i SCRUM eller har erfaring med systemudvikling generelt, så er det traditionelle paradigme og kravspecifikation at foretrække.
Kravspecifikationen giver altså en mere detaljeret estimering af projektets samlede omkostninger (Total Cost of Acquisition). Den giver også en forventning om hvad projektet ender ud med. Og dette gør at kunden nemmere kan vurdere projektet i forhold til dets Business Case. Giver projektet derfor overhovedet mening at gennemføre? Ved de agile metoder ved man først dette, når man står på den anden side, da man først kender projektets leverancer, når det er gennemført. Det er ikke særligt forretningsorienteret, vel? Agilitet er godt i projekter, hvor vi ikke har klare forventninger til funktionalitet og ikke kender vores behov. Det er lige nøjagtigt her, at de agile metoder kommer til sin rette.
Når ressourcerne bruges til at skrive en kravspecifikation, så sikrer dette også en mere lean proces. Flaskehalse elimineres, da afklaringer holdes på et minimum. Jeg lærte i skolen, at kravspecifikationen bør sikre at alle afklaringer omkring funktionalitet er gjort på forhånd, således at udviklerne har en madopskrift de kan følge – punkt for punkt. Dette holder nok i teorien, men i praksis er det ikke muligt. Kravspecifikationen vil altid have mangler – jeg tror ikke på, at du kan få alt med. Onde tunger vil her sige, at SCRUM netop sikrer, at kunden har mulighed for at tage stilling til krav løbende. Ja, ja, men det kan man jo også ved at udvikle traditionelt! Ved kravspecifikationen er der blot markant færre ting der skal afklares med kunden løbende, hvilket gør selve konstruktionsfasen væsentligt kortere og mere strømlinet.
Desuden sikrer kravspecifikationen et testgrundlag, da man binært kan angive “1” ved krav der er opfyldt, og “0” ved krav, der ikke er opfyldt. Ergo kan kvaliteten i højere grad sikres. Langt størstedelen af de webprojekter der igangsættes i Danmark er af så kort varighed (hvilket er under 6 måneder), at kundens situation eller krav næppe når at ændre sig betydeligt. Ofte opdeles projekterne alligevel i iterationer med selvstændige kravspecifikationer.
Så hvad kan vi lære af dette? Kravspecifikationen er ikke død! Kravspecifikationen lever i bedste velgående og aflives næppe af de agile metoder. Kravspecifikationen er et vigtigt element i ethvert forretningsorienteret webprojekt. Den synliggør økonomi, projektleverancer og skaber fælles forventninger mellem kunde og leverandør. Kravspecifikationen er til nytte både for kunden, projektlederen og udvikleren.