Het maken van een succesvolle DevOps-transitie levert zeer tastbare resultaten op, maar is op zichzelf een abstract proces. Inzicht krijgen en overzicht houden zijn alleen al om die reden vaak lastig. In deel 2 van ons vierluik over de succesfactoren in DevOps-transities gaan we in op het belang van meten en monitoren. Daarbij draait veel, zo niet alles, om feedback en transparantie.
Eerder fouten of incidenten ontdekken
Software wordt getest om eventuele fouten te identificeren. Hoe later een fout ontdekt wordt, hoe exponentieel sneller de kosten voor die fout oplopen. Dit wordt duidelijk zichtbaar in watervalprojecten, waar elke nieuwe fase extra kosten met zich meebrengt. Dit geldt al als een fout tijdens het ontwikkelproces ontdekt wordt, en geldt nog nadrukkelijker als de fout onbedoeld in productie genomen is. Hetzelfde geldt voor bevindingen van gebruikers. Hoe eerder het duidelijk is als gebruikers functionaliteit liever anders hadden gezien, hoe eenvoudiger het is om het aan te passen. Door eerder de kwaliteit van het product te testen en feedback te krijgen van de gebruikers kan er sneller een beter product beschikbaar gesteld worden. Bijkomend voordeel van snelle feedback is dat de code en functionaliteit waar het fout ging nog vers in het geheugen van de betreffende developer ligt.
Onbenutte functionaliteit
Zelfs als er geen bugs worden ontdekt, betekent dit niet automatisch dat de release goed is. Bepaalde functionaliteit kan bijvoorbeeld prima werken, maar door (vrijwel) niemand gebruikt worden. Om dit soort verspilling te voorkomen, is het dus ook zaak om te weten, dus te meten, wat gebruikers wel en niet gebruiken en wat ze precies van alle functionaliteiten vinden. Dit kan bijvoorbeeld door het gebruik van een bepaalde functie te monitoren of gebruikers direct te vragen welke functionaliteit ze wel en niet gebruiken. Controleer in dit verband ook regelmatig of iedereen van wie je feedback verwacht er überhaupt wel bij kan.
Transparantie
De transparantie die je met meten en monitoren creëert, heeft in breder verband ook betrekking op data over het ontwikkelproces zelf. Denk hierbij onder andere aan indicatoren ten aanzien van testdekking en gegevens over het aantal opgetreden incidenten. En in hoeverre is die data beschikbaar voor de rest van de organisatie? Op verborgen data kun je immers geen feedback geven of actie ondernemen. Van DevOps-teams wordt verwacht dat ze zelfmanaging zijn en dat kan alleen als ze tijdig en doorlopend over alle relevante informatie beschikken. Dat zorgt ervoor dat het team sneller kan reageren op gevonden fouten en de gebruiker sneller weer verder kan helpen, maar het is ook een manier om te laten zien dat en hoe je met verbeteringen bezig bent.
Work in Progress limieten
Om tijdige en volledige feedback te krijgen, is het tot slot van belang om niet te veel functionaliteiten tegelijk te ontwikkelen. Om te focussen op de belangrijkste functionaliteiten op dat moment, wordt vaak gewerkt met Work in Progress (WIP) limieten. Een WIP-limiet is het maximum aantal brokjes werk waar je tegelijk aan werkt. Hoe lager je die WIP-limiet instelt, hoe sneller een brokje werk klaar is en voor de gebruiker beschikbaar gesteld kan worden. Klanten zien liever elke week een kleine verbetering dan in één keer meerdere verbeteringen, waardoor ze niet meer precies weten wat allemaal in de release zat.
Meten en verbeteren
Door de juiste zaken te meten, krijg je waardevolle informatie over het huidige proces en de waarde die je voor je klanten levert. Stop alleen niet bij het meten, maar zorg voor acties om het proces te verbeteren en de waarde te verhogen. En blijf meten en aanpassen: dit is de basis van continuous improvement.
Benieuwd hoe je dit doet? Neem dan contact op met ons op via 085 487 52 20.
Weten hoe jouw team ervoor staat op het gebied van meten en monitoring? Vraag dan vrijblijvend een gratis online meting aan.
Klik hier om ook deel 1 over cultuur als succesfactor in DevOps te lezen
