Fem bästa KPI:er för programvaruteknik och hur de blir lurade

av Bill Harding,Programmerare/CEO
Publicerad den 31 mars 2020.Senast uppdaterad den 17 april 2020.

När folk talar om tekniska KPI:er finns det två motstridiga truismer som man ofta hör:

Det som mäts förbättras.-Peter Drucker

Och

När ett mått blir ett mål upphör det att vara ett bra mått.

.Goodharts lag

Båda dessa påståenden beskriver delvis tekniska KPI:er, men tillsammans innebär de att det är möjligt att använda mätning för att förbättra. Hur kan en datadriven chef överbrygga denna klyfta?

Den dåliga nyheten är att det krävs ett visst engagemang för att lära sig, särskilt för dem som kommer från avlägsna (dvs. icke-tekniska) roller.Den goda nyheten är att noggrant utvalda mätvärden kan fortsätta att fungera trots att man ”blir ett mål”. För många av de mätvärden som vi kommer att rekommendera är det faktiskt så att ju mer en anställd ”spelar med systemet”, desto mer tjänar företaget sina långsiktiga intressen. Slutmålet är mätvärden som fortsätter att fungera trots att de ”manipuleras”. Det finns fem mått som uppfyller detta krav.

Målgrupp: Alla chefer som har försökt att få fler färdiga ärenden från sitt ingenjörsteam vet hur det är att kämpa.De vill vidta rättvisa, datastödda åtgärder som förbättrar deras hastighet. De vet att det är dyrt och oskalbart att fatta beslut baserade på magkänsla. Men när de tittar på sin lista med uppgifter är den full av uppgifter som verkar mer brådskande än ”förbättra mätningen”. I praktiken sker det ofta efter ett katastrofalt misslyckande, t.ex. en felfri version eller att en utvecklare inte har stängt några ärenden på en månad.

Även när det står klart att mätning måste ske är det oklart var man ska börja. Du kan googla ”engineering KPI:er”, klicka dig igenom hela den första sidan med resultat och förbli oklar om vilka nästa steg du ska ta. Ta det ofta omtalade måttet ”Team Velocity” som ett exempel. Nästan alla Google-resultat rekommenderar att man mäter ”Team Velocity”, men ingen vill säga om det mäts i… stängda biljetter? Linjer av kod? Story Points? Oavsett vad det är har cheferna inte tid att ta reda på det. De måste ta sig från detta 15 000 fot höga berg av teori ner till något som de kan förstå, lita på och dra nytta av… helst omedelbart.

Den organiserande förutsättningen för den här artikeln är att du är en chef som vill förstå mjukvaruteknikmetri precis tillräckligt bra för att göra ditt team mer effektivt. Att vara chef innebär att du är för upptagen för att lära dig om teori, utom när det är direkt kopplat till hur du kan dra nytta av teorin.

Metri måste vara praktisk för riktiga företag att pröva

För att skriva den här artikeln har vi tagit del av de mätvärden som föreslagits av de 20 bästa Google-resultaten inom området mjukvarumetri. Som du kanske kan föreställa dig hade varje källa sina egna teorier om vilka mätvärden som var viktigast.Deras artiklar delade ofta in mätvärden i grupper som ”processmätvärden” och ”projektmätvärden”. Vi kommer att följa deras tips om gruppering av mätetal, men våra grupper kommer att vara ”kvalitetsmätetal” och ”allt annat”.

