Sådan genvinder du god softwarekvalitet

Hvad er god softwarekvalitet?

Når vi taler om softwarekvalitet, er det åbenlyst, at én blandt mange forudsætninger for tilfredse kunder er, at den nyeste version af softwaren er komplet, færdig, testet og uden fejl. Men virkeligheden er bare ofte anderledes. Selv de største softwareleverandører kæmper med kvalitetsproblemer - også længe efter, at softwaren er gjort tilgængelig for kunderne.

Denne artikel handler om nogle af de bagvedliggende årsager til, at mange softwareleverandører er og bliver udfordret på kvaliteten. Artiklen giver dig desuden en praktisk vejledning i, hvordan du kan forbedre din softwarekvalitet ved at anvende det agile manifest som inspiration og fundament.

Læs artiklen herunder, eller download den som pdf her.

Forståelsen af begrebet kvalitet afhænger af øjnene, der ser

Forståelsen af ”god kvalitet” varierer afhængigt af, hvem du spørger. For slutbrugeren handler det ofte om en fejlfri oplevelse. For udvikleren handler det om, at koden er velstruktureret og let at vedligeholde, og at den overholder kodestandarden. For softwareleverandøren er god softwarekvalitet nøglen til øget kundetilfredshed og konkurrenceevne.

Forståelsen af begrebet kvalitet afhænger altså af øjnene, der ser, personens holdning til kvalitet og brugssituationen. Ofte har vi hørt en løsningsarkitekt eller en udvikler forklare, at softwaren virker, som den skal, nemlig i overensstemmelse med designet (”works as designed”). Samtidig oplever kunden og slutbrugeren, at den oplevede kvalitet ikke er god nok.

Lad os dykke ned i, hvordan vi kan opnå god softwarekvalitet gennem det agile manifest.

Det agile manifest tilbyder 4 værdier og 12 principper, der kan hjælpe dig med at tackle kvalitetsudfordringer og forbedre din softwarekvalitet.

De fire værdier i det agile manifest

  1. Individer og interaktioner frem for processer og værktøjer
  2. Fungerende software frem for omfattende dokumentation
  3. Kundesamarbejde frem for
    kontraktforhandling
  4. Reaktion på forandringer frem for at følge en plan

Kilde: https://agilemanifesto.org

De 12 principper bag det agile manifest

Princip 1 - Kundetilfredshed

Se mereSe mindre

Manifestet understreger, at vi skal levere værdifuld software løbende. Det er vigtigt at forstå, at ”kunden” ikke altid er slutbrugeren - i de tidlige faser er det ofte leverandørens Product Owner (PO), der repræsenterer kundens krav og forventninger. Dette er særligt vigtigt ved nye produkter eller teknologier, hvor vi skal teste konceptets værdi (PoC) og udvikle prototyper. Uden kundens input risikerer vi, at koden ikke skaber værdi eller slet ikke bliver brugt – uanset dens kvalitet.

Princip 2 - Ændringshåndtering

Se mereSe mindre

I modsætning til vandfaldsmodellen tillader det agile manifest, at nye krav opstår sent i processen, fordi kravene ofte forbedrer løsningen og øger kundetilfredsheden. Ignorerer teamet nye krav eller undlader at tilrette koden, mister softwaren relevans og risikerer at blive utilstrækkelig eller uhensigtsmæssig.

Princip 3 - Løbende leverancer

Se mereSe mindre

Agile teams leverer software hver 2.-4. uge, så kunden kan se og teste løsningen. Dette feedback loop sikrer, at kritiske fejl kan håndteres med det samme, og at forbedringer kan prioriteres. Forsømmer teamet at levere løbende, risikerer vi, at fejl hober sig op og skaber (større) problemer senere.

Princip 4 - Teamarbejde

Se mereSe mindre

Agile teams består af fagfolk fra IT og forretning, der arbejder tæt sammen om fælles mål. Teamets medlemmer løser opgaven sammen, og medlemmerne er gensidigt afhængige af hinanden. Gennem det daglige arbejde opnår teamet en fælles forståelse af opgaven og får flere perspektiver med ind i opgaveløsningen. Det nære og tætte samarbejde skaber transparens og flow i arbejdet. Hvis samarbejdet ikke fungerer godt, kan det føre til ineffektivitet og dårlig kvalitet. Et balanceret team, der kender og udnytter hinandens kompetencer, er afgørende.

Princip 5 - Motiverede teams

Se mereSe mindre

Motiverede, robuste og stabile teams trives med deres roller og arbejdet samt tager ansvar for egne produkter. Det øger deres ekspertise over tid. Robusthed opnås, når teamet er tværfunktionelt og komplet med overlappende kompetencer. I praksis er et team sjældent hverken robust eller stabilt over tid.

