Teknisk gæld i specialudviklede it-systemer er mere reglen end undtagelsen. Tricket er at afvikle gælden i tide. Også selvom deadline er højeste prioritet. Hvilken afdragsmodel vælger du?
Når du får specialudviklet et it-system, kan du få it-systemet skræddersyet til forretningen. Dette kan være attraktivt for at honorere forretningens særbehov, der ikke let lader sig løse med standardsystemer.
Men en del af prisen er teknisk gæld.
Teknisk gæld i specialudviklede it-systemer er dog ikke nødvendigvis et problem.
Til sammenligning er økonomisk gæld i form af fx realkreditlån i en bolig heller ikke nødvendigvis et problem. Gælden kan være en fornuftig vej til at anskaffe sig den rigtige bolig. Om gælden er et problem, afhænger primært af skyldnerens evne til at betale omkostninger og afdrag.
Dette gælder også teknisk it-gæld.
Teknisk gæld er en naturlig konsekvens af nogle af de kompromiser, der kan bringe systemet i mål til tiden. Det kan du læse mere om i denne artikel:
”Teknisk gæld? Men it-systemet er jo sprit-nyt!”
Men du bør undgå, at den tekniske gæld hober sig op og bliver en klods om benet.
Situationen opstår, når den tekniske gæld ikke er en prioriteret del af udviklingsindsatsen. Den tekniske gæld afdrages dermed ikke.
Konsekvensen er, at den tekniske gæld i specialudviklede it-systemer stiger i takt med udviklingen af ny funktionalitet. Og udviklingsteamet afdrager kun på den tekniske gæld, når dette er tvingende nødvendigt. Fx for at kunne indføre ny funktionalitet, der kræver væsentlige rettelser i eksisterende kode. Men afraget har et så begrænset omfang, at den tekniske gæld hober sig op.
Princippet med akkumuleret teknisk gæld er skitseret på figuren.
Så hvordan kan du holde den tekniske gæld bedre under kontrol?
Nedenfor præsenteres to modeller til prioriteret afdrag af teknisk gæld med hver sin afdragsprofil.
Løbende afdrag på teknisk gæld
Du kan vælge at afdrage løbende, se figuren.
Dette er den fornuftige afdragsmodel, hvor indsatsen med at afdrage på teknisk gæld i specialudviklede it-systemer prioriteres på lige fod med ny funktionalitet.
Modellen egner sig særligt godt til agile projekter, der releaser løbende og anvender høj grad af automatiseret test.
Udviklingsteamet sikrer, at den tekniske gæld dokumenteres og er synlig som oprydningsopgaver på backloggen. Og product owner kan i samarbejde med udviklingsteamet sikre, at disse løbende prioriteres i de enkelte sprints.
Udviklingsteamet og product owner har dermed løbende føling med den tekniske gæld og undgår, at gælden hober sig op.
Men modellen bliver ofte anset for mere idealistisk end realistisk. . Selv i agile projekter med løbende releases kommer prioriteringen ofte under pres med henblik på at øge værdien for forretningen. Her må afdrag af teknisk gæld ofte vige for mere funktionalitet.
Afdragsfrihed på teknisk gæld indtil release
En mere realistisk afdragsmodel er at planlægge med afdragsfrihed indtil en release af it-systemet. Og derefter planlægge med øget afdrag på den tekniske gæld.
Modellen tilgodeser, at forretningens udviklingskrav i en periode har højere prioritet end teknisk gæld. Som konsekvens øges den tekniske gæld i perioden med afdragsfrihed.
Herefter reduceres den tekniske gæld i det specialudviklede it-system i takt med, at afdrag på den tekniske gæld har højere prioritet end funktionelle udvidelser.
Hvad skal der til for at bevare kontrollen over teknisk gæld?
For at få succes med at holde den tekniske gæld i specialudviklede it-systemer under kontrol kan du som:
- Aftale en hensigtsmæssig afdragsmodel med udviklingsteamet. Dvs. om den tekniske gæld, der opstår i udviklingsforløbet, løbende skal afdrages – eller om du foretrækker perioder med afdragsfrihed.
- Stille krav til udviklingsteamet om løbende at synliggøre den tekniske gæld overfor dig som systemejer eller product owner. Den, der betaler, har også krav på at kende omkostningen ved de valgte kompromiser.
- Efterspørge. Det kan fx være designbeslutninger, der øger den kodemæssige kompleksitet eller bryder med tidligere arkitekturvalg. Det er dig som systemejer eller product owner, der skal beslutte om kompromisets konsekvenser for teknisk gæld står mål med fordelene i form af fx øget fremdrift. Du kan i denne situation med fordel efterspørge flere løsningsforslag. Det vil gøre det lettere for dig at sammenligne fordele og ulemper og vælge det rigtige kompromis.
- Løbende måle på den tekniske gæld, fx ved automatisk eller med manuelle stikprøver at måle på kvaliteten af kildekoden.
- Sikre at der oprettes oprydningsopgaver i backloggen, der synliggør den tekniske gæld.
- Sikre automatiseret test af it-systemet. Dette vil øge muligheden for at kunne gennemføre de nødvendige ændringer i kildekoden uden at dette introducerer unødig risiko for fejl i systemet. Uden automatiseret test vil testbyrden ved at afdrage på den tekniske gæld kunne blive uforholdsmæssig dyr.
