Technische schulden: agile strategieën voor een schuldenvrije ontwikkelingscyclus

Traditionele softwareprogramma's hebben een op fasen gebaseerde benadering voor ontwikkeling: functieontwikkeling, alfa, bèta en golden master (GM).

Elke release begint met een fase waarin nieuwe functies worden gebouwd en (idealiter) issues die zijn overgebleven van de laatste release worden aangepakt (maar laten we eerlijk zijn: dit gebeurt zelden). De ontwikkelingscyclus bereikt de alfa-status wanneer elke functie is geïmplementeerd en klaar is om getest te worden. Bèta wordt bereikt wanneer er genoeg bugs zijn verholpen om feedback van klanten mogelijk te maken. Helaas verschijnen er nieuwe bugs, terwijl het team nog bezig is om genoeg bugs op te lossen om de bèta-status te bereiken. Het is een chronisch geval van 'whack-a-mole' ('Mollen meppen'): los één bug op en er verschijnen meteen twee nieuwe. Ten slotte bereikt de release de gouden mijlpaal wanneer er geen openstaande bugs meer zijn. 'Geen openstaande bugs' wordt meestal bereikt door enkele bekende issues op te lossen en de rest (de meeste?) uit te stellen tot de volgende release.

Het oplossen van bugs voortdurend uitstellen, is een gevaarlijke manier om software te maken. Naarmate het aantal bugs groeit, wordt het aanpakken ervan steeds intimiderender, wat leidt tot een vicieuze cirkel aan technische schulden. Tot overmaat van ramp ontsporen schema's omdat codering rond de bugs de ontwikkeling vertraagt. Ondertussen hebben klanten te maken met een langzame achteruitgang vanwege niet-opgeloste defecten. Sommigen van hen zullen je dan ook verlaten.

Er moet een betere manier zijn.

Met agile wordt kwaliteit in de iteratieve ontwikkelingsaanpak ingebakken, zodat het team bij elke release een consistent kwaliteitsniveau kan behouden. Als een functie niet in goede conditie is, wordt deze niet verzonden. Vind je dat moeilijk te geloven? Er is een truc: de definitie van 'gedaan' definiëren of opnieuw definiëren.

Voor traditionele teams betekent 'gedaan' dat het goed genoeg is om QA te laten beginnen. Het probleem met die definitie is dat bugs vroeg in de releasecyclus binnensluipen, en dat dit niet meer ophoudt. Tegen de tijd dat QA het in handen krijgt, zit het product dus lagenvol met defecten. Agile teams definiëren" done echter" als klaar om uit te brengen, wat betekent dat ontwikkelaars pas doorgaan naar de volgende story of de volgende functie als hun huidige item praktisch in handen van klanten is. Om de zaken te versnellen, gebruiken ze technieken zoals workflows voor functiebranches, geautomatiseerd testen en continue integratie gedurende de ontwikkelingscyclus.

De hoofdbranch van de codebase moet altijd klaar zijn voor levering. Dat heeft de hoogste prioriteit. Nieuwe functies beginnen hun leven dus op een taakbranch met code voor de functie zelf, plus geautomatiseerde tests. Zodra de functie is voltooid en de geautomatiseerde testes zijn afgerond, kan de branch worden samengevoegd met hoofdbranch. Omdat de kwaliteitslat altijd vast (en hoog) ligt, blijven de technologische schulden onder controle.

Voor veel organisaties is dit een enorme culturele verandering. Met agile verplaatst de focus zich van planningen naar aantoonbaar hoogwaardige software. De producteigenaar krijgt de bevoegdheid om het team eerst met het meest waardevolle werk bezig te laten gaan, waardoor de scope van de release wordt verkleind in plaats van concessies te doen aan de kwaliteit.

Want we mogen niet vergeten: hoe langer bugs blijven hangen, hoe lastiger ze opgelost kunnen worden.

Als je met verouderde code werkt, is de kans groot dat je wat technische schulden erft. De volgende onderwerpen helpen je bestaande schulden in te dammen en stellen je team in staat zich te concentreren op leuke dingen, zoals de ontwikkeling van nieuwe functies.

Soms zijn ontwikkelaars en productmanagers het oneens over waar technische schulden uit bestaan. Dus laten we de controverse hier een halt toeroepen:

Dit omvat alle technische snelkoppelingen die zijn gemaakt om leveringsdeadlines te behalen!

Aan de ontwikkelingskant is er een verleiding om architectonisch werk te karakteriseren als technische schulden. Het kan al dan niet zo zijn, afhankelijk van de aard van de wijziging (bijv. het vervangen van een snelkoppeling door de 'echte' oplossing t.o.v. het splitsen van een monolithische codebase in microservices). Aan de andere kant voelt productbeheer vaak meer urgentie rond het bouwen van nieuwe functies dan voor het oplossen van bugs of trage prestaties. Om te voorkomen dat beide partijen afgestompt raken over de mening van de andere partij, moet iedereen het onderscheid begrijpen tussen technische schulden, gewenste architectonische veranderingen in de codebase en nieuwe functies. Duidelijke communicatie tussen ontwikkeling en productmanagement is van groot belang om prioriteit te geven aan de backlog en het ontwikkelen van de codebase.

Probeer niet te leveren bij de definitie van gedaan, maar voeg een aparte testtaak toe aan de oorspronkelijke userstory. Het is te eenvoudig om ze uit te stellen en dat nodigt alleen uit tot technische schulden. Als tests niet worden uitgevoerd als onderdeel van de oorspronkelijke story of bugfix, is de oorspronkelijke story of bugfix niet voltooid. Houd een strikte definitie van gedaan aan in je programma en zorg ervoor dat deze volledige geautomatiseerd testen omvat. Niets vermindert de agility van het team meer dan handmatig testen en een defecte codebase.

Wanneer iemand een bug in de software ontdekt, neem dan de tijd om een geautomatiseerde test toe te voegen die dit aantoont. Zodra de bug is verholpen, voer je de test opnieuw uit om te controleren dat deze slaagt. Dit is de kern van testgestuurde ontwikkeling, een aloude methodologie voor het handhaven van kwaliteit in agile ontwikkeling.

Het veranderen van de filosofie van het team (en die van de belanghebbenden van het team) over het beheren van technische schulden is niet eenvoudig. Door zakelijke behoeften wordt soms de ontwikkelingstijd verkort zodat ze sneller op de markt kunnen komen. Laten we dat in gedachten houden en vervolgens enkele actiepunten samenvatten voor het indammen van technische schulden:

• Informeer de producteigenaar over de werkelijke kosten van technische schulden. Zorg ervoor dat de waarden van storypoints kloppen voor toekomstige story's waarvoor bestaande technische schulden opgelost moeten zijn.
• Moduleer je architectuur en neem een krachtig standpunt in ten aanzien van technische schulden in nieuwe componenten of bibliotheken in de applicatie. Aangezien het team en het bedrijf de flexibiliteit van deze nieuwe componenten zien, willen ze die praktijken natuurlijk uitbreiden naar andere delen van de code.
• Schrijf geautomatiseerde tests! Niets voorkomt bugs beter dan geautomatiseerde tests en continue integratie. Wanneer een nieuwe bug wordt gevonden, schrijf je een nieuwe test om deze te reproduceren en vervolgens de issue op te lossen. Als die bug ooit weer opduikt, zal de geautomatiseerde test deze opvangen voordat klanten deze kunnen zien.

Vergeet niet dat technische schulden een realiteit zijn voor alle softwareteams. Niemand vermijdt het helemaal, het belangrijkste is om te voorkomen dat het uit de hand loopt.