Här är vad som räknas som ett kvalitetsmått:

  • Affärsvärde.Är det möjligt att dra en rak linje från mätetal => skapat affärsnytta?
  • Mätbart.Kan vi definiera ett specifikt antal och dess måttenheter (t.ex, poäng, procent), så att det kan spåras över tiden och korreleras med händelser och experiment?
  • Handlingsbar.Kan det regelbundet informera om åtgärder som leder till positiva resultat? Företrädesvis med minimalt antal falska positiva resultat?
  • Tillgänglig/bekväm.Kan ett genomsnittligt programvaruteam få tillgång till detta mått utan att ändra sina befintliga utvecklingsprocesser?
  • Populär.Har det tillräckligt många anhängare för att vara väldokumenterat och trovärdigt?
  • För att inkluderas i ”Quality Metrics”-hinken krävs alla fem ovan, plus ett tillfredsställande svar på vår fråga: Om vi litar på detta mått och utvecklarna därefter optimerar för det, vad händer då?Under de år som vi har arbetat med att bygga och iterera vårt eget utvecklingsmått (”Line Impact”) har vi lärt oss att giftiga biprodukter är en förväntad konsekvens av mätning, såvida inte måttet är exakt anpassat till det långsiktiga affärsvärdet.Som ett exempel kommer vi senare att visa hur utvecklare som försöker manipulera ”Lead Time”-måttet orsakar minskad transparens för ledningen.

    KPI:er för kvalitetsteknik

    Här är fem mjukvarumått som hjälper cheferna att driva ett mer effektivt team.

    🏦 OKR-driven

    Exempel på OKR-mall

    En av många exempel på OKR-mallar som finns tillgängliga via Weekdone på Okrexamples.com

    Alla listor som fokuserar på att maximera affärsnyttan borde börja här. Ledande företag som Google använder OKR som en primär axel för att utvärdera seniora ingenjörer. Nackdelen med OKR-drivna mätvärden är att de per definition är specifika för affärsmässiga detaljer. Detta gör det omöjligt att generalisera en formel för att fånga dem, eller att generalisera den väg genom vilken de kommer att bli manipulerade.

    Hur man manipulerar dem?Risken för att OKR:s manipuleras är låg eftersom de vanligtvis är affärscentrerade. Den största faran medOKR-drivna mätvärden är att eftersom de vanligen formuleras på engångsbasis (eller periodiskt) är de kanske mindre tillförlitliga än mätvärden som har granskats under flera år. Det finns alltid möjliga fall som lurar.Om man till exempel fastställer en OKR som innebär att ”införa mindre än 10 buggar per månad” kan man lura den genom att inte lansera några nya funktioner. Om båda parter agerar i god tro bör OKR-spel i praktiken vara sällsynta.

    Hur får man det?Via befintliga mätinstrumentpaneler eller genom att samarbeta med företag somWeekdonsom hjälper till att ge OKR-inspiration.

    📐Line Impact

    Exempel på teknisk KPI Line Impact: tillförlitlig mätning av källkod

    10 repos grafiskt indelade efter deras Line Impact, en mätning som kvantifierar takten med vilken källkoden utvecklas,image courtesy GitClear

    Line Impact är en mätning som är utformad för att mäta hur mycket kognitiv energi som läggs på mjukvaruutveckling.Den här videon ger en illustrerad förklaring till hur det är möjligt. Den korta förklaringen är att Line Impact tar bort all interstitiell aktivitet (”churn”) som sker när en funktion utvecklas och lämnar en koncentrerad förkroppsligande av det arbete som ägt rum. Line Impact bevaras mellan olika språk, så det tar samma tid att generera Line Impact oavsett om utvecklaren skriver Java, Python, Javascript eller något annat större programmeringsspråk (30+ stöds).

    I fråga om affärsnytta är Line Impact en parallell till Story Points: det illustrerar hur kostnaden för en uppgift fluktuerar beroende på vilken utvecklare som tilldelas den. Utifrån detta kan en engagerad chef använda Domain Experts-rapporten för att matcha Jiras med ämnesexperter, vilket dramatiskt kan öka produkthastigheten.

    Hur man använder den?Alla mätvärden som hävdar ”Lines of Code” (LoC) som datakälla (som Line Impact gör) förtjänar att närmas med försiktighet. Om det implementeras slarvigt förstoras subtila brister i bearbetningen upp till ett brus som tränger ut signalen.Det är därför GitClear byggde de bästa kodgranskningsverktygen på marknaden: så att chefer och utvecklare kan granska hur Line Impact delas ut per fil och per åtagande.Öppenhet är ett kraftfullt motgift för att bekämpa spelande.

    Ett ytterligare skydd kommer i form av meddelanden som utlöses när en utvecklare bidrar med arbete med en ovanlig hastighet. Dessa och andra åtgärder har gjort det tillräckligt svårt att manipulera Line Impact att GitClear ännu inte har fått någon kund som rapporterar att Line Impact har manipulerats av deras team.Med detta sagt skulle det vara oseriöst att hävda att måttet på något sätt är ogenomträngligt för spel, så här finns en lista över kända vägar för att ackumulera snabb Line Impact.Kärnan är att om en utvecklare skriver tester, raderar gammal kod och lägger till dokumentation, kommer de att tjäna en outsized andel av Line Impact.

    Hur får man det?Registrera dig för en kostnadsfri 15-dagars testperiod. Om du gillar det börjar priserna på 9 dollar per aktiv utvecklare.Se en kort förklaringsvideo om Line Impact här.On prem version tillgänglig.

    🎲 Story Points

    engineering KPI:er: Jira burndown-rapport

    Story Point-baserad ”release burndown”-rapport, tillgänglig via Jira

    Story Points kan göra anspråk på att vara den mest ”klassiska” av de tekniska KPI:erna. Det finns många olika sätt att beräkna Story Points. Alla former av beräkning är en uppskattning av den förväntade utvecklingstiden för att slutföra en uppgift. Chefer kan använda Story Points för att beräkna kostnaderna för en uppgift, t.ex. om en utvecklare tjänar 10 000 dollar/månad, om biljetten uppskattas till 10 Story Points = en halv månad, är kostnaden 10 000 dollar * 0,5 = 5 000 dollar.Med hjälp av någon version av denna beräkning kan man prioritera uppgifter baserat på vilka som ger det högsta förhållandet mellan beräknat värde och beräknad genomförandekostnad.

    Hur man använder det?Den största uppmärksamheten här gäller hur Story Points beräknas. Det enklaste sättet att ”manipulera” Story Points är för utvecklarteamet att förvränga betygsskalan, vanligtvis i riktning mot en överskattning av svårighetsgraden. Ett alternativ för att lösa detta är att låta uppgifter väljas ut på en ”uppgiftsmarknadsplats”, där övervärderade uppgifter kan fördelas jämnt mellan utvecklarna för att upprätthålla den relativa kalibreringen. Ett annat sätt är att regelbundet omkalibrera den konstant som används för att omvandla Story Points till ”utvecklardagar”. Observera att eftersom genomförandet av Story Points ofta skiljer sig åt mellan olika team är det inte tillrådligt att använda dem för att jämföra prestanda mellan olika team.

    Hur man får tag på det?De flesta problemspårare på denna sida av GitHub gör det möjligt att ange Story Points. När det gäller att visa dem tillhandahåller Jira en ”next-gen velocity report” som är avsedd att visa Story Points som slutförts över tiden.De erbjuder också en ”release burndown report” som använder Story Points för att uppskatta hur teamet följer sina mål för sprinten. GitClear erbjuder också rudimentära (för tillfället) grafer som illustrerar Story Points som avslutats över tiden.

    🐞 Bug Rate / Escaped Defects

    Detta mått definieras på olika sätt av olika källor, men alla kommer fram till samma viktiga fråga: hur många buggar kommer ut i världen, och hur väl reagerar vi på dem?Stackify relaterar det i specifika numeriska termer:

    Din felutryckningsfrekvens uttrycks som en procentandel baserad på hur många fel du hittar innan de hamnar i produktion eller hur många som når fram till produktionen, beroende på vad du föredrar. Varje mjukvaruprojekt och team kommer att vara olika, men vi föreslår att man strävar efter att hitta 90 % av alla defekter innan de når produktion.

    Stackify’s definition utgår från att man kommer att utse ett fält i sin problemspårning för att fånga upp i vilken utvecklingsfas felet inträffade. För team som inte har tid att sätta upp och spåra utvecklingsfaser kan en alternativ definition vara:

    Hur ofta blir kod som skrivs i en ny funktion kod som ändras i samband med att man löser ett fel?

    Ett datalänkat svar på denna fråga tillhandahålls GitClear-användare, men är svårt att beräkna manuellt (om du inte är GitClear-användare).En garanterat tillgänglig reservmätning av felprocenten kan vara: ”Vad är förhållandet mellan skapade fel och lösta fel”?

    Hur man kan manipulera den?Detta mått är svårt att manipulera. En utvecklare kan ta sig an fler små ärenden, men varje ärende medför en ökad risk för fel om han eller hon inte är försiktig. Risken med att använda Bug Rate är att det behövs en motvikt för ”framsteg” som Story Points eller Line Impact, annars skulle en utvecklare kunna dröja kvar på ett enda problem under hela sprinten och säkerställa en 0 % felprocent.

    Hur får man fram det?Om ditt team har bandbredd för att märka problem efter utvecklingsfasen då de inträffade, så kanEscaped Defects beräknas manuellt med hjälp av vilken issue tracker som helst. GitClear är ett annat tillgängligt alternativ för att beräkna andelen funktioner som blir fel.

    ✅ Pull Request Completion Rate

    Exempel på ingenjörs-KPI Pull Requests: statistik på GitClear

    Ett urval av statistiken över pull requests som tillhandahålls av GitClear

    Hur stor andel av pull requests stängdes inom en vecka efter att de öppnats? Detta ger upphov till flera mer detaljerade frågor, som ”är teamet engagerat i att svara snabbt på nya pull requests”, ”kan de samarbeta” och ”har utvecklarna putsat sin kod innan de skickar in den för sammanslagning?”

    Hur man spelar det?Att klara testet ”Pull request completion rate” innebär att man alltid stänger PR:s inom en vecka. Detta är relativt svårt att spela, men det måste balanseras av en drivande kraft som Story Points eller Line Impact, annars kommer alla lagets incitament att vara att polera arbetet i stället för att skicka det (eller lämna in det för PR-granskning).

    Hur får man det?Alla ”märkesleverantörer” av Engineering Insight (GitClear, Pluralsight, Code Climate, Pinpoint) erbjuder statistik som illustrerar effektiviteten i ett teams pull request-process.Vi hjälper till att jämföra leverantörerna här.

    Honorabla omnämnanden

    Under de bästa mätvärdena hittar vi ett interstitiellt skikt. Det här är mätvärden som har önskvärda egenskaper och viktiga brister. De kan fortfarande leverera värde, så länge en chef vet tillräckligt för att ta hänsyn till deras begränsningar.

    Lead Time/Cycle Time

    Lead Time-grafen visualiserad via Azure Devops

    Men den är listad (två gånger!) iPluralsights lista över Top 5 Metrics, är Cycle Time en bra idé som är mycket känslig för spel.

    ”Lead Time” definieras oftast som ”Vad är intervallet mellan när en uppgift registreras i issue tracker och när den levereras till kunden?”. Dess kusin, ”Cycle Time”, är en delmängd av Lead Time och definieras som ”tiden mellan när produktteamet plockade upp den ur kön och när den nådde produktionen”.

    Hur man spelar den?Lead Time-prestanda beror till viss del på den mekanism genom vilken Jiras registreras, vilket innebär att dess tillämpbarhet i olika team är låg. Cykeltiden beror på de konventioner genom vilka committern väljer att göra sin första commit. Det här måttet är alltså enkelt att manipulera om en utvecklare sparar sina commits lokalt och släpper dem i en enda arbetsinsats omedelbart innan han eller hon skickar in PR. Detta misslyckande är det som förvisar Cycle Time till avsnittet ”hedersomnämnanden”. Inte heller idealiskt: genom att en utvecklare uppmuntras att spara sina commits utan att skjuta på dem är det omöjligt för lagkamraterna att ingripa medan arbetet pågår.Denna sidoeffekt minskar insynen mellan en chef och deras utvecklare.

    Hur får man tag på det?Azure Devops Services tillhandahåller grafen som beskrivs ovan.Jira erbjuder också en version av den.Alla de större erbjudandena för Engineering Insight (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementerar någon form av beräkning av ledtid.

    Testtäckning

    Att försöka fånga in något mått på testtäckning är ett rimligt mål att överväga att eftersträva. Det är dock inte helt tillräckligt för att vara en toppnivåmätare av två skäl:

  1. Det är en ofullständig lösning. En adekvat testning måste inkludera funktions- och integrationstester tillsammans med enhetstester, och ingen automatiserad lösning kan veta vilka sidor som måste besökas inom appen eller webbplatsen, detta kräver fortfarande mänsklig styrning
  2. Det är mycket svårt att koppla tillbaka till affärsmått på högsta nivå. Testtäckning är värt att utvärdera som en del av en ledande utvecklares plan för att övervaka kodkvaliteten, men den är inte tillräckligt direkt kopplad till affärsvärdet för att kunna göra en egen bedömning. Ett relaterat men mer affärsmässigt mått för att spåra kodfel är ”Bug Rate / Escaped Defects.”

”Everything Else” Metrics

Listan ovan är relativt kort jämfört med den mängd tidigare mått som föreslagits av andra författare.För fullständighetens skull ska vi gå igenom några av de mest omnämnda mätvärdena på andra ställen och varför de inte kom med i listan.

Team Velocity

Detta var ett av de mest populära mätvärdena som citerades i andra artiklar. Den rekommenderas av TechBeacon, InfoPulse och SeaLights.io.Författarna verkar dock vara försiktiga med att definiera enheterna för detta viktiga mått.TechBeacon definierar det som ”hur många ”enheter” av programvara som teamet vanligtvis färdigställer under en iteration”. Inte så lätt att ta på. InfoPulse försöker inte specificera enheter. SeaLights säger att enheterna är ”Story Points”. Vi drar därför slutsatsen att begreppet ”velocity” på ett adekvat sätt fångas upp av Story Points, eller Line Impact som en proxy.

Code Churn

Vd:n för GitPrime (som nu förvärvats av Pluralsight) var en av dem som förespråkade att man skulle ta hänsyn till Code Churn.Vi hävdar i vårt svar att konsekvenserna av Code Churn är överallt på kartan, vilket gör det mycket svårt att agera på hög churn. Metriker måste vara användbara.

Release/Sprint Burndown

SeaLights och InfoPulse rekommenderar att man uppmärksammar hur ett team utvecklas mot sina sprintmål.Vi håller med om att detta är viktigt, men det täcks redan av avsnittet ”Story Points” ovan.

Mean time to repair / Mean time between failures

Av den handfull artiklar som förespråkar dessa mätvärden är det ingen som vågar beskriva vilka enheter som mätvärdena är baserade på eller vilken tjänst som kan användas för att samla in dessa datapunkter.Forskning visar att Atlassian erbjuder en hjälpartikel i ämnet.Om den här artikeln inte redan var 2500 ord lång skulle MTTR kunna hamna i avsnittet ”hedersomnämnanden”. Men det är inte lätt att koppla tillbaka till affärsnytta, och det är inte enkelt för ett genomsnittligt team att få tillgång till utan att ändra sina rutiner.

Missade vi något?

Lämna ett svar

Lämna ett svar

Din e-postadress kommer inte publiceras.