Agile Software Development Metrics och KPI: er som hjälper till att optimera produktleverans

Lästid: 13 minuter

den agila metoden för mjukvaruutveckling har länge varit en vanlig praxis. Enligt HP online-undersökningen väljer 16 procent av IT-proffsen ren smidig, 51 procent lutar sig mot den och 24 procent antar en smidig hybridstrategi. Idag nämns vattenfallsutveckling oftast som en smidig differentiator, vad smidig inte är. Vi har i stort sett diskuterat de viktigaste skillnaderna i vårt whitepaper om agila projekthanteringsmetoder.

trots anpassningsförmågan och flexibiliteten hos agile management och dess snabba svar på förändringar kan arbetsflödet förbli centraliserat och kontrollerat. Agila nyckeltal (key performance Indicators) ger vägledning för strategisk planering, utvärdering och förbättring av operativa processer.

traditionella värdehanteringssystem tenderar att fokusera på att slutföra uppgiften inom ramen för kategorisk schema och kostnad. Men med agile ser kunder och teammedlemmar omedelbara resultat och justerar tidsramar och ansträngningar för att leverera en produkt som motsvarar schemakraven. Vilka verktyg och tekniker kräver sådan kunskap? Här är vår översikt över agile development metrics performance assessment.

Agile software development KPI: er

i den här artikeln kommer vi inte att utforska alla möjliga agile development metrics och KPI: er. Dessutom kan du uppfinna dina egna som matchar ditt projekt bäst. Vi kommer dock att beskriva de vanligaste KPI: erna som används över flera mjukvaruutvecklingsaspekter:

• hastighet
• Sprint burndown
• släpp burndown
• Cykeltid
• kumulativt flöde
• Flödeseffektivitet
• kodtäckning genom automatiserade tester
• testautomatisering mot manuell testning
• McCabe cyklomatisk komplexitet (MCC)
• kod Churn

mätning av pågående arbete

hastighet

hastighet mäter mängden arbete (ett antal funktioner) som slutförts i en sprint. Även om det inte är ett förutsägelse-eller jämförelseverktyg, ger velocity team en uppfattning om hur mycket arbete som kan göras i nästa sprint.

hastighetsindex är unikt för varje lag och bör ställas in för att bedöma hur realistiskt åtagandet är. Till exempel, om projektbackloggen har 200 story points och i genomsnitt Slutför laget 10 story points per sprint, betyder det att laget kommer att kräva cirka 20 sprints för att slutföra projektet.

ju längre du spårar hastigheten, desto högre är noggrannheten i korrespondensen mellan skyldigheter och kostnader

för ett lag som just har antagit den smidiga metoden eller till och med påbörjat en ny produkt, kommer hastighetsuppskattningarna av de första sprintarna troligen att vara oregelbundna. Men när lag får erfarenhet kommer hastigheten att toppa och sedan nå en platå med förutsägbart flöde och förväntad prestanda. En minskning av konsekvent flöde kommer att indikera problem i utvecklingen och avslöja behovet av förändring.

Tips för att använda hastighetsmetriken

bekämpa inkonsekvens efter 3-5 sprintar. Om hastigheten förblir inkonsekvent efter en lång tidsperiod, överväga att bedöma både externa och interna faktorer som förhindrar tydlig uppskattning.

ändra hastighetsspårningen efter lag-och uppgiftsändringar. När en teammedlem lämnar projektet eller fler medlemmar/aktiviteter läggs till, räkna om hastighet eller starta om beräkningen helt.

tre sprintar räcker för tidiga prognoser. För att förutsäga framtida prestanda, använd genomsnittet av de tre tidigare sprintarna.

Sprint burndown diagram

sprint burndown diagrammet visar mängden arbete som återstår att göra före slutet av en sprint. Verktyget är särskilt värdefullt eftersom det visar framstegen mot målet istället för att lista färdiga objekt. Det är också mycket användbart för att avslöja planeringsfel som ett lag gjorde i början av en sprint.

