Vijf beste software engineering KPI’s, en hoe ze worden bedrogen

Door Bill Harding,Programmeur/CEO
Gepubliceerd op 31 maart 2020.Laatst bijgewerkt op 17 april 2020.

Wanneer mensen het hebben over engineering KPI’s, zijn er twee tegenstrijdige gemeenplaatsen die men vaak hoort:

Wat gemeten wordt, wordt beter.-Peter Drucker

En

Wanneer een meting een doel wordt, houdt het op een goede meting te zijn.-Wet van Goodhart

Beide van deze verklaringen beschrijven engineering KPIs gedeeltelijk, maar samen impliceren zij dat het onmogelijk is om meting te gebruiken om te verbeteren. Hoe kan een data-gedreven manager deze kloof overbruggen?

Het slechte nieuws is dat het enige toewijding vergt om te leren, vooral voor diegenen die uit afstandelijke (d.w.z., niet-technische) rollen komen. Het goede nieuws is dat zorgvuldig gekozen metrieken kunnen blijven werken en dat ook doen, ondanks dat zij “een doel worden”. In feite, voor veel van de metingen die we zullen aanbevelen, hoe meer een werknemer “het systeem bespeelt”, hoe meer de langetermijnbelangen van het bedrijf worden gediend. Het einddoel zijn metingen die blijven werken terwijl ze “gespeeld” worden. Er zijn vijf metingen die aan deze lat voldoen. Doelpubliek: Actiegerichte Manager

Elke manager die heeft geprobeerd om meer voltooide tickets uit zijn engineeringteam te krijgen, kent de worsteling. Zij willen eerlijke, op gegevens gebaseerde acties ondernemen die hun snelheid verbeteren. Zij weten dat beslissingen nemen op basis van buikgevoel duur is en niet schaalbaar. Toch, als ze naar hun to-do lijst kijken, staat deze vol met taken die dringender lijken dan “verbeter de metingen”. In de praktijk gebeurt het meten vaak na een catastrofale mislukking, zoals een buggy release build of de constatering dat een ontwikkelaar al een maand geen tickets meer heeft gesloten.

Zelfs als het duidelijk is dat er gemeten moet worden, is het onduidelijk waar te beginnen. Je kunt “engineering KPI’s” googelen, de hele eerste pagina met resultaten doorklikken, en dan nog onduidelijk blijven over welke volgende stappen je moet nemen. Neem de vaak aangeprezen metric “Team Velocity” als voorbeeld. Bijna elk Google resultaat beveelt aan om “Team Velocity” te meten, maar niemand wil zeggen of het wordt gemeten in… gesloten tickets? Regels code? Verhaalpunten? Wat het ook is, managers hebben geen tijd om het uit te zoeken. Ze moeten van deze 15.000 voet berg van theorie naar beneden in iets wat ze kunnen begrijpen, vertrouwen, en profiteren van … bij voorkeur onmiddellijk.

De organiserende premisse van dit artikel is dat je een manager die wil software engineeringmetrics begrijpen net goed genoeg om je team effectiever te maken. Het zijn van een manager betekent dat je het te druk om te leren over theorie, behalve waar het direct terug naar hoe je kunt profiteren van die theorie.

Metrics moet praktisch zijn voor echte bedrijven om uit te proberen

Voor het schrijven van dit artikel, we verteerd de metrieken voorgesteld door de top 20 Google-resultaten op het domein vansoftware metrics. Zoals je je kunt voorstellen, had elke bron zijn eigen theorieën over welke metrieken het meest van belang waren.Hun artikelen verdeelden vaak metrieken in groepen als “proces metrieken” en “project metrieken.” Wij zullen hun aanwijzingen voor het groeperen van metrieken volgen, maar onze groepen zullen “kwaliteitsmetrieken” en “al het andere” zijn.

