Het plakband van IT

Hey there! Welcome to this new blog post!

Dit is het eerste deel van een serie van drie blogartikelen waarin ik uitleg wat technische schuld (technical debt) is, hoe het kan ontstaan, waarom het negatieve impact heeft en wat organisaties eraan kunnen doen om dit terug te dringen.

Inleiding

Met de komst van agile werkvormen en multidisciplinaire teams gaan ontwikkelaars steeds meer werkzaamheden doen die vroeger belegd waren bij testers. Statische code-analysetools (als SonarQube) geven de ontwikkelaar dashboards met daarin allerlei kreten uit de testwereld. Zo ook de term technische schuld. Ik krijg hierover vaak vragen omdat het concept niet goed begrepen wordt.
Afgelopen jaar ben ik actief geweest voor meerdere klanten als kwaliteitsadviseur. Bij verschillende projecten ben ik getuige geweest van teams die per sprint steeds minder werk konden verzetten. Zowel de teams als de PO staan met hun handen in het haar en weten niet hoe ze het tij kunnen keren. Toevoegen van development capaciteit vertraagt in eerste instantie de voortgang en het doen van meer refinements ook.
Een opdrachtgever, die het probleem iedere sprint zag toenemen, vroeg aan mij: wat is acceptabele technische schuld?

Wat is het?

Technische schuld is een jargon uit de IT-wereld binnen het domein van testen en kwaliteit. Het is een verzamelnaam voor herstelkosten (oplostijd, opgetelde mean-time-to-resolution) van achterstallig onderhoud of geïmplementeerde oplossingen die niet voldoen aan de kwaliteitseisen.
‘Technical debt’ wordt vaak uitgedrukt in tijd, dus uren of dagen van herstelwerkzaamheden. In het algemeen geldt dat bij meer technische schuld de algehele kwaliteit van het product lager is en bij een lagere technische schuld is de kwaliteit hoger.

Meer lezen:

https://blog.the-experts.nl/sebastiaan127001/het-plakband-van-de-it-4ln5