på diagrammet nedan representerar den svarta linjen den prognostiserade (ideala trendlinjen) som visar i vilken takt laget behöver bränna ner historiapunkter för att slutföra sprinten i tid. Den blå linjen anger den totala mängden arbete och dess framsteg under hela sprinten. Du kan se att under dagarna fem och sex lyckades ett lag inte uppnå de prognostiserade framstegen. Men på dag sju togs frågan upp och arbetet var tillbaka på rätt spår. Sådana pågående uppdateringar gör det möjligt för team att ta itu med nya problem under dagliga stand-up-möten.

förutom arbetet prestanda i sig, burndown diagram kan avslöja planeringsfrågor

Tips för att närma sprint burndown

Story punkter bör vara ännu i omfattning. Om arbetsflödet inte är konsekvent kan vissa aktiviteter ha delats upp i ojämna bitar. Omfattningen av avvikelsen mellan en ideal trend och verkligheten belyser tydligt detta problem.

redogöra för oplanerade uppgifter. Burndown-diagrammet är användbart för att förstå omfattningen av dolda och ospårade uppgifter. Om mängden arbete ökar istället för att minska, har projektet många oskattade eller oplanerade uppgifter som bör åtgärdas.

Använd ett burndown-diagram för att bedöma lagets förtroende. Med tanke på de aktuella priserna, fråga ditt lag hur säker De är på att slutföra sprinten i tid. Ju längre du använder det här måttet, desto mer exakta är dina sprintberäkningar.

uppskatta utgåvan med ett burndown-diagram

ett release burndown-diagram anger hur mycket arbete som måste slutföras innan en release. Diagrammet illustrerar framstegsöversikten och låter dig implementera ändringar för att säkerställa leverans i tid.

en traditionell version av diagrammet liknar sprint burndown-diagrammet, men ger en översikt över hela projektet där y-axeln är sprintar och x-axeln är ett mått på återstående arbete (dagar, timmar eller historiapunkter). Men vad händer om mer arbete läggs till i projektet eller om ditt beräknade arbete inte uppfyller förväntningarna?

på diagrammet nedan planerade ett team att slutföra ett projekt i fyra sprintar och hade ursprungligen 45 berättelsepoäng. Medan framstegen gick som planerat under första och andra sprinten ökade det uppskattade arbetet vid den tredje sprinten, vilket återspeglas på y-axeln i negativa värden. Under den tredje sprinten uppträdde 5 nya berättelsepunkter. De slutfördes inte och den fjärde sprinten lade till ytterligare 5 berättelsepoäng. Därför måste framstegen och frisättningstiden justeras.

release burndown diagram är super effektiv för situationer med massor av förändrade krav och tillåter ett team att hålla på rätt spår under varje sprint

Hur kan release burndown diagram hjälp?

realtids förutsägelse på release. När ditt projekt genomgår förändringar, vilket händer varje gång med iterativt utvecklande produkter, måste du se hur dessa förändringar påverkar släppdatumet. Release burndown-diagrammet gör det möjligt att förutsäga släppdatumet i realtid enligt uppdateringar i arbetsomfånget.

Deadline förutsägelser. Du kan uppskatta om teamet kan slutföra en produktrelease i tid eller förutse att tidsfristen ska gå vidare med tanke på tillagda uppgifter.

uppskatta antalet sprintar. Att bedöma hur många sprintar som krävs för att avsluta arbetet är också en viktig faktor att tänka på med release burndown-diagrammet.

bedömning av processhälsa och hitta flaskhalsar

Cykeltid

mätvärdet cykeltid beskriver hur mycket tid som spenderades på en uppgift, inklusive varje gång arbetet måste öppnas igen och slutföras igen. Beräkning av cykeltiden ger information om den totala prestandan och möjliggör uppskattning av slutförandet av framtida uppgifter. Medan den kortare cykeltiden illustrerar bättre prestanda, värderas de lag som levererar inom en konsekvent cykel mest.

med hjälp av diagrammet nedan kan du identifiera den genomsnittliga tiden det tar att slutföra en uppgift, rita en median-eller kontrollgränslinje som inte bör korsas och märka vilka uppgifter som tog ovanligt lång tid att slutföra.

standardavvikelsen drar en linje mellan det normala och inte rekommenderade antalet dagar för att slutföra aktiviteten

du kan också stapla alla cykler för en viss period och dra insikt från att jämföra den med andra data. Genom att genomföra en ytterligare undersökning kan du dra slutsatser om kvaliteten på arbetet.

