När man sätter upp mål måste man självklart också följa upp hur de uppnås. Detta är en av alla projektledares viktigaste uppgifter, och mjukvaruutvecklingschefer är inget undantag.
Projektledare använder specifika KPI:er för att hantera mjukvaruutvecklingsprojekt på ett effektivt sätt. Utvecklingshastighet, cykeltid och ledtid är alla exempel på KPI:er som kan användas för att spåra mjukvaruprojekt.
Dessa KPI:er för mjukvaruutveckling är ditt verktygslåda med objektiva data för att spåra varje steg i mjukvaruutvecklingscykeln, identifiera flaskhalsar och arbeta mot kontinuerlig förbättring.
Låt oss se hur mjukvaruutvecklingsteam kan optimera utvecklingsprocessen med hjälp av de 25 viktigaste KPI:erna (nyckeltal) för mjukvaruutveckling för att driva beslutsfattandet.
25 KPI-mått för mjukvaruutveckling
Det finns otaliga KPI:er som är skräddarsydda för specifika affärsmål och pågående projekt. Här är de 25 bästa som gäller över hela linjen för att hålla ditt utvecklarteam före målen.
1. Utvecklingshastighet
Mät mjukvaruutvecklingsteamets prestanda med utvecklingshastighet. Den anger det totala arbete som ditt team kan utföra under en sprint (en fast period under vilken uppgifterna ska slutföras).
Inom en sprint använder du story points för att beräkna den insats som krävs för att slutföra en uppgift på en skala från ett till tio, där ett är snabbast och tio är mest komplicerat. Genom att mäta varje sprint och story point kan du förstå ditt utvecklingsteams genomsnittliga hastighet inom tre sprints.
Utan denna mätparameter blir det svårt att planera, prioritera, fördela resurser och sätta realistiska förväntningar för framtida projekt.
Utvecklingshastighet = Totalt antal story points som slutförts i en sprint
2. Cykeltid
Cykeltid är ett mått från DevOps Research and Assessment (DORA) som mäter den tid som åtgår för att utföra en viss uppgift. Det kvantifierar teamets prestanda och uppskattar den tid som krävs för att slutföra framtida uppgifter.
I mjukvaruutveckling kan cykeltid till exempel avse den tid det tar att lösa ett fel, från det att det tilldelas en utvecklare och genomgår kodstabilitets- och kodtestning till dess att det är åtgärdat och godkänt av kvalitetssäkringen.
Denna mätvärde hjälper till att bedöma utvecklarteamets produktivitet och identifierar områden som kan förbättras. Du kan jämföra cykeltiden för varje uppgift med önskad varaktighet för att analysera var teamet brister.
Cykel tid = Sluttid – Starttid
3. Kodtäckning
Kodtäckning, även kallat testtäckning, mäter andelen testad kod. Denna DevOps-mätvärde mäter mjukvarukvaliteten för produktions- och teständamål.
Det prioriterar testdriven utveckling (TDD) och identifierar buggar i koder. Ju högre kodtäckning, desto mindre är risken för buggar.
Kodtäckning = (antal rader kod som exekverats av tester / totalt antal rader kod) X100
4. Distributionsfrekvens
Att implementera agila metoder kan göra det svårare att mäta företagets prestanda, eftersom hela teamet måste spåra agila mätvärden under hela utvecklingscykeln. När du spårar prestandan för mjukvaruutvecklingsverktyg och -processer under en sådan process kan du förlita dig på KPI:n för distributionsfrekvens.
Det avgör hur snabbt implementeringsteamet implementerar kod i olika avdelningar, såsom staging, testning och produktion. Denna KPI är en av de fyra DORA-mätvärdena och är kopplad till andra, såsom förändringsfelprocent, ledtid för förändringar och genomsnittlig återställningstid.
Denna mjukvaru-KPI ger insikt i utvecklingsteamets effektivitet och flexibilitet, sätter riktmärken för att förbättra implementeringsrutinerna och bidrar till kontinuerlig förbättring.
Distributionsfrekvens = Totalt antal distributioner / Tidsperiod
5. Net Promoter Score
Net Promoter Score (NPS) mäter kundnöjdhet på en skala från noll till tio, där noll beskriver den sämsta användarupplevelsen och tio den bästa.
Personer som betygsätter programvaran mellan noll och sex kallas kritiker, sju och åtta är passiva och de som betygsätter den med nio eller tio är förespråkare. Om antalet förespråkare överstiger antalet kritiker, fungerar programvaran bra.
Net Promoter Score = (% promotorer) – (% kritiker)
6. Genomsnittlig tid mellan fel (MTBF)
När man försöker mäta programvarans tillförlitlighet kvantifierar MTBF-måttet den genomsnittliga tiden mellan två programvarufel.
Inom mjukvaruutveckling, där fel är oundvikliga, är MTBF-måttet avgörande för att utvärdera mjukvaruuppgifter och utveckla reparationsstrategier.
Medeltid mellan fel (MTBF) = Total drifttid/Totalt antal haverier
7. Andel misslyckade förändringar
Att mäta mjukvarukvalitet är komplext på grund av dess subjektivitet. Mätvärdet Change Failure Rate ger en inblick i mjukvarukvaliteten genom att beräkna andelen distributioner som leder till ett fel i produktionen.
En låg felprocent vid förändringar indikerar färre buggar och hög kvalitet. Tvärtom innebär en hög felprocent fler buggar och ett behov för teamet att omarbeta koden.
CFR = (Antal misslyckade ändringar/Antal ändringar)/100
8. Storlek på pull-förfrågan (PR)
Pull request size är ett mätvärde inom mjukvaruutveckling som mäter antalet kodändringar i en enskild pull request och återspeglar storleken eller omfattningen av de ändringar som en utvecklare inför.
Små pull-förfrågningar är lättare att granska och bearbeta, vilket underlättar snabbare integration, ger mer specifik feedback och minskar risken för buggar. Stora pull-förfrågningar tar däremot längre tid att förstå, granska och åtgärda.
9. Felupptäcktsgrad (DDR)
DDR-kvoten mäter antalet fel som upptäckts före lanseringen jämfört med antalet fel som upptäckts efter lanseringen.
Använd DDR-måttet för att bedöma antalet fel som ditt testteam missat och som kunderna stöter på, vilket påverkar deras upplevelse negativt.
Felupptäcktsgrad = (fel som upptäckts i en fas + totala fel) X 100
10. Kodomsättning
Kod behöver ofta revideras i samband med programuppgraderingar och införandet av nya funktioner. Kodomsättningsmåttet mäter antalet gånger en programkod behöver itereras under en viss period. En högre kodomsättning indikerar högre underhållskostnader och risk.
DevOp-team arbetar till exempel vanligtvis med en genomsnittlig kodomsättningsgrad på 25 %, vilket indikerar att koderna är 75 % effektiva.
Kodomsättningshastighet = Totalt antal kodrader i början – (Tillagda rader + rader som tagits bort + rader som modifierats)/ Totalt antal kodrader X 100
11. Kodens enkelhet
En enkel kod som körs utan problem är bättre än en komplex kod som kräver ständiga iterationer. Kodens enkelhet kan mätas med hjälp av flera mått, såsom cyklomatisk komplexitet, kodduplicering, kodomsättning etc.
Enkel kod indikerar att koden tar mindre tid, kräver färre iterationer och har färre buggar.
Det finns ingen direkt formel för att mäta kodens enkelhet, såsom cyklomatisk komplexitet, eftersom det är en kvalitativ snarare än kvantitativ mätvärde.
12. Kumulativt flöde
Programvaruutvecklingschefer vill ofta veta i vilket skede programvaruutvecklingsprojekten befinner sig. Det kumulativa flödet visar med hjälp av visuella diagram om en uppgift är godkänd, pågående eller i backlog-stadiet.
Olika färger visar olika statusar. Dessutom visar bandets bredd cykeltiden. Med denna KPI för mjukvaruutveckling kan du mäta statusen för mjukvaruutvecklingen, identifiera flaskhalsar och beräkna den insats som krävs för att slutföra backlog-poster.
Läs också: Hur ser en mjukvaruutvecklares dag ut?
13. Felprocent
Bugfrekvensen anger antalet buggar som identifierats under mjukvarutestningen. De flesta mjukvaruutvecklingsteam använder denna mätvärde för att jämföra bugfrekvenser mellan projekt, team och tidsramar, fastställa riktmärken och sätta upp realistiska mål för att minska antalet buggar.
Du kan betrakta dem ur två perspektiv: det totala antalet upptäckta buggar och allvarlighetsgraden hos de identifierade buggarna.
Bug Rate = (Antal upptäckta buggar/Totalt antal kodrader) X 100
14. Sprint Burndown
Mät det totala antalet uppgifter som utförts inom en sprint med sprint burndown-måttet. Det är en av de viktigaste KPI:erna inom mjukvaruutveckling som avgör hur mycket arbete som utförts under sprints. Justera teamets prestanda om resultaten inte motsvarar förväntningarna.
Företag använder ofta sprintburndown-diagram och mäter tiden och mängden arbete som ska utföras i story points för att kontrollera avvikelser från den ideala utvecklingen.
15. Release Burndown
KPI-måttet release burndown mäter framstegen för produktlanseringen och förutsäger hur många sprintar som krävs för att slutföra en version baserat på tidigare sprintar.
Använd ett release burndown-diagram för att mäta om verksamheten går enligt plan eller ligger efter schemat och visa projektets framsteg för intressenterna.
16. Flödeseffektivitet
Nyckeltalet för flödeseffektivitet mäter förhållandet mellan total tid och aktiv tid för att ge en inblick i stilleståndstiden och optimera arbetsflödet.
Flödeseffektivitet = (värdeskapande tid / ledtid) X 100
Värdeskapande tid = Tid som läggs på aktiviteter som direkt bidrar till kundens behov, såsom källkod/testning.
Total ledtid = Tiden från det att ett arbetsmoment kommer in i Kanban-systemet till dess att det levereras till kunden.
17. Genomsnittlig reparationstid (MTTR)
Medelreparationstiden avser den totala tid det tar för ett system att reparera ett problem eller fel. Den inkluderar reparationstiden och testtiden för att införliva all tid som krävs tills programvaran är fullt funktionell.
En hög MTTR i mjukvaruutvecklingsprojekt kan leda till oplanerade driftstopp.
MTTR utvärderar tillförlitligheten och tillgängligheten hos dina system och din utrustning och identifierar förbättringsområden och trender i fel så att dina mjukvaruutvecklare kan optimera underhållsstrategierna.
MTTR = Total underhållstid / Antal reparationer
18. Kötid
Kö-tid är den tid det tar från det att ett ärende registreras till dess att det är löst. Det avser den period då ärendet fortfarande ligger i kön och är obehandlat eller olöst.
Långa kötider kan orsakas av brist på QA-specialister, dålig intern kommunikation eller otillräckliga verktyg och support. Denna KPI visar hur optimerad pipelinen är; ju lägre den är, desto bättre.
19. Andel slutförda projekt
Ju snabbare ärendet slutförs, desto mer positivt påverkar det mjukvaruutvecklingsteamets effektivitet. Omfattningens slutförandegrad är ett mått som avgör det totala antalet ärenden som slutförts inom en sprint.
En låg andel slutförda projekt tyder på icke-optimerade processer, orealistiska mål eller för få medarbetare.
20. Tillagd omfattning
Scope added är en viktig mätparameter för alla mjukvaruutvecklingschefer, eftersom den står för det totala antalet story points som lagts till efter sprintens start.
En hög procentandel för tillagd omfattning indikerar bristande planering för att fastställa kommande utmaningar. Det stör sprintplaneringen genom att minska möjligheten att utföra nytt arbete.
För att minska omfattningen, ta bort funktioner som kräver mer tid än ditt team kan avsätta. Du kan också skapa en underhållsprognos som anger den tid och ansträngning som krävs för att hålla funktionen igång på lång sikt.
21. Ledtid
Ledtid mäter den totala tiden för en uppgift från begäran till slutförande. Till skillnad från cykeltiden för mjukvaruutvecklingsteam tar den även hänsyn till väntetid, godkännanden och granskningar som krävs innan uppgiften slutförs.
En kortare ledtid innebär snabbare time-to-market, ökad flexibilitet och effektivare resursanvändning. Tillsammans bidrar dessa faktorer till högre kundnöjdhet.
Ledtid = tidpunkt för distribution – tidpunkt för bekräftelse
22. Slöseri med resurser
Mätvärdet för bortkastad arbetsinsats mäter den tid och de resurser som läggs på uppgifter som inte bidrar till det slutliga projektet eller affärsmålen.
Om teamet till exempel arbetade med en programvarufunktion som efter två veckor ansågs irrelevant, skulle den bortkastade insatsen vara det belopp som betalats till alla utvecklare för deras arbete under dessa två veckor.
För att öka produktiviteten och minska tiden till marknaden, mät KPI:er för mjukvaruutveckling, såsom bortkastad arbetsinsats, och hitta sätt att minska den för att projektet ska lyckas.
Bortkastad arbetsinsats = (Total bortkastad arbetsinsats / Total arbetsinsats) X 100
23. Avbrott
Avbrottsmätvärdena mäter det totala antalet avbrutna uppgifter inom en given period. Du kan också mäta det totala antalet avbrott inom en uppgift för att få en tydligare bild.
Avbrott påverkar direkt prestandan och måste mätas för att hålla sig inom realistiska tidsramar. Några exempel på avbrott är tekniska problem, systemfel, personliga avbrott eller avbrott på grund av bristande resurser.
Avbrottsfrekvens = (Totalt antal avbrott / Total arbetstid) X 100
24. Anställning och ramp-up-tid
Du behöver tillräckliga resurser för att genomföra din mjukvaruutvecklingscykel. Att anställa ett team av skickliga utvecklare tar ibland tid, vilket understryker behovet av att sätta realistiska förväntningar på uppgiftsutförandet.
Anställningstiden definierar perioden från det att kandidaten söker ett jobb till dess att hen accepterar det. Med detta ska du ta hänsyn till ramp-tiden, som avser tiden mellan det att kandidaten anställs för en roll och det att hen blir fullt produktiv i den.
Beakta båda dessa indikatorer när du uppskattar livscykeln för mjukvaruutvecklingen.
25. Förväntat leveransdatum
Intressenter kräver ofta ett beräknat leveransdatum för när programvaran ska vara färdig, och denna KPI hjälper tvärfunktionella avdelningar att planera sitt arbete.
Leveransdatumet kan ändras under arbetets gång och kan justeras när förändringar inträffar.
Läs också: Vad är skillnaden mellan OKR och KPI?
Utmaningar vid implementering av KPI:er för mjukvaruutveckling och tips för att övervinna dem
Välja rätt KPI:er
När du fastställer KPI:er för mjukvaruutveckling kan det vara svårt att avgöra vilka som är mest relevanta för ditt projekt. Hur väljer du de viktigaste nyckeltalen bland alla alternativ?
Vi rekommenderar att du börjar med de organisatoriska målen och KPI:er som stöder de strategiska initiativen. Exempel på viktiga områden där mjukvaruutveckling kan ha stor inverkan är förbättring av produktkvaliteten, ökad kundnöjdhet och kortare time-to-market.
Motsvarande KPI:er som tillför affärsvärde inkluderar kodtäckning, cykeltid, kodkvalitet, MTTR för att förbättra produktkvaliteten, NPS för kundnöjdhet och distributionsfrekvens för marknadsintroduktion.
Samla in synpunkter från ingenjörer, testare, utvecklare, projektledare och produktutvecklare för att göra detta till ett samarbete och öka sannolikheten för en framgångsrik implementering.
Justera och följ upp KPI:er regelbundet
KPI:er är inte statiska, utan måste regelbundet anpassas efter förändrade krav och affärsmål. Du kan spåra dem i kalkylblad, men detta har begränsad skalbarhet på grund av versionskontroll, brist på automatiserade dataändringar och rollbaserad åtkomst.
Du behöver programvara eller en mall för att spåra och justera dina KPI:er för mjukvaruutveckling för att projektet ska kunna slutföras framgångsrikt.
Bristande samordning inom teamen
Anta ett scenario där utvecklingsteamet mäter och prioriterar NPS-poängen men glömmer att kommunicera den till kundsupportteamet. Utan denna samordning kan supportteamet prioritera hastighet framför kundupplevelsen, vilket undergräver affärsmålet.
Förutom att mäta relevanta KPI-mått måste du kommunicera dem till berörda teammedlemmar så att de förstår deras betydelse och hur de stämmer överens med företagets mål.
Hur säkerställer du att alla är överens om KPI:erna och har möjlighet att bidra till att uppnå dem utan att använda en gemensam instrumentpanel eller programvara?
Kvalitet och noggrannhet i data
Spreadsheet-baserad dataspårning har flera brister, inklusive dubbla poster, manuella datainmatningsfel och föråldrad information, vilket kan leda till felaktiga beslut.
Datasilos skapas i många företag där varje avdelning arbetar isolerat med sina egna data och metoder.
Till exempel kan cybersäkerhetsteamet inom organisationen arbeta med olika datakällor. Utvecklingsteamet kan däremot ha separata metoder, även om dessa team har ett gemensamt mål – att minska sårbarheter i programvaran som är utsatta för cyberattacker.
Resultatet är en fragmenterad miljö utan en enda källa till sanning. Organisationer får inte underskatta vikten av datahygien och aktualitet för ett sunt beslutsfattande, särskilt när tvärfunktionella team samarbetar mot ett gemensamt mål. Det är viktigt att ha en enda källa till sanning, där alla team har tillgång till samma centraliserade data.
Spåra och implementera KPI:er för mjukvaruutveckling med ClickUp Dashboards
När du väl känner till de viktigaste KPI:erna för mjukvaruutveckling är nästa fråga hur du ska spåra och implementera dem.
Att spåra KPI:er för programvara är tidskrävande och felaktigt utan effektiva verktyg som tillhandahåller tydliga datapunkter på ett klart och användbart sätt.
ClickUp är en omfattande plattform för att spåra alla dina nyckeltal relaterade till ditt mjukvaruprojekt och säkerställa att de är i linje med dina affärs- och strategiska mål.
Du kan anpassa ClickUp-instrumentpanelerna för att spåra de mest relevanta KPI:erna med realtidsdata och främja effektivt och snabbt beslutsfattande. Instrumentpanelen kan anpassas med sprintrapporteringskort som hastighetskort, burndown-kort, burnup-kort, kumulativt flöde, cykeltid och ledtid.
Alla dessa kort uppdateras regelbundet (förutom hastighet) för att förenkla KPI-spårning och mäta utvecklingsinsatser. Dessa kort har olika anpassningsalternativ, inklusive källa, tidsintervall, provperiod, arbetsmängd, uppgiftsfilter etc.
ClickUp Dashboards integrerar värdefull data från olika källor för att ge en helhetsbild av mjukvaruutvecklingsprojektets mätvärden och prestanda. Denna data kan användas för att fatta datadrivna beslut om mjukvaruutvecklingsprocessen, optimera resursfördelningen och den övergripande utvecklingsprocessen.
ClickUp KPI-mallar
Framgång handlar om att ligga steget före KPI:erna, och som chef måste du mäta vad som fungerar och vad som inte fungerar för ditt mjukvaruutvecklingsteam.
ClickUps mallar för mjukvaruutveckling är utformade för högkvalitativ mjukvaruutveckling. De levereras med färdiga, helt anpassningsbara underkategorier och hjälper dig att spåra KPI:er för projektledning med anpassade vyer, statusar och fält.
ClickUp KPI-mall gör det enkelt att mäta KPI, oavsett om du är ett nystartat företag eller ett etablerat företag. Med den här mallen kan du:
- Håll dig uppdaterad om dina viktigaste datapunkter – allt på ett ställe för alla dina mjukvaruutvecklare.
- Få insyn i ditt utvecklingsteams arbete genom att följa upp framstegen mot målen.
- Identifiera trender och följ och mät utvecklingen av dina nyckeltal (KPI) med ett visuellt diagram.
Så här förenklar ClickUp för mjukvaruutvecklingsteam mätningen av KPI:er:
- Skapa mål: Utforma mätbara och uppnåbara mål som stämmer överens med dina långsiktiga och kortsiktiga mål.
- ClickUp Dashboard: Identifiera de mätvärden som bäst passar dina behov och använd instrumentpanelen för att spåra dem.
- Skapa milstolpar: Spåra mätvärdena själv eller använd automatiserade analysverktyg för att spåra prestanda i realtid.
- Analysera resultaten: Använd ClickUps Gantt-diagramvy eller tavelvy för att analysera resultaten och ändra målen efter behov.
Relaterat: KPI:er för produktledning 🎯
Kvalitetssäkringens inverkan på KPI:er för mjukvaruutveckling
Kvalitetssäkring måste vara centralt för att mäta mjukvaruutvecklingsmått, från att identifiera säkerhetsbrister till att testa mjukvaran för att identifiera buggar.
En strukturerad och pålitlig testprocess säkerställer att utvecklingsteamet åtgärdar alla buggar och problem innan kunden använder din produkt/programvara.
Dessutom minskar optimal kvalitetsleverans tiden för omarbetning av kod och minskar antalet buggar och andelen fel som upptäcks. Det är därför vi rekommenderar att optimera kvalitetssäkringen för snabba och smidiga mjukvaruutvecklingsprocesser.
Mät KPI:er för mjukvaruutveckling för att maximera dina chanser att genomföra projektet
Programvaruutveckling är en iterativ process som kräver frekvent övervakning och justeringar för att säkerställa projektets framgång. Att fastställa KPI:er för programvaruutveckling gör att alla tar ansvar och säkerställer att programvaruutvecklingsarbetet fokuserar på affärsmålen.
De fungerar som en ledstjärna för mjukvaruutvecklingsteam, mäter dagliga framsteg och hjälper ledningen och cheferna att bättre förstå helheten.
Integrera ClickUps projektledningsprogramvara med programvaruleveransprocessen för att mäta framsteg, spåra KPI:er, justera dem efter behov och optimera din utvecklingsprocess.
Registrera dig gratis på ClickUp för att ställa in och spåra dina KPI:er för mjukvaruutveckling.