De vier beste metrics voor software-ontwikkeling
Hoe goed we ons werk ook doen, het kan altijd beter. En dat vindt men niet alleen in de boardroom. Dat is bij het ene type werk makkelijker te meten dan bij het andere. Zo kan een profbokser eenvoudig zijn overwinningen turven en kan een verkoper bijvoorbeeld wijzen naar omzetcijfers. Ben je dagelijks met software-ontwikkeling in de weer, dan is dat een stuk lastiger. Maar, dankzij een viertal metrics, zeker niet onmogelijk.
Metrics voor software-ontwikkeling
Als je nog geen historische data hebt, moet je domweg ergens beginnen. En waarom niet vandaag? Door data op te bouwen en consequent bij te houden, zul je vanzelf ontdekken of je daadwerkelijk op de juiste weg bent of niet. Om verbetering in je software-ontwikkelingsproces tastbaar te maken, kun je gebruik maken van de volgende vier metrics:
Deployment frequency
Een belangrijke metric, of KPI, is de development frequency, oftewel hoe vaak je met je product naar de productieomgeving of bijvoorbeeld de App of Play Store gaat. Dit kun je handmatig bijhouden, maar ook geautomatiseerd ‘turven’ in Azure DevOps of met een andere tool. Hoe vaker je naar productie gaat, hoe beter. De kans op fouten is daardoor namelijk kleiner en je hebt sneller feedback op wijzigingen.
Lead time for changes
De tweede metric is nauw met de vorige verbonden, namelijk de doorlooptijd van wijzigingen. Dit is de tijd tussen het afronden van de code tot aan het beschikbaar stellen aan de eindgebruiker. Hoe korter de doorlooptijd, inclusief acceptatie van de betreffende wijziging, des te makkelijker je fouten of bugs kunt terughalen. Bovendien is er dan minder kans dat er tussentijds alweer andere wijzigingen zijn.
Mean time to restore
Fouten in software kunnen je dienstverlening tijdelijk ontregelen. De mean time to restore (MTTR) geeft aan hoeveel tijd je nodig hebt om de dienstverlening te hervatten na het optreden van zo’n fout. En hoewel direct foutloze software alleen in onze fantasie bestaat, wil je het ongemak en de gevolgen voor de klant natuurlijk zoveel mogelijk beperken. Te meer omdat je je klanten hierdoor sneller van nieuwe functionaliteiten kunt voorzien.
Change fail rate
Als releases relatief vaak tot incidenten leiden, wat je procentueel kunt uitdrukken met de change fail rate, dan schiet de kwaliteit van de oplevering tekort. Verlopen releases daarentegen vrijwel vlekkeloos, dan ben je kennelijk in control. Dit luxeprobleem zou je kunnen benutten door het tempo wat op te voeren.
Onderlinge samenhang
Realiseer je, tot slot, dat alle vier de metrics elkaar aanvullen en er pas substantiële verbetering optreedt wanneer op alle fronten winst wordt behaald. Je kunt bijvoorbeeld aan de lopend band releasen met een goede lead time, maar als elke release fouten bevat, blijft het geheel achter. Hetzelfde geldt voor de situatie dat alle metrics verbeteren, maar dat het aantal releases per jaar sterk achterblijft. Dan weet je pas veel te laat of je de juiste keuzes hebt gemaakt en wordt het achterhalen van fouten een flinke uitdaging.
Consequent en voor langere tijd
Als je op de aangegeven manier consequent en over langere periode je KPI’s beheert, dan zal vanzelf blijken of je met je software-ontwikkelproces de juiste weg bent ingeslagen. Zeker als je dat ook nog eens geautomatiseerd doet.
Lees hier meer over het belang van ‘meten’ als succesfactor van DevOps. Wil je (nog) meer weten? Neem dan gerust contact op met Heiko Wijtenburg via heikow@delta-n.nl of op 085 487 52 20.