här kan du se att antalet slutförda uppgifter från Mars till juni har ökat liksom antalet buggar

hur man använder cykeltiden

leta efter likheter. En bra praxis är att hitta liknande saker som tar oförutsägbara cykeltider att slutföra, vilket avslöjar återkommande problem, antingen inom teknik eller ledning.

Rita förutsägelser. Du kan fatta datadrivna beslut genom att förutsäga tiden för att slutföra nya uppgifter baserat på liknande från det förflutna.

spåra takten. Diagrammet beskriver hur du håller samma arbetstakt och definierar om det finns interna problem som minskar arbetshastigheten.

kumulativt flödesschema (CFC)

det kumulativa flödesmåttet beskrivs av diagramområdet som visar antalet olika typer av uppgifter i varje steg i projektet med x-axeln som anger datum och y-axeln som visar antalet berättelsepunkter. Dess huvudsyfte är att ge en enkel visualisering av hur uppgifter fördelas i olika steg. Linjerna på diagrammet bör stanna mer eller mindre jämnt medan bandet med de ”färdiga” uppgifterna ska växa kontinuerligt.

diagrammet avslöjar mycket kritisk information som plötsliga flaskhalsar eller stigningar i något av banden

CFC kommer att vara till stor nytta för Kanban-team som en enkel visualisering av lagets arbete. Diagrammet motsvarar också kanbans trestegs arbetsflöde. Här kartlägger du också tre huvuduppgiftskategorier: att göra, pågår och slutfört.

dessutom hjälper diagrammet att identifiera när WIP-gränserna överskrids. Som ett av de mest värdefulla verktygen i agil utveckling är WIP-gränser avsedda att odla kulturen för efterbehandling och eliminera multitasking genom att ställa in maximal mängd arbete för varje projektstatus.

vilka frågor påpekas av CFC?

• Backlog tillväxt indikerar de olösta uppgifter som antingen är för låg prioritet att ta itu med just nu eller är föråldrade
• inkonsekvent flöde och plötsliga flaskhalsar indikerar vilka områden bör jämnas ut i de senare stadierna
• bredden på varje band visar den genomsnittliga cykeltiden
• den betydande utvidgningen av ”pågående” område kan innebära att laget inte kommer att kunna avsluta hela projektet i tid

flödeseffektivitet

flödeseffektivitet är ett mycket användbart mått i Kanban-utveckling som oftast förbises av utveckling team. Medan flödeseffektivitet kompletterar kumulativt flöde, ger det insikter i fördelningen mellan verkligt arbete och väntetider. Det är ett sällsynt fall när en utvecklare arbetar på en sak i taget utan att vänta. Verkligheten är vanligtvis mer komplex. Och ”work-in-progress” är ett namn som inte alltid matchar status.

koden kan till exempel ha många beroenden och du kan inte börja arbeta med någon funktion innan en annan är klar, eller dina prioriteringar ändras eller du väntar på en intressents godkännande. Att mäta hur mycket tid du väntar mot arbete kan vara ännu mer användbart än att effektivisera processer relaterade till verkligt arbete.

genom att titta på de lägsta effektivitetsindikatorerna kan du förstå de viktigaste flaskhalsarna

hur man använder flödeseffektivitet

beräkningsformel. Om du inte använder någon projekthanteringsprogramvara som innehåller dessa mätvärden kan du beräkna flödeseffektivitet med denna enkla formel: arbete/(arbete+vänta) * 100%. Då kan du visualisera det digitalt eller till och med rita grafen på din office whiteboard.

definiera din normala flödeseffektivitet. Som med alla andra mätvärden är det omöjligt att hävda normala siffror för alla projekt. Vissa säger att 15-procenten är okej för de flesta projekt, vilket i princip innebär att en historia eller ett annat arbete väntar 85 procent mot 15 procent behandlingstid. David J. Anderson, en ledningsexpert från LeanKanban School of Management, föreslår att 40 procent och högre borde vara målet för de flesta lag.

sönderdela detaljer om arbetet innan du fixar flödeseffektivitet. Diagrammet möjliggör visning av exakta tidsperioder när din effektivitet var lägst. Och dessa data måste analyseras mycket noggrant, eftersom den verkliga orsaken och dess botemedel inte avslöjas så lätt. Innan du börjar intensiva åtgärder, gör en grundlig undersökning av orsakerna.

