Christiaan Verwijs
Christiaan Verwijs Agile Coach en Software Developer
| 0 reactie(s)

4 tips om beter om te gaan met technische schuld in Scrum

Technische schuld

Technische schuld, of Technical debt, is één van de grootste frustraties van de Development Teams waar ik mee werk. Als je om voorbeelden vraagt van technische schuld, steken de meeste teams meteen van wal. Met ‘technische schuld’ doel ik dan op workarounds, code die moeilijk te lezen is, ‘tijdelijke’ oplossingen en andere hacks die op korte termijn een probleem oplossen, maar op langere termijn voor hoofdpijn zorgen. Development Teams zijn zich zeer bewust van de opbouw van technische schuld, maar voelen zich vaak machteloos om er wat aan te doen. Het lukt ze niet om goed uit te leggen waarom het bestrijden en voorkomen van technische schuld een belangrijk aandachtspunt is bij productontwikkeling. Het gevoel  is vooral dat het management de voorkeur blijft geven aan nieuwe features boven kwaliteit.

In deze post geef ik je vier praktische tips om technische schuld transparant te maken, en hoe je je organisatie helpt om een betere balans te treffen tussen code kwaliteit en nieuwe features.

1. Maak gebruik van krachtige metaforen

‘Technische schuld’ is een krachtige metafoor. Zet het ook zo in. De consequentie van hacks, work-arounds die ‘nu snel een probleem oplossen, maar later hoofdpijn veroorzaken’ is abstract en moeilijk te begrijpen voor niet-developers. Ze hebben simpelweg geen mentaal model om te begrijpen wat ‘technische schuld’ is en wat het veroorzaakt. Het constant benadrukken dat ‘X verbeterd zou moeten worden’ of dat ‘Y slechte code’ is, gaat hier niet helpen. Het zorgt er eerder voor dat dat je wordt weggezet als ‘die gast die altijd loopt te mopperen’.

Metaforen zorgen voor begrip omdat ze een mentaal model bieden. ‘Technische schuld’ is zo’n metafoor. Oorspronkelijk bedacht door Ward Cunningham, en verder uitgewerkt door Martin Fowler, stelt het het schrijven van code van lage kwaliteit gelijk aan het opbouwen van een financiële schuld. Technische schuld bouwt op wanneer slechte code wordt geschreven vanuit de gedachte om het later te verbeteren. Omdat code slecht te lezen is, buggy in elkaar steekt of niet goed getest is, zorgt het ervoor dat je rente gaat betalen over deze code. Rente die bestaat uit vertraging, bugs en verloren tijd. En net als bij een financiële schuld stapelen de gevolgen van deze rente zich op. Totdat je alleen nog maar rente aan het betalen bent. Alle tijd gaat dan naar het oplossen van bugs, het doorgronden van moeilijk leesbare code, het dichten van security holes en het oplossen van performance-problemen. Natuurlijk accepteren we soms een mate van technische schuld, en nemen we de rente voor lief, maar dat moeten we meestal niet willen. Of de rente moet tenminste zo snel mogelijk weer worden terugbetaald. De volgende visualisatie illustreert het gevolg van technische schuld dan ook uitstekend:

2. Neem verantwoordelijkheid als Development Team

Soms voelen Development Teams zich slachtoffer van de wijze waarop het management aan de ene kant de prioriteit blijft geven aan nieuwe features boven het bestrijden van technische schuld, terwijl het team aan de andere kant wel de schuld krijgt van bugs, performance-problemen en steeds tragere ontwikkeling.

Een belangrijke eerste stap is om uit de slachtofferrol te stappen. Neem als Development Team de verantwoordelijkheid over het voorkomen en bestrijden van technische schuld. Het is niet zonder reden dat de Scrum Guide het Development Team verantwoordelijk maakt voor het garanderen van kwaliteit. Maak gebruik van de tips in deze post om technische schuld op de agenda te krijgen. Maak het transparant. Geef tegengas als jullie het gevoel hebben dat de kwaliteit van de code te weinig aandacht krijgt ten opzichte van het toevoegen van nieuwe features. Zorg ervoor dat de schattingen die je geeft aan items op de Product Backlog rekening houden met het schrijven van tests en leesbare/onderhoudbare code. Dit is niet een keuze die je buiten het Development Team moet leggen. Kijk ook kritisch naar de Definition of Done, en zorg dat aspecten gerelateerde aan code-kwaliteit daarin goed aandacht krijgen. Zo zorg je ervoor dat het voorkomen en bestrijden van technische schuld onderdeel blijft van de dialoog met de Product Eigenaar en de bredere organisatie. Een belangrijke tip is om dat wel op een empathische, pragmatische en vriendelijke manier te blijven doen.

3. Maak gebruik van code metrics om technische schuld meetbaar te maken

