zoals ik opmerkte in het artikel “Why metrics don’ t matter in software development (unless you pair them with business goals),” het kiezen van metrics vereist veel aandacht en zorg om de specifieke vragen te ondersteunen die een bedrijf echt nodig heeft om te beantwoorden. Hier is het kritieke punt: metingen moeten alleen worden ontworpen als een manier om zakelijke vragen te beantwoorden. En die vragen zijn nooit, ” hoeveel KLOCs zijn we tot nu toe?”
dit artikel gaat verder waar het vorige ophield, door eerst de specifieke metrics te bespreken die elk team zou moeten gebruiken, of tenminste van plan te zijn om het te gebruiken zodra een manier is om merkbare prestaties te verbeteren. Merk op dat de titel van dit artikel beweert dat er “9 metrics die een verschil kunnen maken…”—want wat echt belangrijk is, wat echt een verschil zal maken, is hoe die metrics daadwerkelijk worden gebruikt om de bedrijfswaarde te verbeteren. Dat gebruik is aan jou. Vervolgens wordt in dit artikel uitgelegd hoe u deze metrics kunt combineren om Betekenis te creëren en een bedrijfswaardehypothese kunt formuleren en testen.
begin met het meten van de juiste dingen
hier zijn negen objectieve metrics (gemarkeerd door opsommingstekens) die u continu moet controleren, om incrementele verbeteringen aan processen en productieomgevingen te maken. Verbeteringen in deze aantallen zullen niet garanderen dat uw klanttevredenheid zal stijgen met sprongen en grenzen. Maar dit zijn tenminste de juiste dingen om te meten. In een later deel van dit artikel, “alles in elkaar zetten”, zul je zien waarom.
Agile process metrics
voor agile en lean processen zijn de basismetrics productietijd, cyclustijd, teamsnelheid en open/close rates. Deze statistieken helpen planning en informatie beslissingen over procesverbetering. Hoewel ze geen succes of toegevoegde waarde meten, en ze hebben niets te maken met de objectieve kwaliteit van de software, moet je ze toch meten. Ik zal uitleggen waarom hieronder.
- Doorlooptijd – Hoe lang het duurt om van idee naar geleverde software te gaan. Als u meer wilt reageren op uw klanten, werken aan het verminderen van uw productietijd, meestal door het vereenvoudigen van de besluitvorming en het verminderen van de wachttijd. Productietijd omvat cyclustijd.
- cyclustijd – hoe lang het duurt om een wijziging in uw softwaresysteem aan te brengen en die wijziging in productie te brengen. Teams die continue levering gebruiken, kunnen cyclustijden hebben gemeten in minuten of zelfs seconden in plaats van maanden.
- teamsnelheid-hoeveel” eenheden ” software het team doorgaans voltooit in een iteratie (ook wel “sprint”genoemd). Dit nummer mag alleen worden gebruikt om iteraties te plannen. Het vergelijken van teamsnelheden is onzin, omdat de metriek is gebaseerd op niet-objectieve schattingen. Het behandelen van snelheid als een succes maatregel is ongepast, en het maken van een specifieke snelheid in een doel verstoort de waarde voor schatting en planning.
- open/close rates – hoeveel productieproblemen binnen een specifieke periode worden gerapporteerd en afgesloten. De algemene trend is belangrijker dan de specifieke nummers.
wanneer een of al deze cijfers buiten het verwachte bereik liggen of in alarmerende richtingen trending geven, neem dan geen oorzaak aan. Praat met het team, krijg het hele verhaal, en laat het team beslissen of er reden tot bezorgdheid is, en zo ja, hoe het te repareren.
u kunt de onderliggende oorzaken van de getallen niet kennen of aannemen, maar deze metrics geven u inzicht in waar uw essentiële processen aandacht nodig hebben. Een hoge open rate en een lage close rate over een paar iteraties, bijvoorbeeld, kan betekenen dat de productie problemen zijn momenteel een lagere prioriteit dan nieuwe functies, of misschien dat het team is gericht op het verminderen van de technische schuld om hele klassen van problemen op te lossen, of dat de enige persoon die wist hoe ze op te lossen stoppen, of iets anders. Je kunt de oorzaken van de getallen niet kennen of aannemen.
Productieanalyse
- Mean time between failures (MTBF)
- Mean time to recover/repair (MTTR)
beide zijn algemene maatstaven van de prestaties van uw software systeem in de huidige productie-omgeving.
- crashsnelheid van toepassingen-hoe vaak een toepassing mislukt gedeeld door hoe vaak het is gebruikt. Deze metriek is gerelateerd aan MTBF en MTTR.
merk op dat geen van deze drie statistieken u vertelt over individuele functies of gebruikers beïnvloed. Hoe kleiner de getallen, hoe beter. Moderne operations-monitoring software maakt het verzamelen van gedetailleerde metrics op individuele programma ‘ s en transacties vrij eenvoudig, maar het kost tijd en zorgvuldige gedachte om het opzetten van de juiste ranges voor waarschuwingen en/of triggers voor het opschalen van omhoog of omlaag (voor cloud-gebaseerde systemen).
we willen dat onze software nooit faalt, maar dat is statistisch onwaarschijnlijk. Wanneer onze software niet, we zouden willen dat het nooit verliezen geen kritieke gegevens en onmiddellijk te herstellen, maar dat kan buitengewoon moeilijk te bereiken. Als uw software is uw bron van inkomsten, echter, de inspanning is de moeite waard.
naast MTBF en MTTR zijn meer fijnkorrelige metingen gebaseerd op individuele transacties, toepassingen, enzovoort, en zij weerspiegelen de geleverde bedrijfswaarde en de kosten van het verhelpen van storingen. Als uw transactie-verwerking applicatie crasht een keer op de honderd, maar herstelt in een tweede of twee en verliest geen kritische informatie, dat 1 procent crash percentage kan goed genoeg zijn. Maar als elke crash is van een app die loopt 100.000 transacties per dag, verliest een $100 verkoop, en kost $ 50 om te herstellen op de back-end, dat 1 procent crash percentage gaat een prioriteit zijn. Vaststelling van het zal de bottom line aanzienlijk beïnvloeden.
Beveiligingsmetrics
beveiliging is een aspect van softwarekwaliteit dat vaak tot later (of te laat) over het hoofd wordt gezien. Security analysis tools kunnen worden gebruikt in het bouwproces, in aanvulling op meer gespecialiseerde evaluaties en stresstests. Beveiligingsvereisten zijn vaak eenvoudig en gemeenschappelijk-sensitief, maar de software development team moet zich bewust zijn van hen, en van de statistieken afgeleid van hen.
het volledige scala aan beveiligingspraktijken en gerelateerde metrics valt buiten het toepassingsgebied van dit artikel, maar net als bij agile process metrics en productie metrics, zijn er een paar specifieke metrics die veel kunnen betekenen voor de algemene tevredenheid van uw klanten.
- eindpunt incidenten-hoeveel eindpunten (mobiele apparaten, werkstations, enz. heeft u gedurende een bepaalde periode een virusinfectie ervaren?
- MTTR (mean time to repair)—in beveiligingsstatistieken is dit de tijd tussen de ontdekking van een beveiligingsinbreuk en een geà mplementeerde, werkende remedie. Zoals met de productie MTTR-metriek hierboven vermeld, moet de veiligheid MTTR worden gevolgd over specifieke tijdsintervallen. Als de MTTR-waarde na verloop van tijd kleiner wordt, worden ontwikkelaars steeds effectiever in het begrijpen van beveiligingsproblemen zoals bugs en hoe ze op te lossen.
voor beide metrics betekent een kleiner aantal na verloop van tijd dat u in de juiste richting gaat. Minder endpoint incidenten spreekt voor zich. Naarmate de MTTR waarde kleiner wordt, worden ontwikkelaars steeds effectiever in het begrijpen van beveiligingsproblemen zoals bugs en hoe ze op te lossen.
u kunt meer manieren vinden om beveiligingsstatistieken toe te passen op softwareontwikkeling in de artikelen Application Security for Agile Projects and Security Threat Models: An Agile Introduction.
een notitie over broncode metrics
vandaag is het eenvoudig om een broncode scanner in uw build pipeline en produceren massa ‘ s van objectieve metrics. Er zijn empirische gemiddelden en voorgestelde bereiken en logische argumenten over het relatieve belang van deze metrics. Maar in de praktijk zijn deze hulpmiddelen het meest behulpzaam bij het afdwingen van codeerstijlen, het markeren van bepaalde anti-patronen en het identificeren van uitschieters en trends.
het is gewoon niet de moeite waard om vast te houden aan de getallen. Hier is een voorbeeld, ter verklaring.
stel dat je een methode vindt in een klasse met een belachelijke metriek, zoals een npath-complexiteit van 52 miljoen. Dat betekent dat er 52 miljoen testcases nodig zijn om elk pad door de code volledig uit te oefenen. Je zou de code kunnen herstofferen in een eenvoudiger structuur, maar voordat je dat doet, overweeg wat de zakelijke impact zou zijn. De kans is groot dat de oude, lelijke code goed genoeg werkt (hoewel de testdekking ontoereikend kan zijn). Het oproepen van de anti-patroon aan het team, zodat ze kunnen voorkomen dat herhalen het is waardevol leren, maar de vaststelling van het waarschijnlijk zou niet de naald op een relevante zakelijke metriek.
het is het beste als het team instemt met het niveau van naleving en de regels waaraan hun code wordt onderworpen, maar wees ervan bewust dat het onderzoeken van uitschieters en het zich zorgen maken over trendstoringen veel tijd kan verspillen.
voeg het allemaal samen: Succes is de ultieme maatstaf
het plezier van het gebruik van geautomatiseerde tools voor het bijhouden en meten van kwaliteit metrics en user analytics is dat het tijd vrijmaakt om zich te concentreren op de statistieken die er echt toe doen: succes metrics.
hoe metrics voor succes te gebruiken
bedrijven hebben doelen. Doelen impliceren vragen ,zoals ” Hoe ziet succes eruit?”of” hoe zal dit het gedrag van klanten beïnvloeden?”Goed gekwantificeerde vragen impliceren metrics.
anders gezegd, metrics moeten alleen worden gebruikt om vragen te beantwoorden, om hypothesen te testen die een specifiek bedrijfsdoel ondersteunen. En dit mag alleen worden gedaan zolang de vragen en antwoorden helpen om positieve veranderingen te stimuleren.
hebben niet alle projecten in het algemeen een aantal invariante doelen, vragen en hypothesen, en dus metrics?
Ja, maar alleen vanuit het oogpunt van het bedrijf. Bedrijfsniveaumetingen van zaken zoals gebruikersbetrokkenheid, nauwe tarieven, het genereren van inkomsten, enzovoort, geven feedback over hoe het bedrijf het doet in de echte wereld. Wijzigingen in software die van invloed zijn op het bedrijf zal ook van invloed zijn op dit soort statistieken.
op een fijner resolutieniveau kan elk kenmerk en gebruikersverhaal zijn eigen succesmeting hebben—bij voorkeur slechts één, en één die direct gerelateerd is aan een waardemaat die aan de klant wordt geleverd. Het voltooien van negen van de tien verhalen in een sprint voor functies die nooit worden geleverd is verspilling, geen succes. Het leveren van verhalen die klanten niet willen of gebruiken is verspilling, geen succes. Het leveren van een verhaal dat een aspect van het geluk van de gebruiker verbetert is een succes. Het leveren van een verhaal dat aantoonbaar de betrokkenheid van gebruikers niet verbetert, is ook een succes, omdat je iets hebt geleerd dat niet werkte, een zakelijke hypothese ongeldig heeft gemaakt en middelen hebt vrijgemaakt om andere wegen te volgen.
Hoe formuleer je een waardehypothese
een waardehypothese is een statement over wat je denkt dat er zal gebeuren als gevolg van de levering van een specifieke functie. De relatie tussen de software, het gewenste resultaat, en de statistieken vormt de waarde hypothese voor de functie (of systeem, of verhaal, of upgrade, enz.). De hypothese moet uitdrukken hoe de beoogde metriek naar verwachting zal veranderen, in welk tijdsbestek, en door hoeveel te worden beschouwd als effectief. Je zal moeten praten met het team en de eigenaar van het product, op zijn minst, om erachter te komen het specifieke ding deze functie of verhaal is bedoeld om te creëren of te verbeteren met betrekking tot het bedrijf om de waarde hypothese te formuleren. Je moet misschien een paar keer vragen “waarom” (zoals een driejarige) om de lagen van niet-gespecificeerde veronderstellingen af te pellen; wees geduldig. Wanneer u begrijpt wat de zakelijke waarde wordt verondersteld te zijn, kunt u beginnen met het stellen van de vragen die u zal leiden tot de statistieken die de vraag te beantwoorden.
bijvoorbeeld, een “technisch” verhaal om de snelheid van een e-commerce checkout proces te verbeteren kan als onderliggende veronderstelling hebben dat een snellere checkout zal leiden tot meer verkoop. Maar waarom denken we dat? Zijn er veel mensen die hun winkelwagentjes verlaten tijdens het afrekenproces? Als dat de consensus is (omdat die consensus wordt ondersteund door basisgegevens), dan is de waarde hypothese kan zijn “wij geloven dat een sneller checkout proces zal resulteren in lagere kar-verlaten tarieven, wat leidt tot een hogere omzet en een verbeterde gebruikerservaring.”
je kunt waarschijnlijk aannemen dat gebruikers sneller afrekenen leuk vinden, maar het kan geen kwaad om te vragen of ze het gemerkt hebben. Kar-verlating tarieven en verkoop kan worden gemeten voor en na het nieuwe proces is ingevoerd, voor een periode van tijd. Als de cart-verlating rate daalt en de verkoop te verhogen (voorbij statistische schommelingen), het bewijs ondersteunt de hypothese en je zou kunnen overwegen of nog verdere snelheidsverbeteringen zijn gerechtvaardigd. Als ze niet, laat deze metriek vervagen in de achtergrond (of verwijder het, als het afleidend), en richt uw aandacht op de volgende hypothese. Als het percentage karrenverlating daalt maar de verkoop ongewijzigd blijft, meet dan voor een langere periode of heroverweeg het veronderstelde verband tussen karrenverlating en verkoop. Met andere woorden, gebruik statistieken om te leren, en alleen zolang ze nuttig zijn voor het rijden verbeteringen.
in sommige gevallen kan de hypothese duidelijk verkeerd zijn, dus laten we de metrics vallen (en maken de softwarewijzigingen ongedaan!) na een paar dagen. In andere gevallen kan de hypothese juist zijn, dus blijven we jarenlang verbeteringen op dit gebied stimuleren.
Six heuristics for effective use of metrics
we hebben gezien hoe subjectieve softwaremetrics veel belangrijker zijn voor zakelijk succes dan de traditionele, objectieve kwaliteitsmetrics van vroeger. De inspanning die nodig is om relevante bedrijfsstatistieken voor functies te vinden en te meten, wordt gecompenseerd door de inzichten en leermogelijkheden die zijn opgedaan. Zakelijke omstandigheden en kansen veranderen voortdurend, dus in plaats van een formule samen te vatten om te volgen, die fragiel kan zijn, hier zijn zes vuistregels, of heuristiek, om te helpen de focus en flexibiliteit te behouden. Mogen zij u begeleiden op uw reis naar kwaliteitssoftware en zakelijk succes!
- Metrics kunnen u het verhaal niet vertellen; alleen het team kan dat doen (met een tip voor Todd DeCapula).
- het vergelijken van sneeuwvlokken is afval.
- u kunt bijna alles meten, maar u kunt niet overal op letten.
- Business success metrics drive software verbeteringen, niet andersom.
- elke functie voegt waarde toe; meet het of doe het niet.
- meet alleen wat er nu toe doet.