öka flödeseffektiviteten med blockeringsanalys. Ett bra sätt att realisera föregående punkt är att öka din flödeseffektivitet med blocker clustering analysis. Om något arbete är blockerat förtjänar det en färgad klistermärke eller en annan form av visuell signal för att få dessa blockerare till lagets uppmärksamhet så att de kan reagera på dem.

du kan markera hur många dagar en del av arbetet är blockerat och prioritera upplösningen

vanligtvis ackumuleras blockerare i kluster eftersom de har många beroenden med varandra. Bättre blockeringsanalys kan göras om du clusteriserar dem från likheter på hög nivå som interna och externa blockerare och sedan specificerar ytterligare genom design, saknat innehåll eller andra saknade funktioner. Blocker-analys är ett enkelt sätt att undersöka dalarna i flödeseffektivitet.

mätning av kodkvalitet

kodtäckning

kodtäckning definierar hur många rader kod eller block som körs medan automatiserade tester körs. Kodtäckning är ett kritiskt mått för testdriven utveckling (TDD) och kontinuerlig leverans. Traditionellt tolkas metriken med ett enkelt tillvägagångssätt: ju högre kodtäckning desto bättre. För att mäta detta behöver du ett av de tillgängliga verktygen som overaller. Men de fungerar alla ungefär samma: när du kör tester kommer verktyget att upptäcka vilka av kodlinjerna som kallas minst en gång. Procentandelen uppringda rader är din kodtäckning.

overaller, till exempel, kommer att bryta ner koden täckning till varje fil mätning och markera täckta och avtäckta linjer

hur man använder kod täckning

fokusera på avtäckta linjer och inte överskatta de täckta. Om kodrad kallas en gång eller ännu mer, det betyder inte nödvändigtvis att funktionen stöder fungerar perfekt bra och användarna kommer att stanna nöjda. Att ringa en kodrad räcker inte alltid för att stänga testuppgiften. Å andra sidan visar andelen upptäckta linjer vad som inte har täckts alls och kan förtjäna testning.

prioritera täckt kod och sikta inte på 100 procent. Även om detta verkar kontraintuitivt betyder 100 procent täckning inte att du har testat koden korrekt. Ditt projekt har koden som är viktig och resten av en kodbas. Eftersom testautomatisering vanligtvis är ett dyrt initiativ bör det prioritera funktionerna och motsvarande bitar av kod.

testautomatisering mot manuell testning

denna mätning definierar hur många kodrader inom en funktion som redan omfattas av automatiserade tester mot de som testas manuellt. Detta följer direkt den tidigare metriska men har ett specifikt användningsfall. Testautomatiseringsandel mot manuell testning används endast när du kritiskt behöver automatisering för att täcka regressioner. Regressionstestning görs för att kontrollera om något blev trasigt efter funktionsuppdateringar. Och om din produkt genomgår ständiga förbättringar – vilket det borde – testning för regression bör automatiseras. Om det inte är det måste dina manuella QA-specialister upprepa samma testscenarier upprepade gånger efter varje uppdatering.

du kan använda samma instrument som används för kodtäckning för att rita denna metriska

som beskriver den automatiska testtäckningen per funktion gör att du kan prioritera de funktioner som 1) kan drabbas av regression efter uppdateringar och 2) för vilka automatiserade tester är kritiska. Vanligtvis har du inte tillräckligt med tid och personal för att täcka allt genom automatiserade tester på en gång, såvida du inte arbetar inom den testdrivna utvecklingsramen. Så det är bättre att prioritera de funktioner som säkert kommer att påverka användarupplevelsen.

McCabe Cyclomatic Complexity (MCC) av kod

Kodkomplexitetsmätningar används för att bedöma riskerna med problem under kodtestning och underhåll. Ju högre kodens komplexitet desto svårare blir det att se till att det har ett acceptabelt antal buggar och håller hög underhållsförmåga. Det vanligaste sättet att mäta kodkomplexitet är McCabe Cyclomatic Complexity Metric (MCC). En av formlerna för att rita komplexitetsresultat för MCC är följande:

MCC = kanter-noder + retur uttalanden

MCC på bilden är lika med 3