Metrics zijn een uitstekende manier om iets dat subjectief en abstract is meer objectief en tastbaar te maken. Van discussies als ‘Er is teveel technische schuld’ ga je naar ‘Zoveel % van de codebase is van lage kwaliteit’. Dit geeft je niet alleen meetbare doelen, het maakt verbetering ook zichtbaar. En dat werkt bijzonder motiverend. Je kunt denken aan de volgende metrics:

  • Cyclomatic complexity: Met deze metric kwantificeer je de complexiteit van classes en methods. De metric telt het aantal functionele paden in je code (if/then/else, switch/case, etc) en weegt dat ten opzichte van het aantal regels code. Hoe hoger de cyclomatische complexiteit, hoe moeilijker de code te begrijpen – en dus te onderhouden – is;
  • Code coverage: Een gebrek aan unit tests is een grote bron van technische schuld. De meeste IDEs en CI-servers kunnen het aantal regels code berekenen dat door unit tests gedekt wordt (de zogenaamde ‘code coverage’). Het is zelden zinvol om te streven naar een dekking van 100%. Een betere stelregel is om eerst een goede dekkingsgraad te bereiken, en daarna te zorgen dat deze tenminste gelijk blijft bij het toevoegen van verdere code;
  • SQALE-rating: Deze metric geeft een totaalbeeld van de kwaliteit van je code, gebaseerd op een groot aantal interne regels. De schaal gaat van A tot E, waarbij A de beste score is en E de slechtste. Veel plugins die gespecialiseerd zijn in het meten van code-kwaliteit kunnen deze rating berekenen (zie ook hieronder);
  • Aantal ‘Rule violations: Deze metric berekent hoeveel regels uit een gegeven code-conventie worden gebroken in een codebase. De geschonden regels worden gegroepeerd naar prioriteit, bijvoorbeeld van ‘critical’ tot ‘minor’, zodat je ook weet waar je het beste kunt beginnen met refactoring;
  • Cost of Delay: Deze (handmatige) metric maakt zichtbaar hoeveel tijd je als team verliest door code van lage kwaliteit;
  • Bugcount: Het tellen van het aantal bugs is een simpele, maar nuttige metric. Naarmate de kwaliteit van de code afneemt, neemt het aantal vaak bugs toe. Het monitoren van het aantal bugs – zeker na een release – is dan ook een uitstekende eerste stap;

Kortom; er zijn veel tools en metrics beschikbaar om technische schuld te kwantificeren. Veel van deze tools zijn gebaseerd op ‘static code analysis’, en kunnen uitgevoerd worden vanuit IDE’s of build- en integratieservers. Ter inspiratie heb ik hieronder een paar tools opgesomd (die binnen enkele minuten operationeel waren).

 

NDepend is een plugin die een groot aantal van de hierboven genoemde metrics ondersteunt. Bijzonder nuttig is de SQALE-rating (van A tot E), het percentage opgebouwde technische schuld en het aantal dagen dat nodig is om dit te repareren. NDepend kan ook handige heatmaps genereren waaruit je snel de classes kunt halen die vooral aandacht nodig hebben.

Gebruik je Visual Studio Professional of hoger? Dan kun je ‘out of the box’ gebruik maken van metrics voor cyclomatische complexiteit en een zogenaamde ‘maintainability index’ (van 0 tot 100).

Een andere optie is SonarQube. Dit platform integreert met allerlei CI-pipelines en IDEs, en genereert een groot aantal code metrics (inclusief de SQALE-rating):

 

Alhoewel deze metrics soms ruw zijn, of kort door de bocht, is dat geen reden om er niet naar te kijken. De metrics geven je wel degelijk een meetbaar, onderbouwd doel. Met enige configuratie zijn de metrics desgewenst nauwkeuriger te maken, bijvoorbeeld door bepaalde files of delen van je codebase uit te sluiten (zoals gegenereerde code of legacy code die niet gewijzigd gaat worden). Deze metrics geven mensen bovendien een beter begrip van de consequenties van technische schuld, en maakt het gemakkelijker om onderbouwde beslissingen te nemen over code-kwaliteit. Development Teams die gebruik maken van dergelijke metrics tijdens (tenminste) de Sprint Review hebben betere, meer gebalanceerde discussies over technische schuld. Een groot verschil met de ‘muur van onbegrip’ die je vaak ziet bij teams die dit niet doen.

4. Maak technische schuld transparant op je backlog

Maak technische schuld transparant. Verstop het niet voor de Product Owner of de rest van de organisatie. Heb je te maken met een bestaande codebase van ‘rotte’ code?  Identificeer dan welke verbeteringen noodzakelijk zijn, voorzie ze van schattingen en stel ze voor voor opname in de Product Backlog. Behandel ze als andere items op je Backlog; breek grotere items op in kleinere items en prioriteer ze met de Product Eigenaar. Op die manier help je de Product Eigenaar om een geïnformeerde keuze te maken over het omgaan met technische schuld.

Een andere optie is om met de Product Eigenaar een bepaald percentage van de sprint te gebruiken voor het wegwerken van technische schuld. Het risico is wel dat de technische schuld (en wat er dan precies wordt gedaan) onzichtbaar blijft voor iedereen buiten het Development Team. Blijf ook hier vasthouden aan transparantie; maak zichtbaar wat je als team oppakt en bespreek het ook tijdens de Scrum Events.

Conclusies

Technische schuld is voor veel Development Teams een frustrerend en demotiverend onderwerp. Het sleutelwoord is transparantie. Maak gebruik van de transparante metafoor ‘technische schuld’ om begrijpelijk te maken wat de kosten zijn van code van lage kwaliteit. Gebruik diverse code metrics om technische schuld zichtbaar te maken in de code, en evalueer de resultaten regelmatig. Maak technische schuld tenslotte transparant op de Product Backlog. Verstop het niet voor de Product Eigenaar of de bredere organisatie.

Deze blog is geschreven door Agile Coach Christiaan Verwijs. Wil je meer blogs van hem lezen? Bezoek dan zijn website http://www.agilistic.nl/agile-software-development/

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Meer weten over onze werkwijze en dienstverlening? Neem gerust contact met ons op!