Når et medlem f.eks. skifter team, skal der sættes tid af til onboarding og omstrukturering. Men flyt hellere opgaver frem for mennesker og undgå ustabile og/eller (kompetencemæssigt) sårbare teams. Vi skal dog være forsigtige med at flytte rundt på fejlrettelser, for de skaber læring. Vi skal med andre ord sørge for, at teamet løser sine egne fejl for at undgå, at teamet gentager fejlen.

Princip 6 - Face-to-face kommunikation

Se mereSe mindre

Face-to-face kommunikation, som handler om direkte, personlige interaktioner, hvor medlemmerne af teamet engagerer sig verbalt og nonverbalt, er mest effektiv; men videomøder kan være nødvendige, når teamet samarbejder på distancen - og når mange benytter sig af hjemmearbejde.

Ofte er dialogen på videomøder forstummet, spontaniteten er væk, og taletiden er afmålt. Når vi mister dynamikken i dialogen, går vigtig oplæring, læring og aflæring samt innovation nemt tabt. Det kan påvirke vores virkelighedsopfattelse og kvaliteten af arbejdet samt skabe unødvendige fejl og misforståelser.

Princip 7 - Vi måler fremdrift med software, der virker

Se mereSe mindre

Fremdrift vurderes bedst med software, der virker. Men softwaren er først endeligt leveret, når den er dokumenteret og testet. Selvom dokumentations- og testarbejdet ofte opfattes som tidskrævende og kedeligt især blandt udviklere, er det nødvendigt for at sikre god kvalitet og overholdelse af lovgivning og intern governance. Dokumentations- og testarbejdet kan effektiviseres ved bl.a. at skrive selvforklarende kode og automatisere processerne til et vist niveau. Endelig kan arbejdet udføres af motiverede specialister med de rette kompetencer. I sidste ende er en MVP-løsning (1), der virker, altid bedre end en perfekt løsning, der fejler.

”De færreste udviklere finder dokumentation spændende, så vi skal være effektive i test- og dokumentationsarbejdet. Det kan vi bl.a. gøre ved at sikre sammenhæng mellem features, user stories og kode, bruge selvforklarende kode med passende kommentarer, teste i overensstemmelse med testcases og automatisere, hvor det giver mening.

Måske giver det også mening at overdrage dokumentationsopgaven til en kollega med et bedre kompetencematch. Og hvem ved - måske kan vi delvist automatisere dokumentationen. Til syvende og sidst er softwaren først færdig, når den er testet og accepteret af kunden.”

Lars Lindsby
Senior Consultant, Business Solutions & Services, kaastrup|andersen

Princip 8 - Konstant tempo

Se mereSe mindre

Et team skal kunne arbejde i et stabilt og kontrolleret tempo, som sikrer løbende leverancer og kvalitet uden overbelastning. Hvis tempoet falder, kan det skyldes manglende ressourcer eller sårbarhed i teamets sammensætning. Når det danske herrelandshold i håndbold er blandt verdens bedste, skyldes det ikke kun, at Danmark har nogle af verdens bedste håndboldspillere; men at holdet også har bredden.

Et agilt team er et tværfunktionelt team på typisk 5-10 dedikerede personer med alle de nødvendige kompetencer til at beskrive, designe, udvikle, teste, dokumentere og implementere applikationer. Hvis teamet skal have bredden og være robust, skal teamet have overlappende kompetencer, eller også skal teamet være større.

Princip 9 - Ekspertise

Se mereSe mindre

Kvalitet kræver godt håndværk Kvalitet kræver godt håndværk udført af eksperter, der arbejder effektivt. Hvis det agile team kæmper med at levere kvalitet, kan det skyldes, at teamet eller enkeltpersoner misforstår eller er uenige om, hvad godt håndværk er (”What good looks like”), og hvordan det udføres. Hvis vi som eksempel tager kodereview, er alle i teamet (også primadonnaerne) omfattet af processen. Formålet er at sikre en høj kodekvalitet, mens målet er, at koden er let at læse og logisk opbygget, at den følger kodestandarden og er genbrugelig osv. Kodereviewet skaber desuden dialog og en fælles forståelse (af det gode håndværk) samt læring (af nye vaner) og aflæring (af uvaner).

Princip 10 - Enkelthed

Se mereSe mindre

Teamet skal maksimere værdien af arbejdet ved at fokusere på de vigtigste opgaver og minimere spildtid. Det kræver prioritering og tillid til teamet, som skal have de rette rammer for at kunne levere effektivt. Det gør teamet ved at prioritere og fokusere på de væsentligste opgaver, udskyde de mindre vigtige opgaver og helt undgå unødvendigt arbejde samt levere den højeste værdi til kunderne (først).

Princippet foreslår også, at teamet skal have det miljø og den støtte, de har brug for, og at vi skal have tillid til, at teamet får arbejdet gjort. Endelig understreger princippet vigtigheden af, at teamet regelmæssigt reflekterer over, hvordan det bliver mere effektivt og justerer adfærden herefter, se princip 12.

