Hoe je de wildgroei van software kunt inperken

De symptomen van een wildgroei aan software kunnen in het begin moeilijk te herkennen zijn. Het kan beginnen met kleine ergernissen die terzijde worden geschoven ten gunste van dingen met hogere prioriteit. Maar als er niets aan wordt gedaan, kan een wildgroei ontwikkelteams met een hogere cognitieve belasting verlammen, de betrokkenheid van teams verminderen en de voordelen van een losjes gekoppelde architectuur ongedaan maken. Zoals het spreekwoord zegt: '20 jaar geleden was het beste moment om een boom te planten. Het beste moment daarna is nu.' Met andere woorden, succes in de toekomst is gebaseerd op het temmen van de wildgroei aan software voordat het een probleem wordt.

Hieronder vind je de drie tekenen van een wildgroei in software en wat je kunt doen om de chaos het hoofd te bieden en tegelijkertijd een innovatieve en dynamische omgeving te creëren die het potentieel van elk team benut.

Een vroeg symptoom van wildgroei in software is wanneer meerdere beoordelingen na een incident (PIR's) erop wijzen dat upstream veranderingen de hoofdoorzaak van een incident zijn. Een groeiend aantal microservices en een toenemend aantal veranderingen binnen een omgeving kunnen de bestaande normen op het gebied van samenwerking tussen ontwikkelaars en de coördinatie van veranderingen onder druk zetten. Zelfs een kleine verhoging van de veranderingsfrequentie van maandelijks naar wekelijks voor één gemoderniseerde toepassing kan resulteren in 100 keer meer releases per maand. Geen wonder dat ontwikkelaars hun manier van samenwerken moeten aanpassen. Incidenten doen zich vaker voor in de productie wanneer de normen voor samenwerking tussen ontwikkelaars niet schaalbaar zijn in een snel veranderende omgeving.

Het creëren van een niet-opdringerige manier voor ontwikkelaars om op de hoogte te zijn van upstream en downstream veranderingen is een geweldige manier om de impact van de wildgroei in software in te perken. Binnen Atlassian gebruiken we Compass — een portal voor ontwikkelaars dat teams helpt gedistribueerde architecturen te navigeren — om ontwikkelingsteams in-app notificaties te sturen over ingrijpende veranderingen in de upstream en downstream services. Het bevestigen van deze notificatie geeft de initiatiefnemer van de verandering een signaal dat teams die verantwoordelijk zijn voor afhankelijke services op de hoogte zijn van de verandering. Dit biedt de mogelijkheid om samen te werken aan de verandering als er problemen worden verwacht, waardoor de kans op onbedoelde gevolgen voor de productie wordt verkleind. Aangezien incidenten zich onvermijdelijk voordoen in een dynamische omgeving, is samenwerking tussen ontwikkelaars tijdens een incident van cruciaal belang om services snel te herstellen.

In beoordelingen na een incident waarbij upstream veranderingen de hoofdoorzaak zijn, komt het vaak voor dat de tijd om services te herstellen wordt beïnvloed door de tijd die nodig is om de problematische upstream verandering vast te stellen, samen met het team of de persoon die eigenaar is van de service. Het is logisch dat het verkorten van de tijd die nodig is om de foutieve upstream verandering te identificeren, uiteindelijk ook de gemiddelde tijd tot herstellen (MTTR) verkort. Dit wordt lastiger bij een losjes gekoppelde architectuur, waar services een uitgebreide afhankelijkheidshiërarchie hebben en de hoofdoorzaak van een incident overal plaats kan vinden. Van oudsher doorzoeken incidentresponders de logboeken of veranderingsrecords om vast te stellen welke wijziging mogelijk een incident heeft veroorzaakt. In een dynamische omgeving is dit vergelijkbaar met het zoeken naar een speld in een hooiberg.

Binnen Atlassian gebruiken we de activiteitsfeed in Compass om de MTTR te verminderen. Hierin worden alle gebeurtenissen voor upstream systemen weergegeven, samen met de gegevens van het team dat eigenaar is. Dit verkort de tijd voor het sorteren aanzienlijk door de samenwerking tussen ontwikkelaars te ondersteunen tijdens een incident. Incidenten zullen voor blijven komen, maar het tijdig identificeren van een upstream verandering als hoofdoorzaak van een incident is van cruciaal belang om ervoor te zorgen dat de impact tot een minimum wordt beperkt en de services snel worden hersteld.

De overgang naar een losjes gekoppelde architectuur is één van de belangrijkste onderdelen voor het creëren van de productiviteit en het welzijn van een team: het vermogen om zelfstandig en met veel autonomie te kunnen handelen. Als er niets aan wordt gedaan, kan een wildgroei van software sommige van deze voordelen teniet doen, wat resulteert in een druk maar onproductief en ongelukkig team. Een veelgehoorde klacht bij gesprekken met ontwikkelingsteams is "alles werkt goed totdat we met een ander team in contact moeten komen." Dit wordt nog versterkt wanneer de wildgroei van software een probleem veroorzaakt. Een snel groeiende en veranderende omgeving beperkt de mogelijkheid voor ontwikkelaars om bij te houden wie ze moeten inschakelen voor upstream- en downstream-afhankelijkheden, wat uiteindelijk resulteert in een vertraging en een toename van frustratie bij teams die proberen om snel te presteren.

Hypothetisch gezien kunnen Alpha-team en Beta-team elke week hetzelfde aantal issues en storypoints in Jira naar 'voltooid' verplaatsen. Het Alpha-team besteedt 90 procent van zijn inspanningen om nieuwe functies naar productie te brengen, terwijl het Beta-team 30 procent besteedt aan nieuwe functies en 70 procent aan het uitzoeken hoe ze kunnen omgaan met de vele upstream-services waar ze afhankelijk van zijn. Beide teams hebben dezelfde hoeveelheid output, maar waarschijnlijk wordt alleen Alpha als productief beschouwd. De wildgroei van software maakt de behoefte aan samenwerking tussen teams duidelijker. Het vinden van slimme manieren waarop autonome teams on-demand betrokken kunnen zijn is essentieel om de kracht van een losjes gekoppelde omgeving te benutten.

In een snel groeiende en dynamische omgeving is het vermogen om informatie zelf te beheren belangrijk voor de productiviteit en het welzijn van een team. Eén manier om dit te bereiken is door een gecentraliseerde softwarecomponentencatalogus te implementeren met gedecentraliseerd beheer; dit is een gecentraliseerde catalogus waarbij elk team verantwoordelijk is voor het creëren en updaten van de services die ze bezitten. Traditionele omgevingen hebben gewoonlijk een gecentraliseerde catalogus die wordt beheerd door een specifiek team of specifieke functie. Dit kan echter de snelheid waarmee veranderingen plaatsvinden in een gedistribueerde omgeving niet bijhouden, waardoor teams schaduw-wiki's gaan maken over met wie en hoe ze moeten handelen. Binnen Atlassian hebben we vastgesteld dat een gedecentraliseerde aanpak de onzichtbare en verspilde moeite tussen teams vermindert, de mogelijkheden voor zelfbediening verbetert en een omgeving creëert met on-demand betrokkenheid. Het tegengaan van de wildgroei in software door zelfbedieningsinformatie over upstream- en downstream-afhankelijkheden beschikbaar te maken, is een geweldige manier om de productiviteit van teams te verbeteren, met aanvullende effecten op het welzijn en de betrokkenheid van het team.