Merkt u ook dat uw ontwikkelteam steeds minder werk kan verzetten? Of zit uw applicatie vol met workarounds waar eindgebruikers last van hebben? Voorkom dat het project uit budget en planning loopt. Lees artikel twee van drie over technische schuld en blijf in control.
In het vorige artikel legde ik uit wat technische schuld is. Samengevat komt het neer op achterstallig onderhoud en tijdelijke oplossingen die op korte termijn geen blokkerend probleem vormen maar waarvan de impact en het risico mettertijd toenemen waardoor de kwaliteit van het eindproduct uiteindelijk merkbaar verslechterd.
De meest voorkomende [1][2] gevolgen hiervan zijn: een lage kwaliteit van het eindproduct, uitgestelde releases, een moeilijk onderhoudbare applicatie, herstelwerkzaamheden, overschrijden van projectbudget, een gedemotiveerd team en, als het een DevOps-team betreft, bestaat het risico dat ze regelmatig bugs moeten oplossen in productie en steeds minder tijd hebben voor het ontwikkelen van nieuwe features.
Om de negatieve impact van technische schuld op het IT-project te beperken is het goed te begrijpen waar technische schuld ontstaat. Voorkomen is immers beter dan genezen. Ik heb de belangrijkste oorzaken verzameld op basis van mijn eigen ervaring en ik heb hiervoor verschillende (meta-)studies geraadpleegd. De uitkomsten van deze studies zijn in grote lijnen hetzelfde. Ik heb deze oorzaken ondergebracht in drie hoofdcategorieën.
Oorzaak 1: Haast
Een van de hoofdoorzaken is de druk van boven of om maar iets te kunnen laten zien tijdens de demo of om zo snel mogelijk nieuwe features op te leveren. Ik vergelijk het met Tetris waarbij de brokken werk steeds sneller worden aangeboden en het team geen tijd meer heeft om een goede plek hiervoor te vinden. Het peil stijgt gestaag totdat alles vastloopt.
Wat er regelmatig gebeurt, is dat product owners meer productiviteit willen van het team en gaan "feature pushen". Het team lijkt een machine die resultaten genereert en hoe meer (user stories) je erin stopt hoe meer het produceert. Helaas werkt het niet zo. De honger naar nieuwe features zorgt ervoor dat product owners vaak te weinig tijd overlaten in de sprint voor kwaliteit en verbetering van het bestaande werk.
De neiging om naar de korte termijn te kijken zit in de menselijke aard en het vereist discipline en visie om de focus te verleggen naar de lange termijn.
In zijn boek [The Seven Habits of Highly Effective People] verwijst Stephen Covey naar de balans tussen productie en productiecapaciteit, de P/PC-balans. Wanneer je alleen maar rijdt met je auto en nooit een APK of iets aan onderhoud laat doen zal de motor uiteindelijk niet meer functioneren en kun je helemaal niet meer rijden. Dit principe geldt ook voor software.
Kortom, wanneer de focus te veel ligt op het shippen van nieuwe features en minder op verbeteren dan neemt de kans op fouten toe. Hierdoor kiest het team shortcuts en workarounds, documenteert te weinig of onjuist, test onvoldoende en maakt quick fixes in plaats van structurele oplossingen. Het team wordt minder wendbaar en kan slecht inspelen op veranderende technologieën in de markt, vernieuwde inzichten of het simpelweg upgraden van frameworks.
De problemen bewegen langzaam richting productie en als je geluk hebt openbaren ze zich voor de livegang zodat de eindgebruiker er geen last van ondervindt.
Het gevolg hiervan is dat de productiecapaciteit geleidelijk aan afneemt en de kans groter dat het project buiten budget en planning gaat, toeneemt.
Tevens stemmen teams die onder druk staan te weinig onderling af wat ten koste gaat van de continuous integration. De verschillende applicatie onderdelen worden slecht op elkaar afgestemd.
Oorzaak 2: Valse Start
Onze klant, die ik in mijn vorige blogartikel benoemde, had een ontwikkelteam van de leverancier dat elke sprint minder storypoints aan werk verzette. Wat ik bij deze bewuste klant ontdekte, is dat er in het voortraject onvoldoende was nagedacht over de gewenste kwaliteit en de project- en productrisico’s. Hierdoor neemt het risico op problemen door technische schuld substantieel toe. Zeker de helft van de bugs ontstaan immers in de requirements en designfase [3].
Wat ik het meest heb gezien bij de IT-projecten afgelopen decennium is dat er geen kwaliteitsaspecten of niet-functionele eisen (non-functional requirements) zijn opgesteld voorafgaand aan het project. Mijn collega Uwe Friedrichsen heeft verschillende blogartikelen gewijd aan de businesswaarde van non-functionals. Deze blogs geven inzicht in de waarde en belang van een gedegen voorbereiding waarin niet-functionele eisen worden opgesteld.
Bij het begin van een IT-project moeten de risico’s van het product en het project worden onderkend en hierop moeten maatregelen worden bedacht. Dit gebeurt vaak in een productvisiesessie of een productrisicoanalyse. Hieruit vloeien de kwaliteitsaspecten (niet-functionele eisen / NFR’s) voort. Tezamen met voorgaande producten kan het architecturale ontwerp en het testplan worden gemaakt. Uiteindelijk werkt dit door tot in het developmentteam dat in hun ‘definition of done’ heeft kwaliteit heeft opgenomen.
Er moet dus een aanpak zijn op gebied van kwaliteit dat antwoord geeft op de vragen: ”Hoe richten wij de governance op kwaliteit in? Wie is waarvoor verantwoordelijk? Wat verwachten wij van onze leverancier?”
Zonder bovengenoemde uitgangspunten is het voor een ontwikkelteam moeilijk om geen fouten te maken die vervolgens weer bijdragen aan de technische schuld van een project.
Oorzaak 3: Team
Wanneer er veel verloop is in het team, bijvoorbeeld als er te veel werkdruk is, en er weinig wordt overgedragen of wanneer het team bestaat uit onervaren teamleden kan dit tot gevolg hebben dat er slechtere code wordt opgeleverd. Deze software behoeft meer onderhoud en de achtergebleven teamleden met een erfenis van oude code die ze niet begrijpen. Dit draagt ook bij aan een toename in technische schuld.
Wanneer het team onder druk staat van de business neemt de motivatie af. De overgebleven teamleden zijn niet gemotiveerd zijn om goede kwaliteit te leveren, zullen geen stap meer doen dan wat er gevraagd wordt en dit leidt tot vertrekkende teamleden.
Samengevat
In de onderstaande overzicht heb ik de oorzaken samengevat.
Wat doe je eraan?
Herkenbaar verhaal? Benieuwd naar wat eraan te doen is? In mijn volgende blog en laatste blog bied ik praktische tips en organisatorische adviezen om kwaliteit weer op een hoger plan te krijgen zodat de velocity toeneemt en de opleverdatum niet nog verder naar achteren wordt geschoven.
[1] Bron: Prevalence, Common Causes and Effects of Technical Debt: Results from a Family of Surveys with the IT Industry
[2] Bron: The most common causes and effects of technical debt: first results from a global family of industrial surveys
[3] Bron: SOFTWARE DEFECT ORIGINS AND REMOVAL METHODS, Capers Jones, July 21, 2013
Discussion (0)