Neem maar afscheid van technische schulden: agile oplossingen voor een gestroomlijnde ontwikkeling

Technische schuld is een concept in softwareontwikkeling dat de toekomstige kosten beschrijft van nu te kiezen voor een snelle of eenvoudige oplossing, in plaats van een betere maar meer tijdrovende aanpak. 

Wanneer ontwikkelaars prioriteit geven aan snelheid boven codekwaliteit, leidt dat tot suboptimale oplossingen die in de toekomst moeten worden geherstructureerd of verbeterd. Dit zorgt voor dubbel zoveel werk voor teams, waarbij hun budgetten, middelen en projecttijdlijnen worden verbruikt. 

Bijvoorbeeld door een verouderde bibliotheek te gebruiken omdat deze vertrouwd is of hardcoding waarden die configureerbaar zouden moeten zijn. Dit lijkt op dit moment misschien efficiënt, maar het leidt uiteindelijk tot dure herbewerkingen, zoals:

• Broze code herschrijven die niet meer werkt wanneer een gerelateerde functie verandert.

• Een module refactoren die niet is ontworpen om op te schalen met meer gebruikers of gegevens.

• Verouderde afhankelijkheden vervangen die geen beveiligingsupdates meer ontvangen.

• Nauw verbonden componenten duidelijker maken zodat functies onafhankelijk van elkaar kunnen worden ontwikkeld en geïmplementeerd.

Traditionele softwareontwikkelingsprogramma's volgen vaak een op fasen gebaseerde benadering voor ontwikkeling die bestaat uit: functieontwikkeling, alfa, bèta en golden master (GM).

Elke softwarerelease begint met een fase waarin nieuwe functies worden gebouwd en (idealiter) problemen die zijn overgebleven van de laatste release worden aangepakt.

• Alfa: wanneer elke functie is geïmplementeerd en klaar is om te worden getest. 

• Bèta: begint wanneer er genoeg bugs zijn verholpen om feedback van klanten mogelijk te maken. Helaas verschijnen er nieuwe bugs, terwijl het team nog bezig is om genoeg bugs op te lossen om de bèta-status te bereiken. Dit leidt tot technische schulden. Het is een chronisch geval van 'whack-a-mole' ('Mollen meppen'): los één bug op en er verschijnen twee nieuwe. 

• Geen openstaande bugs: dit wordt meestal bereikt door enkele bekende problemen op te lossen en de rest uit te stellen tot de volgende release. 

Door bugfixes uit te stellen, kunnen technische schulden zich opstapelen en escaleren. Naarmate de backlog groeit, wordt het moeilijker om deze aan te pakken. De ontwikkeling vertraagt, de tijdlijnen verschuiven en klanten hebben last van aanhoudende gebreken. In plaats van technische schulden uit de hand te laten lopen, kan het toepassen van agile praktijken een duurzamere aanpak bieden.

Een begrip hebben van technische schulden houdt in dat je erkent dat niet alle schulden gelijk zijn. De belangrijkste categorieën van technische schulden zijn onder meer: 

• Opzettelijke schuld: wanneer teams willens en wetens de kortst mogelijke weg nemen om deadlines te halen of functies sneller te leveren. Het is een bewuste beslissing waarbij ontwikkelaars begrijpen dat ze werk voor de toekomst creëren, maar kwantiteit verkiezen boven kwaliteit. 

• Onvoorziene schuld: slechte codekwaliteit kan onbedoeld voorkomen. Een ontwikkelaar kan de vereisten verkeerd interpreteren of het team heeft geen ervaring met een bepaalde technologie. Dit soort technische schulden komen voort uit onopzettelijke fouten in plaats van strategische keuzes. 

• Bitrot: zelfs goede code kan na verloop van tijd problematisch worden. Naarmate systemen ontwikkelen, afhankelijkheden veranderen en nieuwe functies worden toegevoegd, kan voorheen solide code verouderd raken of incompatibel worden met nieuwere componenten.

Teams stapelen technische schulden op om verschillende redenen, vaak zonder te beseffen dat het gebeurt. Veelvoorkomende oorzaken van technische schulden zijn onder andere: 

• Strakke deadlines: wanneer productmanagement aandringt op snellere levering, wordt er half werk geleverd. Snelle oplossingen vervangen de juiste oplossingen, waardoor schulden ontstaan die in de loop van de tijd toenemen. 

• Gebrek aan testen: als je de tests overslaat, bespaar je in eerste instantie misschien tijd, maar bugs die zich voordoen zorgen voor voortdurende onderhoudskosten die de toekomstige ontwikkeling vertragen. 

• Slechte communicatie: als agile projectmanagementpraktijken mislukken, kunnen ontwikkelaars de vereisten verkeerd begrijpen of veronderstellingen maken die tot herbewerking leiden. 