”Vi er sikkert mange, der har en personlig præference for at lave løsninger, der er bedre end ”gode nok”; men det går ikke med gold plating (2). Vi bliver nødt til at forholde os til ”Definition of Done” (DoD). Vores features og user stories skal betragtes som ”Done” (færdige), når de er udført til det aftalte minimumsniveau af kvalitet (DoD).”

Lars Lindsby
Senior Consultant, Business Solutions & Services, kaastrup|andersen

Princip 11 - Selvorganisering

Se mereSe mindre

Det agile manifest understreger, at de bedste løsninger opstår fra selvorganiserede teams, hvor krav, design og arkitektur udvikler sig løbende i takt med ny viden. Denne autonomi giver teamet frihed til at beslutte, hvordan produktet leveres. Men manglende enighed om roller, ansvar og arbejdsmetoder kan føre til kvalitetstab. Hvis teamet ikke etablerer en fælles retning og best practices, kan det f.eks. resultere i alt for mange metoder, som gør vedligeholdelse af kodebasen vanskelig og kompromitterer kvaliteten.

Princip 12 - Refleksion og tilpasning

Se mereSe mindre

Det agile manifest opfordrer teamet til regelmæssigt at reflektere over dets arbejde for at øge effektiviteten - både i adfærd og metoder - med mindst mulig indsats. Et retrospective (3) bør ikke være et rutinemøde. Det afholdes, når der er væsentlige erfaringer at drøfte. Det er afgørende, at teamet konkret beslutter, hvad der i givet fald skal ændres, og hvem der følger op. Hvis teamet ikke giver sig tid til refleksion, kan det miste overblikket, og der er en risiko for, at kvaliteten falder.

Værdien af de agile værdier og principper

Vi håber, at du med udfoldelsen af hvert princip i det agile manifest er blevet beriget med nye måder, hvorpå du kan opnå højere softwarekvalitet.

Principperne giver en praktisk ramme for kontinuerlig levering, tæt samarbejde, løbende læring og kvalitetsfokus.

De fremmer det gode håndværk, hvilket reducerer fejl i og øger robustheden af softwaren. Værdierne skaber tilmed en kultur, hvor menneskelige interaktioner, samarbejde og fleksibilitet vægtes højere end stive processer og statiske planer. Det sikrer, at teams hurtigt kan reagere på ændringer og levere værdi til kunderne.

Hvorfor det betaler sig
At levere software af høj kvalitet er ikke kun en teknisk ambition, men en forretningsstrategi.
Formår du at håndtere kvalitetsproblemer proaktivt, opnår du:

  • Øget kundeloyalitet: Fejlfri software styrker kundetillid.
  • Reduktion i supportomkostninger: Mindre tid brugt på fejlfinding.
  • Hurtigere time-to-market: Smidigere udviklingsprocesser.
  • Forøget konkurrenceevne: Bedre produkter giver markedsfordele.

 

  1. MVP er en forkortelse for Minimal Viable Product, som er et levedygtigt produkt med nok funktionalitet til de første kunder.
  2. Gold plating forekommer, når teamet overleverer og f.eks. inkluderer ekstra funktionalitet.
  3. Retrospective handler om, at teamet ser tilbage på den seneste periode i projektet og spørger sig selv om, hvad der gik godt, hvad der gik galt, og hvordan teamet forbedrer sig.

Et skub i den rigtige retning

God softwarekvalitet er ikke en luksus - det er en nødvendighed. Ved at anvende det agile manifest kan du skabe en ramme, hvor din softwarekvalitet ikke kun lever op til kundernes forventninger, men overgår dem. Tøv ikke med at kontakte os - sammen kan vi sikre, at din software bliver en drivkraft for virksomhedens succes.

Sådan hjælper vi dig
Hos kaastrup|andersen hjælper vi virksomheder med at genskabe fokus på kvalitet gennem implementering af agile metoder.

Vi tilbyder:

  • Rådgivning om procesoptimering: Hjælp til at identificere og udbedre kvalitetsudfordringer.
  • Workshops i agil udvikling: Træning i de agile principper.
  • Målrettede kvalitetsløsninger: Design af skræddersyede strategier.

Kontakt os i dag, og lad os tage en uforpligtende snak om, hvordan vi kan hjælpe dig med at genvinder den gode softwarekvalitet og styrke din forretning.

Relateret viden

Ledelse og Metoder

VELUX A/S i Skjern står over for deres største lagerprojekt nogensinde – etableringen af et fælleslager
Ledelse og Metoder

Hvordan sikrer du, at din idé faktisk bliver til et produkt, der skaber værdi for dine kunder og forretningen?
Forandringsledelse

Grundfos opnår ISO 27001-certificering gennem strategisk samarbejde og forretningsfokuseret forandringsledelse

Kontakt os

Lars Glowienka

CSO
+45 70 27 77 19
Kontakt mig