Truende fiasko vendt til succes: Sådan lugede KMD 3 ud af 4 softwarefejl væk i monsterprojekt

KMD's store Opera-system var ramt af alvorlige problemer med for mange fejl. Men en analyse af projektet viste, hvor problemet lå, og så blev skuden vendt.

Fejlene hobede sig op, og det var ved at give alvorlige problemer for udviklingen af KMD’s store kommunale it-system Opera.

»Vi kunne se, at det ikke hang sammen. Så der skulle ske noget, og vi blev enige om at få undersøgt, om vores processer var optimale,« forklarer projektchef Kim Bjørkquist, der var en af de ansvarlige for at få Opera tilbage på ret kurs.

Systemet er det økonomiske centralnervesystem hos de kommuner, som bruger det, og med over tusind komponenter og integration til et væld af forskellige andre it-systemer, er det en kompleks størrelse, som ikke er nem at overskue.

Den almindelige opfattelse på projektet var derfor forkert: At antallet af uløste fejl steg, fordi kvalitetskontrollen til sidst i processen ikke var god nok.

»Når man laver applikationsudvikling, og det er fejlbehæftet, som det var en overgang med Opera, så skyder man lynhurtigt skylden på testerne. Men problemet var et andet sted, som undersøgelsen viste,« siger Kim Bjørkquist til Version2.

Analyserede 200 fejl

Med hjælp fra proceskonsulent Jakob Føns fra SQA Consult blev årsagen til 200 fejl undersøgt, og resultatet var entydigt: 80 procent af fejlene, som skulle bekæmpes på sidste trin i processen, var lokale håndværksmæssige fejl, der var opstået helt tilbage i første trin, hvor udviklerne skriver de enkelte kode-bidder.

Det var altså ikke den komplicerede integration, der drillede, men fejl som kunne nedbringes helt fra starten af, hvis udviklerne designede og testede deres egen kode mere omhyggeligt, inden den røg videre i systemet.

»De fleste udviklere var meget overraskede. Nogle tog det til sig med det samme, andre var mere ’nej, det kan ikke være rigtigt’. Men vi havde fundet ud af, hvor vi skulle tage fat. Tidligere havde indsatsen været mere i blinde,« siger Kim Bjørkquist.

Omstillingen blev en gigantisk succes. Fra sommeren 2011 til slutningen af 2011 blev antallet af fejl i koden nedbragt til under det halve. Og samtidigt steg produktiviteten til over det dobbelte, så fejltætheden faktisk er faldet til under en fjerdedel af før.

»Resultaterne er jo helt fantastiske. Jeg er meget overrasket over, at man kunne opnå så signifikant en gevinst,« siger Kim Bjørkquist, der ikke længere er tilknyttet Opera, men er rykket videre til et nyt projekt.

Prekær omstilling

Men vejen til langt bedre kode var ikke bare at tromle på med krav til udviklerne.

»Resultatet af analysen gjorde, at omstillingen blev prekær. Vi ramte et sted, hvor ingen troede, vi havde et issue, og det gav en lille hurdle, vi skulle over. Så vi skulle lige snakke om det, og det er jo helt naturligt,« siger Kim Bjørkquist.

Første fase i omstillingen var derfor rent frivillig. Udviklerne blev klædt bedre på til at teste deres kode grundigere, og først senere kom der mere faste krav.

»Vi nåede heldigvis rigtig langt med frivillighedens vej alene. Nogle unit-testede jo også allerede deres kode selv, så for dem var forskellen ikke så stor, mens andre kun testede lidt, og nogle slet ikke. Så for dem var det en omstilling. Der vil altid være nogle, som tænker ’mit arbejde er godt nok, som det er’,« siger projektchefen.

Analysen af projektet viste også, at kommunikationen mellem de forskellige grupper på projektet ikke var god, fordi der blev brugt den klassiske vandfaldsmodel, hvor man udvikler ud fra en skreven kravspecifikation.

Blandt andet af den grund skiftede man over til agil udvikling med Scrum-metoden, hvor processen er meget mere fleksibel.

»En nedskrevet specifikation er en meget ineffektiv måde at kommunikere på. Uanset hvor godt du skriver det, vil det altid kunne misforstås. Med Scrum sker vidensudvekslingen derfor face-to-face,« forklarer konsulent Jakob Føns.

Med de store forbedringer i produktiviteten og fejlraten har arbejdet med at skifte samarbejdsmetode og styrke unit-testing betalt sig hjem på et halvt år, vurderer Kim Bjørkquist, som anbefaler alle store projekter at få sat fokus på, hvor det kan gå galt i processen.

Og det smukke ved at fokusere på at forebygge fejl er, at det kun gør processen billigere, lyder det fra Jakob Føns.

»Når man taler om bedre kvalitet, tror mange, at det så må koste flere penge. Men sådan er det ikke, hvis du kan undgå fejl fra starten af, ved at arbejde med forebyggelse i frem for test. Det er tankevækkende,« siger han.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Henrik Snog

»Når man laver applikationsudvikling, og det er fejlbehæftet, som det var en overgang med Opera, så skyder man lynhurtigt skylden på testerne. Men problemet var et andet sted, som undersøgelsen viste,« siger Kim Bjørkquist til Version2.

Hvad er det for en metode hvor testerne får lov til at fylde fejl i applikationen? Ellers er det i hvert fald lidt unfair at beskylde dem for fejlene.

  • 0
  • 0
#5 Steen Klingenberg

Jeg anerkender værdien af face2face kommunikation og SCRUM og det er besnærende at blive enige om at dokumentation er mindre vigtigt :-) MEN, hvis man erkender at udviklingstiden kun udgør en lille del af TCO, tidsmæssigt og økonomisk, kan det være risikabelt ikke at fastholde kravene (og eks. design/arkitektur - different story) skriftligt! Omkostningerne og risici ifm. vedligehold (udbygning, fejlretning, migrering/refaktoreringer...) kan stige betragteligt hvis dem som skal udføre vedligeholdelsen intet håndgribeligt har ud over kodebasen og forhåbentligt et test setup :-)

  • 0
  • 0
Log ind eller Opret konto for at kommentere