Wanneer u de vorige twee blogs hebt gelezen begrijpt u mogelijk de ernst van de situatie en hoe technische schuld IT-projecten in kan sluipen en ervoor kan zorgen dat projecten onbeheersbaar worden in productie. In dit derde en laatste deel zet ik een gestructureerd plan uiteen om technische schuld terug te dringen tot een acceptabel minimum. Helemaal schuldenvrij is namelijk niet te garanderen.
Waarom zou u?
Refererend aan de auto met achterstallig onderhoud uit de vorige artikelen, kan men verwachten dat de kwaliteit ervan achteruit gaat door de focus op vernieuwing. Dit geldt uiteraard net zo goed voor IT-projecten. Het gevolg is dat de applicatie in productie niet voldoet aan de verwachtingen van de eindgebruiker en de business. Maar daarnaast zijn er nog andere veel voorkomende gevolgen.[2][4]
In de eerste plaats wil ik de impact op de projectplanning aanvoeren. Bij een te grote technische schuld is de kans op uitloop aanzienlijk vergroot door alle onvoorziene reparatiewerkzaamheden en inhaalslagen. De paradox hier is dat, zoals genoemd in vorig artikel, de belangrijkste oorzaak voor technische schuld de deadlines (lees: haast) van het project zijn.
Een ander risico uit de top drie is dat de onderhoudbaarheid van de applicatie slechter wordt naarmate de technische schuld toeneemt [2]. Uit onderzoek is gebleken dat gemiddeld 75% van de kosten van een IT-project opgaat in de beheerfase (maintenance) [3]. Wanneer projecten veel achterstallig onderhoud (technische schuld) hebben nemen de kosten in beheer aanzienlijk toe.
Als laatste motivatie wil ik aanvoeren dat gemiddeld 25% van development wordt besteed aan het oplossen van problemen door technische schuld wanneer die er is; problemen oplossen tijdens de voortbrenging dus. Waarom zou u dan niet structureel 25% van de sprint inruimen voor verbeterslagen?
Samengevat: om de snelheid te behouden en de beheerkosten te beperken is het zaak om de technische schuld van een IT-project te minimaliseren van het begin af aan.
Het roer moet om, maar hoe?
Voordat ik inga op de aanpak, is het nog belangrijker dat zowel de teamleden als de product owners de juiste mindset hebben en dat de product owner en/of projectleider overtuigd is van de business case en de ontwikkelaars eigenaar worden van de kwaliteit omdat ze inzien wat het hen brengt. Mensen die last ervaren willen verandering en mensen die geloven in de voordelen nemen hun verantwoordelijkheid. Daarom is het goed om het ontwikkelteam en management te betrekken in dit proces zodat er draagvlak ontstaat en de KPI’s niet alleen over functionaliteit gaan. Vergroot de focus op kwaliteit en de lange termijn zodat de balans herstelt wordt.
De business case
Zoals geschetst in het tweede blog komt het geregeld voor dat kwaliteit niet op de agenda staat van de managers en directie totdat de kosten toenemen omdat een project uit tijd en geld loopt.
Wanneer men geen of te weinig aandacht heeft voor de kwaliteit, raakt men langzamerhand in een situatie waarin reactief gehandeld wordt op incidenten en waarin steeds meer brandjes geblust moeten worden, steeds meer problemen zich voordoen en waarin er meer aandacht gaat naar de ondersteuning van de beheer- of gebruikersorganisatie dan aan ontwikkelen. Hierdoor neemt de stress toe en de velocity en het werkplezier af. Dit komt doordat de applicatie niet of minder voldoet aan de kwaliteitseisen en daarom slechter zal presteren, niet schaalbaar is en slecht onderhoudbaar is. Uiteindelijk moeten teams het werk uit hun handen laten vallen om het project weer op de rails te krijgen en komt de trein tot stilstand.
If you don't deal with your demons, they will deal with you, and it's gonna hurt.
Samengevat: wanneer u geleidelijk aan de balans herstelt en aandacht geeft aan kwaliteit wordt u geleidelijk aan weer proactief en komt u 'in control'.
Hoe weet ik of ons project technische schuld heeft?
Dit is een belangrijke vraag. Wanneer projectteams dit al inzichtelijk hebben gemaakt, bijvoorbeeld door middel van een dashboard (van SonarQube), is het duidelijk te zien. Maar vaker kom ik projecten tegen waar dit helemaal niet bekend is. Wanneer men zich er niet van bewust is dan is de kans groot dat er dus technische schuld aanwezig is. Dan is het juist zaak om dit aan het licht te brengen. In het volgende stappenplan ga ik daar verder op in.
Het stappenplan en routekaart
continuous improvement
Om methodisch en doelgericht uw project naar een hoger kwaliteitsniveau te brengen is het niet nodig om het wiel opnieuw uit te vinden. William Deming, de grondlegger van modern kwaliteitsmanagement en continuous improvement, heeft tenslotte rond 1920 een methodiek ontworpen waar tot op de dag van vandaag vele andere methodieken op gebaseerd zijn, te weten Plan - Do - Check - Act, of wel PDCA [5]. Omdat deze methode bewezen effectief is, heb ik het stappenplan hierop gebaseerd. De effectieve werkwijzen en bewezen methoden van de projecten waar ik onderdeel van was, heb ik ondergebracht in de stappen van het stappenplan.
Dit stappenplan biedt een handvat om technische schuld inzichtelijk te maken, het te onderkennen en het daadwerkelijk op te lossen. Het is geen proces dat in beton gegoten is maar een het is adaptief en schaalbaar. Het geeft antwoord op de vragen: “waar begin ik?” en “hoe werk ik het weg?”. Het is goed onder te brengen in scrum-processen, daarom wordt daar naar verwezen bij sommige stappen, maar het werkt net zo goed bij andere werkvormen als SAFe, DevOps of iets anders.
Tevens kan dit gebruikt worden als routekaart. Het hoeft niet chronologisch te worden gelezen en bij sommige stappen staat ook een verwijzing naar een externe bron voor meer verdieping.
Plan: identificeer
Het aan het licht brengen van de technische schuld is de eerste stap. Een idee krijgen van de omvang van het probleem helpt bij het inschatten van de impact. Waar hebben we het over? Gaat het om het herschrijven van wat features of het documenteren zodat het beter te beheren is? Of betreft het honderden blocking code smells in SonarQube of afhankelijkheden van bibliotheken met beveiligingsproblemen die gebruikt worden in de containers.
Gaat het om een hele sprint aan werk om de kwaliteit weer op orde te krijgen of is het in een middag geregeld?
Niet alle problemen zijn zichtbaar dus het team is zich niet altijd bewust van alle technische schuld.
Om die reden moet u op twee manieren op zoek gaan naar de technische schuld geautomatiseerd en handmatig.
Automatisch wordt vooral gedaan door het scannen van de broncode op onvolkomenheden (statische codeanalyse) en de uitkomsten uit de automatische regressietest (ART). Ik zie automatisch scannen als de grammaticacontrole van een tekstprogramma. De computer gaat door massa’s tekst en controleert de punten en komma's die zelf over het hoofd wordt gezien. Zet automatisering in voor het monnikenwerk.
Een ander voordeel van automatisch scannen is dat dit continu kan blijven draaien, bijvoorbeeld na iedere pipeline build. Op die manier kan een dashboard worden gemaakt en kan met de trend van het aantal meldingen (technische schuld) bijhouden. Dit kan het team en het management handige sturingsinformatie geven.
Belangrijk om te realiseren is dat geautomatiseerde tools (zoals SonarQube) die rapporteren over de hoeveelheid technische schuld van een project, slechts een indicatie geven. Dit komt omdat grotere ontwerpproblemen of inefficiënte oplossingen meestal niet automatisch kunnen worden gedetecteerd. Daarnaast is de hersteltijd, die wordt genoemd in de rapportage slechts een suggestie.
Door de bank genomen kan er met automatisering de helft van de bevindingen worden gevonden.
Zoek daarom ook niet-geautomatiseerd door middel van peer-reviews. Het vier-ogen-principe is essentieel om grotere ontwerpproblemen boven tafel te krijgen die zorgen dat een applicatie in productie moeilijk te beheren is. Bijvoorbeeld het houden aan de code-conventies of het schrijven van leesbare begrijpelijke code is iets wat geautomatiseerd niet te ontdekken is.
Net als bij het schrijven van een belangrijke brief, is het aan te raden om, naast de grammatica-controle, een ander de brief te laten lezen of het begrijpelijke taal is en of het zijn doel dient. Dit is wat ontwikkelaars ook met elkaars werk moeten doen. Ook buiten het team kan men op zoek naar reviewers.
Samengevat: breng technische schuld aan het licht door periodieke (liefst dagelijkse) automatische scans en door code reviews van andere ontwikkelaars of audits van externe partijen.
Resultaat: een overzicht van het aantal meldingen van verbetermogelijkheden uit de scans en een ureninschatting van de reparatietijd van de technische schuld.
Meer: voor een handig dashboard verwijs ik u naar https://quality-time.readthedocs.io/en/latest/
Plan: prioriteer
Binnen maatwerksoftwareprojecten zijn er manieren om technische schuld te categoriseren.
Allereerst is het goed om te realiseren dat niet alle technische schuld naar nul hoeft, het ligt namelijk aan het type technische schuld zoals het update van een bibliotheek of het refactoren van een complete module. Daarom is het goed om een onderverdeling te maken.
In sommige gevallen kunnen problemen, al dan niet tijdelijk, worden gemarkeerd als aanvaarde technische schuld. Dit is bijvoorbeeld wanneer de kosten voor het oplossen onvoldoende opwegen tegen de baten. Dit kunnen zowel technische voordelen zijn als het behalen van businessdoelen. Welke problemen we nu even laten liggen en later willen oppakken moeten we apart worden geadministreerd zodat het team deze niet uit het oog verliest.
De geautomatiseerde tools gooien alle technische schuld op een hoop. Dit is echter onterecht want sommige problemen die u oplost hebben een grote positieve impact op het eindproduct. Bijvoorbeeld wanneer ik een oud maatwerk framework vol met afhankelijkheden en kwetsbaarheden vervang en optimaliseer dan kan dit het team veel werk opleveren, maar ook de business veel winst omdat de beheer- en ontwikkelkosten afnemen.
Maak daarom een indeling en bepaal per issue, hoeveel impact het oplossen ervan heeft op de kwaliteit van het eindproduct en hoeveel tijd of storypoints het kost om dit te realiseren. De werkpakketten (stories) die een directe of indirecte positieve invloed hebben op de business of eindgebruiker moeten voorrang krijgen.
Onder het begrip impact versta ik dan businesswaarde of waarde voor de eindgebruiker, zichtbaar effect op de kwaliteit van non-functionals.
Naast de impact op het eindproduct zijn projectkosten ook een overweging. De aard van technische schuld (zoals uitgelegd in het eerste blog) is: Hoe ouder het probleem is, hoe duurder het wordt. Dit komt omdat mettertijd de complexiteit van de software toeneemt. Hoe meer afhankelijkheden een component heeft hoe meer werk het kost.
Dus de ouderdom van iets is ook een goede reden om zaken geprioriteerd op te pakken.
Er moet daarna tijd worden ingeruimd om deze taken uit te voeren.
Wanneer men scrum werkt kan men tijdens de sprintplanning naast nieuwe features, bewust stilstaan bij kwaliteit.
Zoals ik aangaf onder het kopje “Waarom zou u?” adviseer ik, afhankelijk van de ordegrootte, om een vijfde tot een kwart van de tijd in te ruimen voor kwaliteit, het wegwerken van technische schuld.
Samengevat: de gevonden technische schuld moet worden gecategoriseerd en daarna worden opgenomen in werkpakketten (user stories) die moeten worden geprioriteerd (story points) en vervolgens worden opgenomen in de sprint. Ruim 20%-25% van de sprint in voor kwaliteit
Resultaat: werkpakketten (user stories die zijn refined en planned) om technische schuld op te lossen
Meer: Voor meer informatie over het categoriseren van technische schuld verwijs ik u naar een artikel op Tweakers genaamd: “De wall of technical debt: maakt techdebt visueel”. [6]
Do: repareer
Vaak is het zo dat de voorbereiding, planning en evaluatie meer tijd innemen dan de daadwerkelijke uitvoer. Zo is de verhouding in dit stappenplan ook.
Deze stap behelst het oplossen van de technische schuld. Dit kan het refactoren zijn van een complete feature of even een library updaten of de testdekking verbeteren. In deze fase is het belangrijk dat degene die het oplost dit naar eer en geweten doet, met in zijn of haar achterhoofd was het einddoel is. Een kwalitatief goed eindproduct dat goed beheersbaar is en weinig gedoe geeft in productie. Het is namelijk ook mogelijk om het zo te bouwen dat de automatische scans het niet meer ontdekken.
Samengevat: repareer het zo goed mogelijk
Do: implementeer
Na de fix moet het worden toegevoegd aan het eindproduct. Dit betekent meestal een merge request om het aan de main line toe te voegen. In deze fase is het belangrijk om het vierogenprincipe te hanteren. Een tweede developer of expert beoordeelt de voorgestelde reparatie.
Wat namelijk kan gebeuren is dat de reparatie toch niet voldoet aan de standaarden maar niet meer als fout wordt aangemerkt door de automatische broncodeanalyse en dan raakt dit probleem uit het oog en komt het in productie met alle risico’s van dien.
Samengevat: implementeer het en laat het reviewen
Check: controleer
Na de implementatie-stap is het zaak te controleren of het euvel daadwerkelijk is opgelost en of er geen nieuwe problemen zijn opgetreden (regressie). De geautomatiseerde tests in het proces geven hier antwoord op.
Check: presenteer
Als onderdeel van het bewust omgaan met kwaliteit en laten zien aan de opdrachtgever dat kwaliteit hoog in het vaandel staat is het goed dit in rapportage of in de demo op te nemen. Beantwoord in deze communicatie: “hoe staat het nu met de kwaliteit van de software?” en “hoe is het team omgegaan met kwaliteit afgelopen periode?” en “welke acties op gebied van kwaliteitsverbetering staan er gepland voor komende periode?”
Act: evalueer
Opnemen in de evaluatie of retro
Het woord schuld in technische schuld impliceert schuld dat er een bewuste keus is gemaakt zoals bij monetaire schuld en dat is niet altijd zo.
Belangrijker is de vraag erachter: hoe komt het dat deze keuzes zijn gemaakt? Hoe komt het dat deze oplossingen op deze manier zijn geïmplementeerd en hoe kunnen we dit in de toekomst voorkomen.
Daarom is het essentieel om regelmatig te evalueren en een kwart van de tijd van de retrospectie te besteden aan de vragen:
Hoe komt het dat deze keuzes zijn gemaakt?
Hoe komt het dat deze oplossingen op deze manier zijn geïmplementeerd en
Hoe kunnen we dit in de toekomst voorkomen?
Een retro moet geen knuffelsessie zijn maar gebaseerd op data. Dus bereid hem voor en kom met cijfers en statistieken. Als er productieverantwoordelijkheid is: hoe draait prod? Hoeveel issues zijn daar? Hoeveel resource consumption of cloud costs zijn er en wat vinden we daarvan.
Hoe heeft de software afgelopen sprint gescoord op non-functionals zoals beschikbaarheid en onderhoudbaarheid? Beantwoord deze vragen voor zowel Dev als Ops.
Samengevat: Ga op zoek naar de oorzaak van de technische schuld en bepaal hoe dit kan worden voorkomen, de volgende keer
Act: leer
De leer-stap is misschien wel de belangrijkste stap. Dit is de laatste stap van de Act-fase, maar kan ook als eerste stap van het hele proces worden gezien.
In deze stap worden de spelregels bepaald. Dit is een stap waar het team en/of het management constant en bewust moet bepalen of er moet worden bijgestuurd aan de hand van wat men heeft geleerd in vorige stappen.
Met spelregels bedoel ik de consensus binnen het projectteam over wanneer iets wordt aangemerkt als technische schuld (onderkennen) en hoe we omgaan met technische schuld die wel onderkend is maar die we nu niet oplossen.
Een kwaliteitsdrempel (quality gate) die is ingebouwd in het proces, zorgt ervoor dat er in principe niets door mag naar productie als het niet voldoet aan de gewenste kwaliteit. Dit zou er in theorie voor moeten zorgen dat technische schuld, software met achterstallig onderhoud of bekende gebreken, niet in productie komt. Helaas is de theorie anders dan in de praktijk.
In Theory There Is No Difference Between Theory and Practice, While In Practice There Is
Wanneer de ontdekte technische schuld onderkend is door het team en er toezegging is gedaan dat dit wordt opgelost dan wordt het ook wel 'geaccepteerde technische schuld' (net als het accepteren van een risico). Het is dan zaak dat het team dit zo snel mogelijk aanpakt, want hoe langer er wordt gewacht hoe groter de schuld wordt.
Als er een bewuste keus wordt gemaakt om een stuk technische schuld toch naar productie te releasen moet het de volgende release eruit zijn. Dit betekent dat er na de release, tijd moet worden ingeruimd om dit stuk te verhelpen. Dit moet een werkafspraak zijn die gedragen wordt door het team en de product owner.
Zoals ik aangaf in de stap prioriteer, hoeft niet alle technische schuld naar nul. Wel is het vaak goed te doen om de dashboards van de geautomatiseerde scans op nul te krijgen. Belangrijker dan de vraag, “tot hoever gaan we?” is het inregelen van een continu proces om kwaliteit in projecten hoog te houden.
Werkwijze
Bij het opleveren van een sprint of story (definition of done) zal kwaliteitscontrole een standaard taak moeten zijn.
Bij sommige teams heb ik gezien dat ze doorlopend een epic hadden voor het oplossen van grotere onderkende technische schuld. Deze manier werkte minder goed vaak omdat het dan in de vergetelheid raakt en de PO er geen ruimte voor reserveert in de sprint.
Wat wel goed werkt, is een teamlid aanwijzen die in deze periode verantwoordelijk is voor alle randzaken. Ik heb ooit als studentenbaan gewerkt in de gaarkeuken van een verzorgingstehuis en het eten voor de cliënten werd daar aan de lopende band bereid. Iedere dag werd er een ander teamlid aangewezen als omloop. Deze ‘vliegende keep’ stond niet aan de band, maar deed alle randzaken. Kortgeleden hebben we dit ingevoerd in een team bij een van onze klanten en dit was een daverend succes omdat de technische schuld als sneeuw voor de zon verdween.
Een ander goed idee dat ik heb geleerd van de developers bij the/experts is dat de ontwikkelomgeving (IDE) waarmee ze werken, de tool om software te schrijven, gekoppeld kan worden aan de statische codeanalysetool (SonarQube lint). Op die manier krijgen ze nog voordat ze het aanbieden aan hun collega’s al feedback. Dit is pas ‘shift left’.
Een bekende naam in de wereld van ontwikkelaars is Uncle Bob (Robert C. Martin). Een van zijn uitgangspunten die hij heeft geleend uit de wereld van de Scouting is:
“Always leave the campground cleaner than you found it.”
Ontwikkelaars noemen dit boyscouting en het komt neer op: ook al zitten er issues in de huidige code base, wat je eraan toevoegt is schoon.
Wanneer ontwikkelaars toegewijd zijn aan goede kwaliteit, leven ze deze principes en hun coding conventions na. Hier hoort ook “clean as you go” bij. Als je iets aan het uitbreiden bent en je komt een stuk oude code tegen met oneffenheden, los dat dan gelijk op. Als je thuis het afval weggooit en je komt onderweg nog een propje tegen dan pak je dat ook op en neem je dat mee.
Houdbaarheid
Het verdient de overweging, op bestuurlijk niveau, om de balans op te maken om te bepalen of het herbouwen van de dienst, applicatie of software niet goedkoper is. Software heeft de neiging om na een aantal jaar doorvoeren van veranderingen steeds complexer te worden. Gezien de technologische vooruitgang is het mogelijk dat de gebruikte frameworks, technologieën en architecturale uitgangspunten niet meer actueel zijn.
Het is de overweging waard om na een periode van vijf jaar te bepalen of het niet goedkoper is om het van de grond af te refactoren in plaats van stukjes krampachtig proberen te vernieuwen.
Samengevat
Zorg dat uw team een actieplan heeft of het heeft opgenomen in hun werkwijze (agile processen) en monitor dit. Zorg dat ze technische schuld geprioriteerd aanpakken. Doe dit door het team bewust te maken van de gevolgen en zodat er een gevoel van urgentie ontstaat.
Zorg dat er uitgangspunten zijn, de spelregels. Dit bestaat onder andere uit de kwaliteitscriteria (niet-functionele eisen) maar ook teamafspraken zoals hoe we omgaan met technische schuld.
Deze uitgangspunten geven rust en duidelijkheid aan het team en iedereen eromheen.
Met een team van specialisten doet the/experts voor verschillende klanten audits op gebied van kwaliteit. Hier brengen wij de kwaliteit van de software en ontwikkelprocessen aan het licht en geven wij hierover praktische adviezen om dit te verbeteren. Daarnaast hebben wij de expertise in huis om deze verbeteringen ook door te voeren in uw organisatie.
[1] Bron: https://en.wikipedia.org/wiki/Technical_debt#Consequences
[3] bron https://galorath.com/software-maintenance-costs/
[5] Bron: https://en.wikipedia.org/wiki/PDCA#About
[6] Bron: https://tweakers.net/reviews/8128/de-wall-of-technical-debt-maakt-techdebt-visueel.html
[7] Bron: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Discussion (0)