• Vaardigheidstekorten: teams die met onbekende technologieën werken, creëren vaak suboptimale oplossingen die verfijnd moeten worden zodra de expertise toeneemt. 

• Vereisten die veranderen: naarmate de productstrategie verandert, sluit code die ooit logisch was mogelijk niet langer aan bij de huidige visie, waardoor deze in feite een technische schuld wordt.

Het meest uitdagende deel van technische schulden is dat ze vaak pas zichtbaar worden zodra ze echte problemen beginnen te veroorzaken. Op dat moment loop je al achter. Gelukkig zijn er eenvoudige manieren om een schuld te identificeren voordat deze tot een serieus probleem leidt.

Dit zijn de meest effectieve methoden om technische schulden vroegtijdig te herkennen: 

• Codebeoordelingen: regelmatige peerreviews onthullen vaak gebieden waar de kortste weg werd genomen of de complexiteit tot boven het beheersbare niveau is gestegen. 

• Complexiteitsstatistieken: tools die de complexiteit van code meten, kunnen helpen bij het identificeren van problematische secties die aandacht vereisen. Een hoge cyclomatische complexiteit of diepgaande nesting duidt vaak op gebieden die klaar zijn voor refactoring. 

• Feedback van ontwikkelaars: teamleden die dagelijks aan de code werken, kunnen patronen en pijnpunten ontdekken die de statistieken misschien over het hoofd zien. Hun inzichten zijn van onschatbare waarde voor het herkennen van wrijvingspunten die het ontwikkelingsproces vertragen. 

• Prestatiebewaking: trage responstijden of pieken in het gebruik van hulpbronnen kunnen wijzen op onderliggende technische problemen die aandacht vereisen. 

Terugkerende bugs of onverwachte vertragingen duiden ook op verborgen schulden die de voortgang vertragen. Als steeds dezelfde problemen optreden of eenvoudige wijzigingen langer duren dan verwacht, is dat meestal een teken dat technische schulden invloed hebben op de snelheid van je team.

Of het nu gaat om snelle oplossingen binnen strakke deadlines, veranderende vereisten of verouderde systemen, de technische schulden kunnen zich opstapelen. En de kans is groot dat je een deel van deze schuld hebt opgebouwd als je met oude code hebt gewerkt. 

Deze tips helpen je echter bestaande schulden te beheren en stellen je team in staat zich te concentreren op leuke dingen, zoals de ontwikkeling van nieuwe functies. 

1. Stel een duidelijke definitie op van technische schulden

Soms zijn ontwikkelaars en productmanagers het oneens over waar technische schulden uit bestaan. Dus laten we de controverse hier een halt toeroepen:

Aan de ontwikkelingskant is er een verleiding om architectonisch werk te karakteriseren als technische schulden. Afhankelijk van de aard van de verandering, zoals het vervangen van een shortcut door de 'echte' oplossing versus het opsplitsen van een monolithische codebasis in microservices, kan het al dan niet om technische schulden gaan.

Aan de andere kant voelt productbeheer vaak meer urgentie rond het bouwen van nieuwe functies dan voor het oplossen van bugs of trage prestaties. 

Om te voorkomen dat beide partijen afgestompt raken, moet iedereen het onderscheid begrijpen tussen technische schulden, gewenste architectonische veranderingen in de codebase en nieuwe functies. Duidelijke communicatie tussen ontwikkeling en productmanagement is net zo belangrijk om backlogs te prioriteren en de codebase te ontwikkelen. 

2. Integreer testen in je workflow

Zorg ervoor dat testen is geïntegreerd in de initiële ontwikkelingscyclus om vroege issues te identificeren en aan te pakken. Begin met het opstellen van een duidelijke definitie van Gereed en vermijd het uitstellen van testen. 

Definieer 'gereed' niet alleen als een voltooide functionaliteit, maar ook als getest en klaar voor release. Dit betekent dat je een aparte testtaak moet toevoegen aan de oorspronkelijke userstory. Als tests niet worden uitgevoerd als onderdeel van de oorspronkelijke story of bugfix, is de oorspronkelijke story of bugfix niet gereed. 

Het is te eenvoudig om ze uit te stellen en dat nodigt alleen uit tot technische schulden.

3. Bugs automatisch wegwerken

Wanneer iemand een bug in de software ontdekt, neem dan de tijd om een geautomatiseerde test toe te voegen die dit aantoont. Zodra de bug is verholpen, voer je de test opnieuw uit om te controleren dat deze slaagt. 

Dit is de kern van testgestuurde ontwikkeling, een aloude methodologie voor het handhaven van kwaliteit in agile ontwikkeling.

Het veranderen van de filosofie van het team (en die van de belanghebbenden van het team) over het beheren van technische schulden is niet eenvoudig. Soms heeft het verkorten van de ontwikkelingstijd om eerder op de markt te komen voorrang. Laten we dat in gedachten houden en vervolgens enkele actie-items samenvatten voor het indammen van technische schulden:

• Informeer de producteigenaar over de werkelijke kosten van technische schulden: zorg ervoor dat de waarden van storypoints kloppen voor toekomstige story's waarvoor bestaande technische schulden opgelost moeten zijn.

• Moduleer je architectuur: neem een krachtig standpunt in ten aanzien van technische schulden in nieuwe componenten of bibliotheken in de applicatie. Zodra flexibiliteit zichtbaar is in deze nieuwe componenten, willen teams die praktijken natuurlijk uitbreiden naar andere delen van de code.

• Schrijf geautomatiseerde tests: niets voorkomt bugs beter dan geautomatiseerde tests en continue integratie. Wanneer een nieuwe bug wordt gevonden, schrijf je een nieuwe test om deze te reproduceren en het probleem op te lossen. Als die bug ooit weer opduikt, zal de geautomatiseerde test deze opvangen voordat klanten deze kunnen zien.

Het concept van technische schulden kan worden geïllustreerd aan de hand van een paar eenvoudige voorbeelden:

Stel je eens een team voor dat databaseverbindingen heeft gecodeerd in plaats van een configuratiesysteem te gebruiken. Dit bespaart in eerste instantie tijd, maar veroorzaakt problemen bij de implementatie in verschillende omgevingen. 

Een ander voorbeeld is het overslaan van de juiste foutafhandeling om een deadline te halen, waardoor het systeem kwetsbaar wordt voor crashes die later noodoplossingen vereisen. 

Goed schuldbeheer kan betekenen dat je bewust kiest voor een eenvoudiger algoritme dat gemakkelijker te begrijpen en te onderhouden is, zelfs als het iets minder efficiënt is. Slecht beheer daarentegen bestaat uit het stapelen van meerdere tijdelijke oplossingen zonder de onderliggende oorzaak aan te pakken. 

Teams kunnen Jira gebruiken om technische schulden bij te houden, te prioriteren en aan te pakken, naast regulier functiewerk. Maak specifieke issuetypen voor technische schuldenposten en neem ze op in je reguliere sprintplanningsproces. 

Gebruik functies voor resourceplanning om tijd vrij te maken voor vermindering van schulden en maak gebruik van tools voor resourcebeheer om processen bij te houden. Stel workflows in die technische schulden zichtbaar maken voor alle belanghebbenden, niet alleen voor ontwikkelaars. 

Met Rovo Dev kunnen teams nog verder gaan door AI te gebruiken om routinematige coderingstaken te automatiseren en refactoring te versnellen. Rovo Dev kan workflows in meerdere stappen genereren, kennis opdoen en code op grotere schaal plannen, genereren en beoordelen. Door minder handmatig werk te hoeven doen om technische schulden te identificeren, te plannen en aan te pakken, helpt Rovo Dev teams om sneller software van hogere kwaliteit te leveren.

Deze transparantie helpt productmanagers inzicht te krijgen in de werkelijke kosten van opgebouwde schulden en maakt het eenvoudiger om de tijd die aan onderhoudswerkzaamheden wordt besteed te rechtvaardigen. 

Jira proberen

Wat zijn technische schulden in scrum?

In scrum zijn technische schulden werk dat gedaan moet worden om de kwaliteit van de code en de gezondheid van het systeem te behouden. Scrum-teams pakken dit aan door schuldposten op te nemen in sprintbacklogs en ze met dezelfde prioriteit te behandelen als ander werk. 

Hoe kun je technische schulden voorkomen?

De preventie van technische schulden begint met een goede planning, regelmatige peer reviews en geautomatiseerde tests. Door een cultuur op te bouwen waarin codekwaliteit op lange termijn belangrijker is dan snelheid op korte termijn, kunnen teams vanaf het begin betere architectuurbeslissingen nemen. 

Zijn technische schulden altijd slecht?

Niet per se. Strategische technische schulden kunnen acceptabel zijn als teams om geldige zakelijke redenen bewust snelheid verkiezen boven perfectie. De sleutel is om het opzettelijk te beheren in plaats van het per ongeluk te laten ophopen.

Wie betaalt de technische schulden?

Iedereen betaalt voor technische schulden. Technische teams besteden meer tijd aan onderhoud, terwijl productteams tragere functies leveren en klanten meer bugs tegenkomen. Zowel belanghebbenden op het gebied van engineering als op het gebied van producten delen de verantwoordelijkheid voor het effectief beheren van schulden. 

Hoe meet je technische schulden?

Gebruik tools zoals Jira om schuldposten bij te houden, de afwikkelingstijd te meten en trends te volgen. Regelmatige code-audits, complexiteitsstatistieken en enquêtes voor ontwikkelaars kunnen helpen om de scope en impact van opgebouwde schulden te kwantificeren.