Hoe technische schulden beheren tijdens ontwikkeling?

Wat is technische schuld?

Technische schuld is een fenomeen dat kan worden gedefinieerd als de opeenstapeling van tijd en moeite die wordt besteed aan het bouwen van software die niet zo goed is als het had kunnen zijn, of in ieder geval zo goed als het zou zijn geweest als de software door iemand anders was gebouwd . Het is een klassiek voorbeeld van ’tijdverspilling’. Het gebeurt vaak omdat ontwikkelaars niet op de hoogte zijn van al hun mogelijkheden om hun code te verbeteren voordat ze deze bouwen.

Technische schuld is elke vorm van kosten die worden gemaakt als gevolg van een slechte planning, slechte ontwerpbeslissingen of andere problemen met de code zelf. Kortom: het is alles waar je later problemen mee kunt krijgen.

En hier wordt het interessant: technische schulden lopen niet alleen op in de loop van de tijd; het kan in uw voordeel worden gebruikt met de juiste beheerstrategieën!

Waarom technische schuld identificeren?

Het identificeren van technische schulden is om verschillende redenen essentieel. Het helpt ontwikkelaars te begrijpen welke delen van hun code de moeite waard zijn om meer tijd te investeren in optimalisatie. Dit kan hen helpen zich te concentreren op die onderdelen en voorkomen dat ze tijd verspillen aan optimalisaties die geen grote voordelen opleveren.

Moet het niet worden vastgelegd als defecten en bugs?

In veel gevallen wordt technische schuld niet gezien als defecten of bugs omdat er geen tools of technieken beschikbaar zijn waarmee ontwikkelaars in verschillende organisaties definitief over dit concept kunnen communiceren met herhaalbare resultaten.

Hoewel technische schuld lange tijd negatief in verband is gebracht, is dit niet noodzakelijkerwijs het gevolg van persoonlijke tekortkomingen van het technische team. Dit kan beter worden begrepen met Martin Fowler’s Technical Debt Quadrants.

Hier zijn een paar stappen die u effectief op het goede spoor moeten zetten om technische schulden te beheren:

1. Volgen

Een goede manier om technische schulden te beheren, is door deze te volgen. En er zijn veel manieren waarop we dat kunnen doen. Traceren, plannen en schatten zijn de drie belangrijkste stappen in het technische schuldproces. Meestal zal tracking de eerste stap zijn, omdat we niet meteen aan alle technische schulden zouden beginnen. De reden om iedereen in een emmer te houden, is dat de technische schuld op verschillende manieren wordt geïdentificeerd of door verschillende mensen die code beoordelen, zodat er niets kan worden gemist. Het helpt ons ook bij verdere activiteiten, zoals het bijwerken van inspanningen, het stellen van prioriteiten en het volgen van de status. Natuurlijk zijn er veel tools die we kunnen gebruiken voor tracking, maar gebruik gewoon de tools die momenteel voor uw project worden gebruikt. Als je bijvoorbeeld Jira gebruikt, maak dan een kaart aan voor de technische schuld in de backlog/productlog.

2. Plannen

Bepaal voor planningsdoeleinden wat er moet gebeuren in de huidige sprint of in de komende sprint. We kunnen onze huidige sprint opnemen om de volgende redenen:

• Geef in de huidige sprint altijd prioriteit aan beveiligingsgerelateerde factoren. Dit omvat zowel beveiligingsproblemen als prestatieproblemen.
• Als de schuld van invloed is op de productie of op andere modules van uw product (bijvoorbeeld gegevensintegriteit), moet deze worden opgenomen in de huidige sprint.
• Als het team hun sprintdoel voor tijd heeft voltooid, onderzoek dan technische schuldprioriteiten die van invloed zijn op uw sprintdoel.
• Als de technische schuld relevant is voor de huidige werkmodule, zou dit geen invloed moeten hebben op uw sprintdoel.
• Als de schulden gerelateerd zijn aan coderefactoring, leesbaarheid en optimalisatie, kunnen ze in de komende sprint worden gepland.

3. Schatting en beschikbaarheid van middelen

• Bespreek voordat u een taak toewijst met elke ontwikkelaar die eerder aan de module heeft gewerkt en identificeer de impact voordat u uren/dagen schat.
• Bekijk de huidige werktaak en pijplijn van de ontwikkelaar en beslis wie kan worden uitgekozen voor een nieuwe taak.

4. Identificeer de impact op het huidige sprintdoel

Als een sprint wordt gestart met bepaalde doelen, maar tegen het einde van de sprint, als we problemen ondervinden bij het leveren van onze deliverables vanwege nieuwe opgenomen schulden die aanvankelijk niet in het sprintplan stonden, dan kun je beslissen welke moeten worden verplaatst naar de volgende sprint volgens zijn gewicht.

Volg deze stappen om te identificeren de gevolgen:

• Stap 1: Het gewicht van de schuld die in de huidige sprint is gekozen.
• Stap 2: Vergelijk de schuldweging met items die in de huidige situatie beschikbaar zijn
• Stap 3: Bepaal de lijst met items die niet worden geleverd.
• Stap 4: Haal die items uit de sprint en verplaats ze naar de backlog.

5. Publiceer sprintresultaten in scrummeeting (producteigenaar, scrummaster en ontwikkelaars)

Om ervoor te zorgen dat iedereen in dezelfde lijn zit, publiceert u het plan met de volgende details:

• Hoeveel artikelen zijn
• Hoeveel items niet
• Reden doelwijzigingen.
• De actiepunten voor niet geleverde artikelen.
• De voordelen van doelveranderingen en hoe deze waarde aan het product hebben toegevoegd.

Bevestig ten slotte de doelwijzigingen met de producteigenaar voordat u eraan gaat werken.

6. Laten we aan de schulden gaan werken.

Hoewel dit de laatste stap is in het beheren van schulden, is het de eerste stap voor ontwikkelaars om aan de schulden te gaan werken. Wees ijverig bij het bijhouden van alle taken die onvoltooid blijven – of ze nu groot of klein zijn, ze dragen allemaal bij aan het totale bedrag aan technische schulden voor uw project.

Technische schulden kunnen leiden tot onvolledige functionaliteit en vertraagde releases, waardoor uw team de geloofwaardigheid bij klanten en belanghebbenden kan verliezen.

Wat gebeurt er als u niet voor technische schulden zorgt?

Het wordt groter en duurder om te repareren. Als uw technische schuld onbeheersbaar wordt, kan dit het zelfs moeilijker maken voor iedereen in uw team, niet alleen voor de ontwikkelaars die aan elk stuk code werken (of de gebruikers die het proberen te gebruiken).

Welke tool(s) je ook kiest, er gaat niets boven persoonlijke communicatie tussen ontwikkelaars en QA-mensen die de impact van elk item begrijpen – en zorg ervoor dat iedereen weet wie wat moet doen. Dit helpt ook om betere communicatie, empathie en transparantie tussen product- en engineeringteams te creëren en het proces op de lange termijn te stroomlijnen.

Deze blog is mede geschreven door Ashok Maruthamuthu, Technisch hoofd bij Zuci Systems. Ashok heeft uitgebreide ervaring met het afhandelen van technische schulden bij verschillende projecten.

Heb je vragen? Schrijf ons hier.

Andere interessante artikelen voor u:

Spaghetticode komt voort uit slecht technisch leiderschap

Nadeel van het ontbreken van een formeel feedbacksysteem voor defectanalyse