Wat meet een technische schuld-assessment?
Ward Cunningham bedacht de metafoor van technische schuld in zijn OOPSLA-ervaringsrapport uit 1992. Hij schreef dat "code voor het eerst opleveren is als schulden aangaan." Een beetje schuld kan je versnellen. Het probleem begint als je die niet aflost, want elk uur dat je besteedt aan het omzeilen van code die net niet klopt, wordt rente. Codescanners meten de code. Dit assessment meet waar het team dagelijks mee te maken heeft: of je de schuld kunt zien, hoeveel die de oplevering vertraagt, hoe gezond de code en systemen aanvoelen en of jullie de schuld aflossen. Iedereen beoordeelt elke stelling voor zichzelf. Daarna nemen jullie de laagste scores mee naar een retrospective en spreken jullie af wat als eerste wordt aangepakt.
Afmetingen
Zichtbaarheid
Of het team weet waar de schuld zit en die als echt werk behandelt.
Bekende hotspots
We weten welke delen van ons systeem de meeste schuld bevatten.
Bijgehouden naast ander werk
Schuld wordt in dezelfde backlog bijgehouden als features en bugs.
Bekende kosten
We kunnen uitleggen wat onze grootste schulden ons kosten aan tijd of risico.
Impact op oplevering
Hoeveel schuld het werk vertraagt dat het team probeert op te leveren.
Snelheid van features
Schuld vertraagt de features die we bouwen zelden.
Veilige wijzigingen
Als we één deel van ons systeem wijzigen, gaat er zelden iets kapot in een ander, ongerelateerd deel.
Snelle, betrouwbare builds
Onze builds en tests zijn snel en betrouwbaar.
Gezondheid van code en systemen
Hoe makkelijk er vandaag met de code, systemen en dependencies te werken valt.
Makkelijk aan te passen
De meeste code is makkelijk te begrijpen en aan te passen.
Actuele dependencies
Onze dependencies en platforms zijn redelijk up-to-date.
Tests ondersteunen refactoring
Onze tests geven ons het vertrouwen om te refactoren.
Schuld aflossen
Of het team gestaag en in onderling overleg vooruitgang boekt bij het verminderen van schuld.
Tijd vrijgemaakt
We maken regelmatig tijd vrij om schuld af te lossen.
Bewuste schuld vastgelegd
Als we bewust schuld aangaan, leggen we die vast met een plan om hem af te lossen.
Gedeelde prioriteiten
Product en engineering zijn het eens over hoe de tijd wordt verdeeld tussen features en schuld.
Wanneer dient u deze gezondheidscontrole uit te voeren?
- Als features langer duren dan nodig en het team steeds naar de codebase wijst.
- Vóór een kwartaal- of roadmapplanning, om af te spreken hoeveel tijd naar het aflossen van schuld gaat.
- Na een grote sprint naar een release of een harde deadline, om de genomen shortcuts vast te leggen voordat ze vergeten worden.
Tips en trucs
- Lees eerst de laagst scorende groep. Lage zichtbaarheid betekent dat je eerst een overzicht van je schuld nodig hebt. Hoge zichtbaarheid met weinig aflossing wijst op een planningsprobleem, niet op een codeprobleem.
- Betrek je productmanager bij het gesprek, ook als alleen engineers de beoordeling invullen. Hoe je tijd verdeelt tussen features en schuld is een gezamenlijke beslissing.
- Combineer de scores met data die je al hebt, zoals buildtijden, het aantal flaky tests of de oorzaken van incidenten. Het assessment laat zien waar het pijn doet; de data laat zien hoeveel.
- Gebruik het naast de DORA Metrics Self-Assessment, het DevOps Maturity Assessment of het Engineering Excellence Maturity Model om te zien hoe schuld samenhangt met oplevering en engineeringpraktijken.
- Herhaal het elk kwartaal. Een stijgende score op de stellingen over schuld aflossen is het vroegste teken dat je plan werkt.
Veelgestelde vragen
Hoe meet je technische schuld?
Wat zijn de vier soorten technische schuld?
Hoeveel tijd moeten we aan technische schuld besteden?
Hoe leg je technische schuld uit aan productmanagers?
Wat is een voorbeeld van technische schuld?
Wie heeft de term technische schuld bedacht?
Based on Ward Cunningham, 'The WyCash Portfolio Management System,' OOPSLA '92 Experience Report (1992).