med denna metriska beräknar utvecklare inte deras kodkomplexitet genom att subjektivt titta på den. Eftersom ingenjörernas färdigheter skiljer sig, varierar deras bedömningar vilket gör kodrefactoring eller fixing bugs mer utmanande på längre sikt. Det finns många MCC-mätverktyg på marknaden som kan kombineras med andra kodkomplexitetsmått som djupet i kodhierarkin och antalet kodrader.

MCC använder detaljer och fallgropar

balansera mänsklig och maskinuppfattning av kodkomplexitet. En av de främsta anledningarna till att använda MCC är att göra kod läsbar för andra utvecklare. Kodens läsbarhet minskar riskerna för långsiktig onboarding av nya utvecklare som måste hantera äldre kod. Det kommer också att förenkla refactoring på vägen. Problemet här är att MCC-modellen kan betrakta några komplexa men läsbara metoder oacceptabla. Och om du tvingar en utvecklare att refactor komplexa metoder i många delmetoder, kan du uppnå motsatta resultat: många metoder med enkla logiker kan bli ännu svårare att förstå för en människa än en enda men ändå komplex metod.

gör inte MCC till ett restriktivt mått. Vissa organisationer övar på att avsluta kodförpliktelser som inte klarar MCC-testet. Även om detta potentiellt kan öka kodens enkelhet, är det naturligt att ha komplex kod på nivåerna av klasser, metoder och funktioner. Att blockera dem helt är inte alltid fördelaktigt. En bra praxis är att ställa in allmän kodkomplexitet KPI för utvecklare, vilket kommer att uppmuntra dem att närma sig kodning mer medvetet och tänka på enkelhet.

applicera MCC för kodgranskning. En annan värdefull praxis för MCC-tester är att tillämpa den under kodrecensioner för att begränsa omfattningen av arbetet för att granska specifika kodbitar där riskerna för defekter är högst.

Code churn

Code churn är en mycket användbar visualisering av trender och fluktuationer som händer med en kodbas både när det gäller den övergripande processen och tiden före en release. Churn mäter hur många kodrader som har lagts till, tagits bort eller ändrats. Ibland visar graferna alla tre mätningarna.

detta exempel från Microsoft innehåller alla tre parametrar, men du kan använda dem selektivt

även om spårningskod churn kan verka som en något primitiv metrisk, gör det möjligt att bedöma kodstabiliteten i olika utvecklingsstadier. Du bör förvänta dig den lägsta stabiliteten under de tidiga sprintarna och den högsta stabiliteten – med den samtidigt lägsta churn – precis före en release. Om din kod är mycket instabil och släppdatumet närmar sig, LARM Larmet.

kod churn användningsfall

leta efter regelbundenheter. Regelbundna spikar i kodändringar kan avslöja att uppgiftsgenereringsmetoden inte är tillräckligt fokuserad och producerar många stora uppgifter på återkommande basis.

oregelbundna men höga spikar kräver utredning. Om du har oregelbundna men kraftfulla spikar i kodändringar kan du undersöka vilka uppgifter som orsakade sådana seismiska toppar i din kod och ompröva nivån på beroenden, särskilt om antalet nya kodlinjer ökade antalet ändrade linjer också.

var uppmärksam på trender. Stabiliteten hos din produkt blir ganska kritisk innan en release. Som vi nämnde bör churnhastigheten ha en nedåtgående trend ju närmare ditt lag kommer till en release. En växande trend innebär möjlig produktinstabilitet efter en release eftersom det är troligt att den nya koden inte kommer att utsättas för tillräcklig testning.

sikta på framsteg, inte kontroll

precis som alla andra resultatindikatorer har agila mätvärden inte alltid tydliga svar eller handlingsbara tips som kommer att försegla din framgång. Du bör dock använda den kunskap de tillhandahåller för att starta en diskussion, göra en utvärdering och erbjuda din egen plan för att hantera problematiska problem.

medan mätvärden ger den numeriska insikten om ett lags prestanda och övergripande tillfredsställelse med arbetet, fixera inte på dem. Med tanke på att smidiga mätvärden inte är standardiserade är det ingen mening att jämföra framgångar för olika lag. Se snarare till att omfamna ditt teams feedback, initiera regelbundna diskussioner och ge näring till en atmosfär av gemensamma mål och stöd.