Hier volgt wat kwalificeert als een kwaliteitsmetriek:

  • Bedrijfswaarde.Is het mogelijk om een rechte lijn te trekken van metriek => gecreëerde bedrijfswaarde?
  • Meetbaar.Kunnen wij een specifiek aantal en zijn meeteenheden (b.v.., punten, percentage), zodat het kan worden gevolgd in de tijd en gecorreleerd met gebeurtenissen en experimenten?
  • Actiegericht: kan het regelmatig worden gebruikt om actie te ondernemen die leidt tot positieve resultaten? Bij voorkeur met zo min mogelijk valse positieven?
  • Beschikbaar/geschikt.Kan een gemiddeld software engineering team toegang krijgen tot deze metric zonder hun bestaande ontwikkelprocessen te veranderen?
  • Populair.Heeft het genoeg aanhang om goed gedocumenteerd en geloofwaardig te zijn?
  • Opname in de “Quality Metrics” emmer vereist alle vijf van de bovenstaande, plus een bevredigend antwoord op onze strikte vraag: als we deze metric vertrouwen, en ontwikkelaars vervolgens optimaliseren voor het, wat gebeurt er dan? In onze jaren doorgebracht met het bouwen en itereren van onze eigen ontwikkeling metric (“Line Impact”), hebben we geleerd dat giftige bijproducten een verwacht gevolg zijn van het meten, tenzij de metric precies is afgestemd op de lange termijn business waarde.Als voorbeeld zullen we later laten zien hoe ontwikkelaars die de “Lead Time” metriek proberen te bespelen, verminderde transparantie voor het management veroorzaken.

    Quality engineering KPI’s

    Hier zijn vijf software metrieken die alle vakjes aanvinken om managers te helpen een efficiënter team te runnen.

    🏦 OKR-gedreven

    Voorbeeld van OKR-sjabloon

    Eén van de vele voorbeeld OKR-sjablonen die via Weekdone beschikbaar zijn op Okrexamples.com

    Een lijst die is gericht op het maximaliseren van de bedrijfswaarde zou hier moeten beginnen. Toonaangevende bedrijven zoals Google gebruiken OKRsas een primaire as waarop hogere ingenieurs worden geëvalueerd. Het nadeel van OKR-gedreven metrieken is dat zij, per definitie, specifiek zijn voor bedrijfsbijzonderheden. Dit maakt het onmogelijk om een formule te veralgemenen waarmee zij kunnen worden vastgelegd, of om de weg te veralgemenen waarlangs zij zullen worden gespeeld.

    Hoe het te spelen? Het risico dat OKRs worden gespeeld is laag aangezien zij gewoonlijk business-centric zijn. Het grootste gevaar van op OKR’s gebaseerde metingen is dat ze, omdat ze meestal eenmalig (of periodiek) worden geformuleerd, misschien minder betrouwbaar zijn dan metingen die jarenlang zijn doorgelicht. Er zijn altijd mogelijke randgevallen die op de loer liggen. Bijvoorbeeld, een OKR instellen op “minder dan 10 bugs per maand introduceren” zou kunnen worden omzeild door geen nieuwe functies te lanceren. Ervan uitgaande dat beide partijen te goeder trouw zijn, zou het spelen met OKR’s in de praktijk zeldzaam moeten zijn.

    Hoe krijg je het? Via bestaande meetdashboards, of door samen te werken met bedrijven alsWeekdone die helpen bij het bieden van OKR-inspiratie.

    📐Line Impact

    Voorbeeld engineering KPI Line Impact: betrouwbare broncode metric

    10 repo’s in kaart gebracht op basis van hun Line Impact, een metric die de snelheid kwantificeert waarmee broncode evolueert,image courtesy GitClear

    Line Impact is een metric die is ontworpen om te meten hoeveel cognitieve energie er wordt gestoken in softwareontwikkeling.Deze video biedt een geïllustreerde uitleg over hoe dat mogelijk is. De korte uitleg is dat Line Impact alle tussentijdse activiteit (“churn”) die plaatsvindt als een functie wordt ontwikkeld, elimineert, waardoor een geconcentreerde belichaming van het werk dat plaatsvond overblijft. Line Impact wordt behouden tussen talen, dus het kost een consistente hoeveelheid tijd om Line Impact te genereren of de ontwikkelaar nu Java, Python, Javascript of een andere grote programmeertaal schrijft (30+ ondersteund).

    In termen van zakelijke waarde, Line Impact parallelliseert Story Points: het illustreert hoe de kosten van een taak fluctueren afhankelijk van de ontwikkelaar aan wie het is toegewezen. Van dit, kan een geëngageerde manager het Rapport van de Domeinexperts gebruiken om Jiras aan subject materieexperts te matchen, die productversnelling drastisch kunnen versnellen.

    Hoe te spelen? Om het even welke metriek die “Lijnen van Code” (LoC) als gegevensbron (zoals Lijnimpact) claimt verdient het om met voorzichtigheid te worden benaderd. Dat is waarom GitClear de beste code review tools op de markt heeft gebouwd: zodat managers en ontwikkelaars kunnen zien hoe Line Impact wordt uitgedeeld op een per-commit, per-bestand basis. Transparantie is een krachtig tegengif om gaming tegen te gaan.

    Extra bescherming komt in de vorm van notificaties die getriggerd worden als een ontwikkelaar werk bijdraagt met een ongewone snelheid. Deze en andere maatregelen hebben het moeilijk genoeg gemaakt om Line Impact te bespelen, zodat GitClear nog geen klant heeft ontvangen die meldt dat Line Impact met succes door hun team is bespeld.Dat gezegd hebbende, zou het niet eerlijk zijn om te beweren dat de metric op de een of andere manier ongevoelig is voor gokken, dus hier is een lijst met bekende paden om snel Line Impact te vergaren. De essentie is dat als een ontwikkelaar tests schrijft, oude code verwijdert, en documentatie toevoegt, ze eenoutsized deel van Line Impact zullen verdienen.

    Hoe te verkrijgen? Meld je aan voor een gratis 15 dagen proefversie. Als het bevalt, begint de prijs bij $9 per actieve ontwikkelaar. Bekijk hier een korte uitlegvideo over Line Impact. On prem-versie beschikbaar.

    🎲 Story Points

    engineering KPI's: Jira burndown rapport

    Op story points gebaseerd “release burndown” rapport, beschikbaar via Jira

    Story Points zouden kunnen beweren de meest “klassieke” van engineering KPI’s te zijn. Er zijn veel verschillende manieren om Story Points te berekenen. Alle vormen komen terug op een schatting van de verwachte tijd van de ontwikkelaar om een taak te voltooien. Managers kunnen Story Points gebruiken om de kosten te berekenen die een taak met zich meebrengt, bijvoorbeeld, als een ontwikkelaar $10k/maand verdient, het ticket wordt geschat op 10 Story Points = de helft van de maand, dan zijn de kosten $10,000 * 0.5 = $5,000. Het gebruik van een versie van die berekening helpt bij het prioriteren van taken op basis van welke de hoogste verhouding van geprojecteerde waarde / geprojecteerde implementatiekosten opleveren.

    Hoe het te spelen? De meeste aandacht hier behoort toe aan hoe de Story Points worden berekend. De gemakkelijkste manier om Story Points te “spelen” is voor het ontwikkelaarsteam om de beoordelingsschaal te vertekenen, meestal in de richting van overschatting van de moeilijkheidsgraad. Een optie om dit aan te pakken is om taken te laten selecteren in een “takenmarktplaats”, waar overgewaardeerde taken gelijkmatig kunnen worden verdeeld tussen ontwikkelaars om relatieve kalibratie te behouden. Een andere manier om dit aan te pakken is om de constante die gebruikt wordt om Story Points te vertalen in “ontwikkelaarsdagen” regelmatig opnieuw te kalibreren. Merk op dat aangezien de implementatie van Story Points vaak per team verschilt, het niet aan te raden is om ze te gebruiken om team-overschrijdende prestaties te vergelijken.

    Hoe te verkrijgen? De meeste issue trackers aan deze kant van GitHub maken het mogelijk om Story Points te specificeren. In termen van het bekijken ervan, biedt Jira een “next-gen velocity report” gewijd aan het doel om Story Points te laten zien die in de loop van de tijd zijn voltooid. Ze bieden ook een “release burndown report” dat Story Points gebruikt om in te schatten hoe het team op weg is naar hun doelen voor de sprint. GitClear biedt ook rudimentaire (voor het moment) grafieken die Story Points voltooid in de tijd illustreren.

    🐞 Bug Rate / Escaped Defects

    Deze metric wordt op verschillende manieren gedefinieerd door verschillende bronnen, maar ze komen allemaal op dezelfde essentiële vraag: hoeveel bugs komen er in de wereld, en hoe goed reageren we op hen?Stackify heeft het in specifieke numerieke termen:

    Uw defect escape rate wordt uitgedrukt in een percentage gebaseerd op hoeveel defecten u vindt voordat ze in productie komen of hoeveel er in productie komen, net wat u wilt. Elk software project en team zal anders zijn, maar wij stellen voor om te streven naar 90% van alle defecten te vinden voordat ze in productie komen.

    Stackify’s definitie gaat ervan uit dat men een veld in hun issue track aanwijst om vast te leggen in welke fase van ontwikkeling de bug zich voordeed. Voor teams die niet de tijd hebben om ontwikkelingsfasen op te zetten en te volgen, kan een vervangende definitie zijn:

    Hoe vaak wordt de code die in een nieuwe eigenschap wordt geschreven code die in de loop van het oplossen van een insect wordt veranderd?

    Een data-gekoppeld antwoord op deze vraag wordt verstrekt aan GitClear gebruikers, maar is moeilijk handmatig te berekenen (als je geen GitClear gebruiker bent).Een gegarandeerd-beschikbare fallback meting van bug rate kan zijn “wat is de verhouding van gemaakte bugs versus opgeloste bugs”?

    Hoe te spelen? Deze metric is moeilijk te spelen. Een ontwikkelaar kan meer kleine tickets aannemen, maar elk ticket introduceert eenincrementeel risico van bugs als zij niet voorzichtig zijn. Dit risico van het gebruiken van Bug Rate is dat het een tegenwicht voor “vooruitgang” zoals Verhaalpunten of Lijnimpact nodig heeft, anders zou een ontwikkelaar op één enkel probleem voor de volledige sprint kunnen blijven hangen, verzekerend een 0% insectenpercentage.

    Hoe het te krijgen? Als uw team de bandbreedte heeft om kwesties door de fase van ontwikkeling te etiketteren waarin zij voorkwamen, dan kunnen de Ontsnapte Defecten manueel door om het even welke issue tracker worden berekend. GitClear is een andere beschikbare optie om het percentage features dat bugs wordt te berekenen.

    ✅ Pull Request Completion Rate

    Voorbeeld engineering KPI Pull Requests: statistieken op GitClear

    Een greep uit de pull request statistieken van GitClear

    Hoeveel procent van de pull requests zijn binnen een week nadat ze zijn geopend gesloten? Dit roept verschillende meer granulaire vragen op, zoals “is het team bezig om snel te reageren op nieuwe pull requests,” “zijn ze in staat om samen te werken,” en “hebben de ontwikkelaars hun code opgepoetst voordat ze het voor merge indienen?”

    Hoe het te spelen? De “Pull request completion rate” test halen betekent altijd PR’s binnen een week sluiten. Dit is relatief moeilijk te spelen, maar het moet worden gecompenseerd door een voortstuwende kracht, zoals Story Points of Line Impact, anders zullen alle stimulansen van het team zijn om werk op te poetsen in plaats van het te verzenden (of het in te dienen voor PR-review).Alle leveranciers van Engineering Insight (GitClear, Pluralsight, Code Climate, Pinpoint) bieden statistieken die de efficiëntie van het pull-request proces van een team illustreren. We helpen de leveranciers hier te vergelijken.

    Eervolle vermeldingen

    Onder de “top tier” metrieken, vinden we een tussenlaag. Dit zijn meetmethoden die naast gewenste kenmerken ook belangrijke tekortkomingen hebben. Ze kunnen nog steeds waarde leveren, zolang een manager genoeg weet om rekening te houden met hun beperkingen.

    Lead Time/Cycle Time

    Lead Time grafiek zoals gevisualiseerd via Azure Devops

    Hoewel deze wordt vermeld (twee keer!) in de lijst van Top 5 Metrics van Puralsight, is Cycle Time een goed idee dat zeer vatbaar is voor gaming.

    “Lead Time” wordt meestal gedefinieerd als “Wat is het interval tussen het moment dat een taak wordt ingediend in de issue tracker en het moment dat deze wordt afgeleverd bij de klant?” Zijn neef, “Cycle Time,” is een subset van Lead Time, gedefinieerd als “de tijd tussen het moment dat het productteam het uit de wachtrij heeft geplukt en het moment dat het de productie heeft bereikt.”

    Hoe te spelen? Lead Time prestaties hangen tot op zekere hoogte af van het mechanisme waarmee Jiras worden ingediend, wat betekent dat de toepasbaarheid ervan tussen teams laag is. Cyclustijd hangt af van de conventies waarmee de committer kiest om zijn eerste commit te doen. Dus, deze metric is eenvoudig te bespelen als een ontwikkelaar zijn commits lokaal opslaat en ze in één keer vrijgeeft, direct voordat hij het PR indient. Dit falen is wat Cycle Time naar de “Eervolle vermeldingen” sectie verwijst. Ook niet ideaal: door een ontwikkelaar te stimuleren om zijn commits op te sparen zonder te pushen, is het onmogelijk voor teamgenoten om in te grijpen terwijl dat werk bezig is.Dit neveneffect vermindert de transparantie tussen een manager en hun ontwikkelaars.

    Hoe krijg je het? Azure Devops Services biedt de bovenstaande grafiek.Jira biedt er ook een versie van.Alle grote Engineering Insight-aanbiedingen (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementeren een of andere versie van de berekening van de doorlooptijd.

    Testdekking

    Proberen om een zekere mate van testdekking vast te leggen is een redelijk doel om te overwegen na te streven. Echter, het maakt niet helemaal de cut als een Top Tier metric om twee redenen:

  1. Het is een onvolledige oplossing. Adequate tests moeten functionele en integratietests omvatten naast unit tests, en geen geautomatiseerde oplossing kan weten welke pagina’s moeten worden bezocht binnen de app of website, dit vereist nog steeds menselijke sturing
  2. Het is erg moeilijk om terug te koppelen naar top-line business metrics. Testdekking is de moeite waard om te beoordelen als onderdeel van het plan van een hoofdontwikkelaar om de kwaliteit van de code te bewaken, maar het is niet direct genoeg verbonden met de bedrijfswaarde om de cut te maken op zichzelf. Een verwante maar meer bedrijfs-functionele metriek om defecten in code te volgen is “Bug Rate / Escaped Defects.”

“Everything Else” Metrics

De lijst hierboven is betrekkelijk kort vergeleken met het corpus van vroegere metrieken die door andere auteurs zijn voorgesteld.Voor de volledigheid, laten we eens kijken naar enkele van de meest genoemde meeteenheden elders, en waarom ze niet de cut.

Team Velocity

Dit was een van de meest populaire meeteenheden aangehaald door andere artikelen. Het wordt aanbevolen doorTechBeacon, InfoPulse, enSeaLights.io.Echter, auteurs lijken terughoudend om de eenheden van deze belangrijke metriek te definiëren.TechBeacon definieert het als “hoeveel ‘eenheden’ van software het team typisch voltooit in een iteratie.” Niet tastbaar. InfoPulse probeert geen eenheden te specificeren. SeaLights zegt dat de eenheden “Story Points” zijn. Dus concluderen we dat het begrip “snelheid” adequaat wordt weergegeven door Story Points, of Line Impact bij benadering.

Code Churn

De CEO van GitPrime (nu overgenomen door Pluralsight) behoorde tot degenen die ervoor pleitten om Code Churn in aanmerking te nemen. Wij stellen in antwoord daarop dat de implicaties van Code Churn alle kanten op gaan, wat het erg moeilijk maakt om op te treden tegen hoge churn. Metrieken moeten uitvoerbaar zijn.

Release/Sprint Burndown

SeaLights en InfoPulse bevelen aan aandacht te besteden aan hoe een team zich ontwikkelt in de richting van hun sprintdoelen. Wij zijn het ermee eens dat dit belangrijk is, maar het wordt al gedekt door de “Story Points”-sectie hierboven.

Mean time to repair / Mean time between failures

Van de handvol artikelen die deze metrieken verdedigen, is er geen die beschrijft in welke eenheden de metriek is gebaseerd, of welke service kan worden gebruikt om deze datapunten te verzamelen.Onderzoek heeft uitgewezen dat Atlassian een help-artikel over dit onderwerp biedt.Als dit artikel niet al 2500 woorden lang was, zou MTTR de “Eervolle vermeldingen” sectie kunnen halen. Maar het is niet eenvoudig om het terug te koppelen naar de zakelijke waarde, en het is niet eenvoudig voor een gemiddeld team om er toegang toe te krijgen zonder hun routines te veranderen.

Hebben we iets gemist?

Leave a Reply

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.