Ny Borger.dk er barn af Scrum - tjek selv, hvor god koden er
»Det er smukt. Når jeg betragter infrastrukturen, så synes jeg faktisk, den er blevet smuk,« siger Rasmus Espholm til Version2.
Han er programleder for den nye version af Borger.dk, arbejder hos Digitaliseringsstyrelsen og er mildest talt godt tilfreds med resultatet. Han giver en stor del af æren til et tæt samarbejde med leverandøren NNIT.
»Vi lærer meget mere som kunde, ved at arbejde på den her måde. Vi har en langt mere detaljeret forståelse af, hvad vi har købt og fået leveret,« siger Rasmus Espholm til Version2.
Den traditionelle måde at udvikle it-projekter på, hvor kunden groft fortalt sender en ordre og modtager et produkt noget tid senere, har man droppet. I stedet for benyttede man udviklingsmodellen Scrum.
Scrum er kendt for at være utrolig fleksibel. Man revurderer og hele tiden projektet i samarbejde med kunden. Man arbejder nemlig i såkaldte sprints, hvor man beslutter sig for en funktion, der skal laves, hvorefter man bruger to uger på det. Når sprintet er færdigt, ser man på, om funktionen lever op til definitionen af færdigt.

På den måde har man hele tiden styr på hvor langt man er og produktet bliver udviklet i takt med, at man får en bedre teknisk forståelse af det. Der opstår sjældent misforståelser mellem kunde og leverandør.
Men når man ikke fra begyndelses har en fuldstændigt prædefineret produktbeskrivelse, betyder det at kunden er nødt til at være involveret i hele forløbet. Derfor har NNIT og Digitaliseringsstyrelsen delt kontorer tre dage om ugen.
»Der er en høj grad af gennemsigtighed i det. Kunden kan jo følge med og se alt hvad vi laver. Der er ingen hemmelighedskræmmerier. Vi spiller med åbne kort,« siger Thomas Søby Ingwersen, lead developer på projektet.
Langt mere kundekontrol
For Rasmus Espholm har den største gevinst være kontrol over kvaliteten.
»Selvfølgelig kan det være nødvendigt nogle gange at springe over hvor gærdet er lavest. Men det er vigtigt, at man tager den beslutning sammen med kunden, og det gør man med Scrum. Hvorimod man med en fast kontrakt kan risikere, at leverandøren laver noget juks, fordi de har travlt,« forklarer Rasmus Espholm.

Det har været særlig vigtigt, at Borger.dk's kode blev af høj kvalitet, da der er krav om at koden skal kunne genbruges til andre portaler. Derfor bliver projektet også udgivet under open source-licens, hvilket i hvert fald ikke har gjort koden dårligere.
»Det holder en lidt til ilden, fordi det, man laver, jo skal kunne tåle at se dagens lys,« siger Thomas Søby Ingwersen.
Artiklen er skrevet som led i Version2's Sommertour 2012, hvor redaktionen sommeren igennem besøger it-virksomheder og rapporterer om medarbejdernes dagligdag og virksomhedens projekter. Se den samlede tour-plan her., hvor du også har mulighed for at stille spørgsmål til de besøgte virksomheder.
Kommentarer (15)
Jeg gætter på de 5 til venstre er projektledelse og de 5 til højre, er dem som har kodet og designet ;)
Jeg er selv scrum udøver og er glad for måden at håndtere kompleksiteten i et software projekt på. Men at kodekvaliteten automatisk skulle blive forhøjet, har jeg svært ved at se. Den er snarere orthogonal med scrum. Ligger der andre teknikker til grund for den forhøjede kvalitet, f.eks tdd eller parprogrammering?
Flot klaret - ros herfra.
Og cool med alle de Lego-minifig magneter :-)
/ Carsten
Når nu overskriften opfordrer til selv at tage et kig på kildekoden, kunne artiklen så ikke også inkludere et link til hvor man kunen finde den henne?
Jeg er da nysgerrig for at se om der er noget jeg kan bidrage med, men kan ikke umiddelbart se nogen links til hvor koden bliver publiceret?
Er der et public read-only repos man kan pulle fra?
Eller kommer koden ud et andet sted?
Det kunne have været sejt hvis der var et "Fork me on GitHub" banner i det ene hjørne af siden, men det kommer næppe til at ske...
Det havde bestemt været en god ide. Imidlertid blev vi ramt af ferien inden vi var helt klar til at ligge kildekoden på softwarebørsen så vi må vende tilbage på den front på den anden side af sommeren.
Jeg regner desuden med at anvende MPL i den forbindelse.
Det er rigtigt - lang tid tager det ikke. Vi vil imidlertid gerne nå at foretage review af dokumentationen først - den har selvfølgelig været en del af DOD, men en grundig gennemgang af det samlede resultat har vi ikke haft lejlighed til at gennemføre endnu.
nå at foretage review af dokumentationen først
Tja, tjo .. Det er jo også en af den slags ting man kan forbedre løbende? :)
Hvis jeg bare gerne vil snuse lidt rundt i koden behøver jeg jo ikke et fuldt dokumenteret system. I kan jo åbne op og vedlægge en readme der forklarer at I stadigvæk mener at I har en opgave i at få modnet dokumentationen - eventuelt kunne I også vedlægge en email adresse så I kan modtage feedback på hvilke områder af systemet der er særligt svære at sætte sig ind i - kun på baggrund af kildekoden.
Jeg ville i hvert fald gerne have et system med lidt manglende dokumentation, frem for et system der aldrig bliver offentliggjort fordi dokumentationen ikke bliver helt god nok - det vil højest sandsynligt også give et incitament til at få den sidste krølle på dokumentationen hvis man føler at man har interessenter der venter på ens leverance.

