De Technische schuld van een SCRUM-team

Technische schuld maken we bijvoorbeeld als we een sprint onder druk staat. Eigenlijk hebben we meer tijd nodig om de programmacode te structureren,  maar die tijd is er niet. Het halen van de deadline is belangrijker dan het opschonen van de code. Daarom stellen we het opschonen uit zodat we de sprint op tijd af kunnen ronden. We stemmen ermee in om een dergelijke schuld aan te gaan die we later moeten terugbetalen.

Technische schuld leidt tot vertraging

Als we nu deze sprint halen, wordt het echter moeilijker om de volgende te halen. We gaan steeds langzamer werken en als je niet oppast, vertraagt ​​de ontwikkeling in de loop van de tijd. Het aantal user stories dat we binnen een sprint kunnen realiseren wordt namelijk steeds kleiner omdat we een last op onze schouders dragen.

Om technische schuld in een agile ontwikkeling te kunnen managen, moeten we concept “technische schuld” goed begrijpen. Anders verpesten we onze software. De vragen om een definitie voor technische schuld te vinden zijn:

• Wat is technische schuld (en wat is niet)?
• Waar komt technische schuld vandaan?
• Wanneer is het goed om technische schulden te maken?
• Hoe kan het de ontwikkeling schaden?
• Technische schuld management: hoe kunnen we deze schuld meten?
• Hoe kunnen we het verminderen?
• Hoe kunnen we technische schuld vermijden?

Wat is technische schuld (en wat is niet)?

Technische schuld is uitgesteld, maar noodzakelijk werk:

Het omvat die interne dingen die we nu niet willen doen, maar die de toekomstige ontwikkeling belemmeren als ze blijven zitten. 
Technische schuld omvat geen uitgestelde functionaliteit, behalve mogelijk in randgevallen waarbij de geleverde functionaliteit “goed genoeg” is voor de klant, maar niet voldoet aan een bepaalde norm. Bijvoorbeeld een UI-element dat niet volledig voldoet aan een bepaalde UI-standaard.

Ongeacht de ontwikkelingsfilosofie die ons ontwikkelteam volgt, zijn er een aantal veel voorkomende fouten die leiden tot technische schulden:

• Slecht gedefinieerde SCRUM-werkwijzen. Inclusief een gebrek aan technische feedback van systeembeheer.
• Gebrek aan documentatie over de programmacode. Voor een ontwikkelaar is het moeilijk om de ​​programmamodule en daarin de code te vinden die hij moet wijzigen.
• Ontoereikende ontwikkeltools voor broncodemanagement, foutopsporing, coderingsnormen en onderhoud en testen.
• Geen of niet-effectieve geautomatiseerde tests, waardoor er ruimte is voor fouten vanwege handmatige processen.

Kies uit twee manieren

We hebben een stuk functionaliteit dat we aan ons systeem moeten toevoegen. Er zijn twee manieren om het te doen:

• Snel, maar rommelig – We weten zeker dat het in toekomstige wijzigingen complexer zullen zijn.
• Het andere resulteert in een schoner ontwerp, maar het duurt langer om het nu te realiseren.

Een puinhoop is nog geen technische schuld

Een puinhoop is geen technische schuld. Een puinhoop is gewoon een puinhoop. Technische schuldbeslissingen worden genomen op basis van echte projectrestricties. Ze zijn riskant, maar ze zijn nuttig. De beslissing om er een ​​puinhoop van te maken is nooit rationeel. Het is altijd gebaseerd op luiheid en onprofessioneel handelen. De kans dat het hele project eens over moet is groot. Een puinhoop is altijd een verlies.

Als onze code rommelig is, is het altijd slecht. Als we echter noodzakelijk werk uitstellen, kan dat een slimme zakelijke beslissing zijn. Helaas leiden beide, het creëren van een puinhoop en het op ons nemen van een technische schuld, in de loop van de tijd tot vergelijkbare problemen.

Enkele voorbeelden van wat technische schuld is en wat niet

Een typisch voorbeeld van technische schuld in programmacode is dat enorme bronbestand waar iedere ontwikkelaar bang voor is. Iedereen in het team weet dat we het moeten opdelen in meer beheersbare stukken. Dit zou de komende functies echter met minstens twee weken vertragen. Het wijzigen van deze module zonder deze te herstructureren, draagt ​​bij aan de schuld van ons product. Iedere volgende wijziging maakt het uiteindelijke herstructureren echter moeilijker en gaat daarom later meer kosten. De rente die we moeten betalen, is de extra complexiteit van elke wijziging die we hebben toegevoegd. De module groeit met iedere codetoevoeging en dat maakt herstructurering (en de beslissing daartoe) steeds moeilijker.

En wat is geen technische schuld?

• Onnodige complexiteit, vuile hacks en onleesbare code zijn geen technische schuld. Er is in de eerste plaats geen goede reden om er zo’n puinhoop van te maken. Als ontwikkelaars denken dat ze geen tijd hebben om eenvoudige, onderhoudbare code te schrijven, ontbreekt het hun duidelijk aan ervaring en professionaliteit.
• “Single brain know-how” is een ander fenomeen dat men vaak omschrijft als technische schuld. Maar afhankelijk zijn van één persoon op een ​​kritisch onderdeel van onze applicatie, is geen technische-schuld – het is een dodelijke bedreiging voor ons bedrijf. Geen enkele regel code zou live mogen gaan zonder dat een tweede paar ogen de code onder de loep hebben genomen. Dingen zoals pair-programmering of code-reviews zijn goede, professionele gewoonten en mogen we niet inruilen voor de illusie van een snellere oplevering.

Hoe kunnen we afrekenen?

Technische schulden beperken zich uiteraard niet tot Agile – SCRUM teams. Veel van deze punten zijn vast ook van toepassing op veel Waterfall projecten. Tegenwoordig moeten alle ontwikkelteams het hoe dan ook sneller doen. En als je sneller levert, ontstaat er technische-schuld.

Er zijn drie benaderingen om af te rekenen met technische schulden:

• Sprint voor sprint: Verminder de technische schulden door in iedere sprint iets op te lossen. Ondertussen kan je nog steeds nieuwe functies opleveren en de Product Owner tevreden houden.
• Een toegespitste sprint: Wijd een hele sprint aan een grote hoeveelheid technische schulden. Dit moeten dan wel allemaal user stories worden.
• Zet het buiten het normale sprintwerk: Haal capaciteit van normaal sprintwerk en focus dat op technisch schuldwerk.

Welke strategie of strategieën we ook gebruiken, het hangt af van onze organisatie en de situatie:

• De omvang.
• Welke kritische functies het betreft.
• De benodigde inspanning.
• De impact van onze technische schuld.

Waar het om gaat is om zo snel mogelijk af te rekenen, wacht niet te lang!

Discussieer mee op LinkedIn.