Agile Programmeludviklingsmålinger og KPI’ er, der hjælper med at optimere produktlevering

Læsetid: 13 minutter

den agile tilgang til programmeludvikling har længe været en almindelig praksis. Ifølge HP online-undersøgelsen vælger 16 procent af IT-fagfolk ren agil, 51 procent læner sig mod it, og 24 procent anvender en agil hybrid tilgang. I dag nævnes vandfaldsudvikling oftest som en smidig differentiator, hvad agile ikke er. Vi har bredt diskuteret de vigtigste forskelle i vores Hvidbog om agile projektledelsesmetoder.

på trods af den smidige ledelses tilpasningsevne og fleksibilitet og dens hurtige reaktion på ændringer kan arbejdsgangen forblive centraliseret og kontrolleret. Agile KPI ‘er (key performance Indicators) giver vejledning til strategisk planlægning, evaluering og forbedring af operationelle processer.

traditionelle værdistyringssystemer har tendens til at fokusere på opgaveafslutning inden for rammerne af kategorisk tidsplan og omkostninger. Men med agile ser kunder og teammedlemmer øjeblikkelige resultater og justerer tidsrammer og indsats for at levere et produkt, der svarer til tidsplankravene. Hvilke værktøjer og teknikker kræver sådan viden? Her er vores oversigt over agile udviklingsmetrics performance assessment.

Agile KPI ‘er

i denne artikel vil vi ikke undersøge alle mulige agile udviklingsmålinger og KPI’ er. Derudover kan du opfinde dine egne, der passer bedst til dit projekt. Imidlertid, vi vil beskrive de mest almindelige KPI ‘ er, der bruges på tværs af flere aspekter af programudvikling:

• hastighed
• Sprintnedbrydning
• Frigivelsesnedbrydning
• Cyklustid
• kumulativ strøm
• Strømningseffektivitet
• kodedækning ved automatiserede test
• testautomatisering mod manuel test
• McCabe cyklomatisk kompleksitet (MCC)
• kode churn

måling af igangværende arbejde

hastighed

hastighed måler mængden af arbejde (et antal funktioner) afsluttet i en sprint. Selvom det ikke er et Forudsigelses-eller sammenligningsværktøj, giver velocity teams en ide om, hvor meget arbejde der kan gøres i næste sprint.

hastighedsindeks er unikt for hvert hold og bør indstilles til at vurdere, hvor realistisk engagementet er. For eksempel, hvis projektet efterslæb har 200 historie punkter og i gennemsnit holdet fuldfører 10 historie punkter pr sprint, betyder det, at holdet vil kræve omkring 20 sprints at fuldføre projektet.

jo længere du sporer hastigheden, jo højere er nøjagtigheden af korrespondancen mellem forpligtelser og omkostninger

for et hold, der lige har vedtaget agile-metoden eller endda påbegyndt et nyt produkt, vil hastighedsestimaterne for de første par sprints sandsynligvis være uregelmæssige. Men når holdene får erfaring, vil hastigheden toppe og derefter nå et plateau med forudsigelig strømning og forventet ydeevne. Et fald i konsekvent strømning vil indikere problemer i udviklingen og afsløre behovet for forandring.

Tips til brug af hastighedsmetrikken

Bekæmp inkonsekvens efter 3-5 sprints. Hvis hastigheden forbliver inkonsekvent efter en lang periode, skal du overveje at vurdere både eksterne og interne faktorer, der forhindrer klar estimering.

ændre hastighedssporingen efter team-og opgaveændringer. Når et teammedlem forlader projektet eller flere medlemmer/opgaver tilføjes, genberegne hastighed eller genstart beregning helt.

tre sprints er nok til tidlige prognoser. For at forudsige fremtidige resultater, bruge gennemsnittet af de tre foregående sprints.

Sprint burn-ned diagram

sprint burn-ned diagrammet viser mængden af arbejde, der er tilbage, der skal udføres inden slutningen af en sprint. Værktøjet er særligt værdifuldt, fordi det viser fremskridtene mod målet i stedet for at notere færdige varer. Det er også meget nyttigt at afdække planlægningsfejl, som et hold lavede i begyndelsen af en sprint.

på diagrammet nedenfor repræsenterer den sorte linje den forventede (ideelle trend) linje, der viser, i hvilken hastighed holdet har brug for at brænde historiepunkter ned for at fuldføre sprinten til tiden. Den blå linje angiver den samlede mængde arbejde og dets fremskridt gennem sprinten. Du kan se, at et hold i løbet af dage fem og seks ikke lykkedes at opnå de forventede fremskridt. Imidlertid, på dag syv, spørgsmålet blev behandlet, og arbejdet var tilbage på sporet. Sådanne løbende opdateringer giver teams mulighed for at løse nye problemer under daglige stand-up-møder.

udover selve arbejdsydelsen kan nedbrændingsdiagrammer afsløre planlægningsproblemer

Tips til tilgang til sprintnedbrydning

historiepunkter skal være lige i omfang. Hvis arbejdsprocessen ikke er ensartet, kan nogle opgaver være opdelt i ujævne bidder. Omfanget af afvigelse mellem en ideel tendens og virkeligheden fremhæver tydeligt dette problem.

konto for uplanlagte opgaver. Nedbrændingsdiagrammet er nyttigt til at forstå omfanget af skjulte og ikke-sporede opgaver. Hvis mængden af arbejde stiger i stedet for at falde, har projektet mange ikke-estimerede eller ikke-planlagte opgaver, der skal løses.

brug et nedbrændingsdiagram til at vurdere holdets tillid. I betragtning af de nuværende satser, spørg dit team, hvor sikre de er på at gennemføre sprinten til tiden. Jo længere du anvender denne måling, jo mere nøjagtige er dine sprint-estimater.

estimering af udgivelsen med et nedslagsdiagram

et nedslagsdiagram angiver den mængde arbejde, der skal udføres, før en udgivelse. Diagrammet illustrerer statusoversigten og giver dig mulighed for at implementere ændringer for at sikre levering til tiden.

en traditionel version af diagrammet svarer til sprint-nedbrændingsdiagrammet, men giver et overblik over hele projektet, hvor y-aksen er sprints, og H-aksen er et mål for resterende arbejde (dage, timer eller historiepunkter). Men hvad nu hvis der tilføjes mere arbejde til projektet, eller dit estimerede arbejde ikke lever op til forventningerne?

på nedenstående diagram planlagde et team at gennemføre et projekt i fire sprints og havde oprindeligt 45 historiepunkter. Mens fremskridtene gik som planlagt under den første og anden sprint, steg det anslåede arbejde ved den tredje sprint, hvilket afspejles på y-aksen i negative værdier. Under den tredje sprint dukkede 5 nye historiepunkter op. De blev ikke afsluttet, og den fjerde sprint tilføjede yderligere 5 historiepunkter. Derfor måtte fremskridtene og frigivelsestiden justeres.

release burn ned chart er super effektiv til situationer med masser af skiftende krav og gør det muligt for et hold at holde sig på sporet under hver sprint

Hvordan kan release burn ned chart hjælpe?

real-time forudsigelse på frigivelse. Når dit projekt gennemgår ændringer, hvilket sker hver gang med iterativt udvikling af produkter, skal du se, hvordan disse ændringer påvirker udgivelsesdatoen. Udbrændingsdiagrammet giver mulighed for at forudsige udgivelsesdatoen i realtid i henhold til opdateringer i arbejdsomfanget.

Deadline forudsigelser. Du kan estimere, om teamet kan gennemføre en produktudgivelse til tiden eller forudse, at fristen skal gå videre i betragtning af tilføjede opgaver.

estimering af antallet af sprints. At vurdere, hvor mange sprints der kræves for at afslutte arbejdet, er også en vigtig faktor at overveje med frigivelsesopbrændingsdiagrammet.

vurdering af proces sundhed og finde flaskehalse

Cyklustid

cyklustidsmetrikken beskriver, hvor meget tid der blev brugt på en opgave, inklusive hver gang arbejdet skulle genåbnes og afsluttes igen. Beregning af cyklustiden giver information om den samlede præstation og giver mulighed for at estimere færdiggørelsen af fremtidige opgaver. Mens den kortere cyklustid illustrerer bedre ydeevne, værdsættes de hold, der leverer inden for en ensartet cyklus, mest.

ved hjælp af diagrammet nedenfor kan du identificere den gennemsnitlige tid, det tager at udføre en opgave, tegne en median-eller kontrolgrænselinje, der ikke skal krydses, og bemærke, hvilke opgaver der tog usædvanligt lang tid at afslutte.

standardafvigelsen trækker en linje mellem det normale og ikke anbefalede antal dage for at fuldføre opgaven

du kan også stable alle cyklusser i en bestemt periode og få indsigt i at sammenligne den med andre data. Ved at foretage en yderligere undersøgelse kan du drage konklusioner om kvaliteten af arbejdet.

her kan du se, at antallet af udførte opgaver fra marts til juni er vokset, ligesom antallet af fejl

Sådan bruges cyklustiden

se efter ligheder. En god praksis er at finde lignende ting, der tager uforudsigelige cyklustider at gennemføre, afslører tilbagevendende problemer, enten inden for teknik eller ledelse.

tegn forudsigelser. Du kan tage datadrevne beslutninger ved at forudsige tiden til at udføre nye opgaver baseret på lignende fra fortiden.

spor tempoet. Diagrammet beskriver, hvordan du holder det samme tempo i arbejdet og definerer, om der er interne problemer, der reducerer arbejdshastigheden.

kumulativt rutediagram (CFC)

den kumulative strømningsmetric er beskrevet af diagramområdet, der viser antallet af forskellige typer opgaver på hvert trin i projektet med H-aksen, der angiver datoer og y-aksen, der viser antallet af historiepunkter. Hovedformålet er at give en nem visualisering af, hvordan opgaver fordeles på forskellige stadier. Linjerne på diagrammet skal forblive mere eller mindre lige, mens båndet med de “færdige” opgaver skal vokse kontinuerligt.

diagrammet afslører en masse kritiske oplysninger såsom pludselige flaskehalse eller stigninger i et af båndene

CFC vil være til stor nytte for Kanban-hold som en simpel visualisering af holdets arbejde. Diagrammet svarer også til Kanbans tre-trins arbejdsgang. Her kortlægger du også tre hovedopgavekategorier: to-do, i gang og afsluttet.

desuden hjælper diagrammet med at identificere, hvornår grænserne for igangværende arbejde overskrides. At være et af de mest værdifulde værktøjer inden for agil udvikling, er vipgrænser beregnet til at dyrke kulturen for efterbehandling og eliminere multitasking ved at indstille den maksimale mængde arbejde for hver projektstatus.

hvilke spørgsmål påpeges af CFC?

• efterslæb vækst angiver de uløste opgaver, der enten er for lav prioritet til at tackle i øjeblikket eller er forældede
• inkonsekvent strømning og pludselige flaskehalse angiver, hvilke områder der skal udglattes i de senere faser
• bredden af hvert bånd viser den gennemsnitlige cyklustid
• den betydelige udvidelse af “i gang” – området kan betyde, at holdet ikke vil være i stand til at afslutte hele processen med at projekt til tiden

strømningseffektivitet

strømningseffektivitet er en meget nyttig måling i Kanban-udvikling, der for det meste overses af udvikling team. Mens strømningseffektivitet supplerer kumulativ strømning, giver den indsigt i fordelingen mellem faktisk arbejde og ventetider. Det er et sjældent tilfælde, når en udvikler arbejder på en ting ad gangen uden at vente. Virkeligheden er normalt mere kompleks. Og “igangværende arbejde” er et navn, der ikke altid matcher status.

for eksempel kan koden have mange afhængigheder, og du kan ikke begynde at arbejde med en funktion, før en anden er færdig, eller dine prioriteter ændres, eller du venter på en interessents godkendelse. At måle, hvor meget tid du venter mod arbejde, kan være endnu mere nyttigt end at strømline processer relateret til faktisk arbejde.

ved at se på de laveste effektivitetsindikatorer kan du forstå de vigtigste flaskehalse

Sådan bruges strømningseffektivitet

beregningsformel. Medmindre du anvender nogle projektstyringsprogrammer, der inkorporerer disse målinger, kan du beregne strømningseffektivitet ved hjælp af denne enkle formel: arbejde/(arbejde+Vent) * 100%. Derefter kan du visualisere det digitalt eller endda tegne grafen på dit kontor tavle.

definer din normale strømningseffektivitet. Som med alle andre målinger er det umuligt at kræve normale tal for alle projekter. Nogle siger, at 15 procent-mærket er okay for de fleste projekter, hvilket dybest set betyder, at et historiepunkt eller et andet stykke arbejde venter 85 procent mod 15 procent behandlingstid. David J. Anderson, en ledelsesekspert fra LeanKanban School of Management, foreslår, at 40 procent og højere skal være målet for de fleste hold.

dekomponere detaljer om arbejdet før fastsættelse strømningseffektivitet. Diagrammet giver mulighed for at se nøjagtige perioder, hvor din effektivitet var den laveste. Og disse data skal analyseres meget omhyggeligt, da den virkelige årsag og dens afhjælpning ikke afsløres så let. Før du begynder intensive handlinger, lav en grundig undersøgelse af årsager.

Forøg strømningseffektiviteten med blokeringsanalyse. Et godt middel til at realisere det foregående punkt er at øge din strømningseffektivitet med blocker clustering analyse. Hvis noget arbejde er blokeret, fortjener det et farvet klistermærke eller en anden form for visuelt signal for at bringe disse blokkere til holdets opmærksomhed, så de kan reagere på dem.

du kan markere, hvor mange dage noget af arbejdet er blokeret og prioritere opløsningen

normalt akkumuleres blokkere i klynger, da de har mange afhængigheder med hinanden. Bedre blokkeranalyse kan udføres, hvis du klynger dem ud fra ligheder på højt niveau som interne og eksterne blokkere og derefter specificerer yderligere ved design, manglende indhold eller andre manglende funktioner. Blokkeranalyse er en enkel måde at undersøge dalene i strømningseffektivitet.

målekodekvalitet

kodedækning

kodedækning definerer, hvor mange linjer kode eller blokke der udføres, mens automatiserede tests kører. Kodedækning er en kritisk metric for test-driven development (TDD) praksis og kontinuerlig levering. Traditionelt fortolkes metricen ved en simpel tilgang: jo højere kodedækning, desto bedre. For at måle dette skal du bruge et af de tilgængelige værktøjer som overalls. Men de fungerer alle stort set det samme: når du kører test, registrerer værktøjet, hvilke af kodelinjerne der kaldes mindst en gang. Procentdelen af kaldte linjer er din kodedækning.

overalls, for eksempel, vil nedbryde kodedækningen til hver filmåling og fremhæve dækkede og udækkede linjer

Sådan bruges kodedækning

fokus på udækkede linjer og overvurder ikke de dækkede. Hvis kodelinjen kaldes en gang eller endnu mere, betyder det ikke nødvendigvis, at den funktion, den understøtter, fungerer perfekt, og brugerne forbliver tilfredse. At kalde en kodelinje er ikke altid tilstrækkelig til at lukke testopgaven. På den anden side viser procentdelen af afdækkede linjer, hvad der slet ikke er dækket og kan fortjener test.

Prioriter dækket kode og mål ikke 100 procent. Selvom dette virker kontraintuitivt, betyder 100 procent dækning ikke, at du har testet koden korrekt. Dit projekt har den kode, der betyder noget, og resten af en kodebase. Da testautomatisering normalt er et dyrt initiativ, bør det prioritere funktionerne og tilsvarende klumper af kode.

testautomatisering mod manuel test

denne måling definerer, hvor mange kodelinjer i en funktion der allerede er dækket med automatiserede tests mod dem, der testes manuelt. Dette følger direkte den foregående metric, men har en specifik brugssag. Testautomatiseringsandel mod manuel test bruges kun, når du kritisk har brug for automatisering for at dække regressioner. Regressionstest udføres for at kontrollere, om noget blev brudt efter funktionsopdateringer. Og hvis dit produkt gennemgår konstante forbedringer – som det skal – test for regression bør automatiseres. Hvis det ikke er tilfældet, skal dine manuelle kvalitetssikringsspecialister gentage de samme testscenarier gentagne gange efter hver opdateringsforpligtelse.

du kan bruge de samme instrumenter, der bruges til kodedækning, til at tegne denne metric

ved at skitsere den automatiserede testdækning pr.funktion kan du prioritere de funktioner, der 1) kan lide af regression efter opdateringer, og 2) for hvilke automatiserede tests er kritiske. Normalt har du ikke nok tid og menneskelige ressourcer til at dække alt ved automatiserede tests på en gang, medmindre du arbejder inden for den testdrevne udviklingsramme. Så det er bedre at prioritere de funktioner, der helt sikkert vil påvirke brugeroplevelsen.

McCabe Cyclomatic kompleksitet (MCC) af kode

kode kompleksitetsmålinger bruges til at vurdere risikoen for problemer under kode test og vedligeholdelse. Jo højere kodens kompleksitet er, desto vanskeligere bliver det at sikre, at det har et acceptabelt antal fejl og holder høj vedligeholdelse. Den mest almindelige tilgang til måling af kodekompleksitet er McCabe Cyclomatic Kompleksitetsmetric (MCC). En af formlerne til at tegne kompleksitetsresultater for MCC er følgende:

MCC = kanter-noder + retur erklæringer

MCC på billedet er lig med 3

med denne måling estimerer udviklere ikke deres kodekompleksitet ved subjektivt at se på det. Da ingeniørernes færdigheder er forskellige, varierer deres vurderinger, hvilket gør koderefactoring eller fastsættelse af fejl mere udfordrende på længere sigt. Der er mange MCC-måleværktøjer på markedet, der kan kombineres med andre kodekompleksitetsmålinger, såsom dybden af kodehierarki og antallet af kodelinjer.

MCC brug SPECIFIKATIONER og faldgruber

Balance menneske og maskine opfattelse af kode kompleksitet. En af hovedårsagerne til at bruge MCC er at gøre kode læsbar for andre udviklere. Læsbarheden af kode reducerer risikoen for langsigtet onboarding af nye udviklere, der skal håndtere ældre kode. Det vil også forenkle refactoring ned ad vejen. Problemet her er, at MCC-modellen kan betragte nogle komplekse, men læsbare metoder som uacceptable. Og hvis du tvinger en udvikler til at refactor komplekse metoder til mange undermetoder, kan du opnå de modsatte resultater: mange metoder med enkle logikker kan blive endnu sværere at forstå for et Menneske end en enkelt, men kompleks metode.

gør ikke MCC en restriktiv metric. Nogle organisationer praktiserer afslutning af kodeforpligtelser, der ikke består MCC-testen. Selvom dette potentielt kan øge kodens enkelhed, er det naturligt at have kompleks kode på niveauerne af klasser, metoder og funktioner. At blokere dem helt er ikke altid gavnligt. En god praksis er at indstille generel kode kompleksitet KPI for udviklere, hvilket vil tilskynde dem til at nærme sig kodning mere bevidst og tænke på enkelhed.

Anvend MCC til kodeanmeldelse. En anden værdifuld praksis for MCC-test er at anvende den under kodevurderinger for at indsnævre omfanget af arbejdet til at gennemgå specifikke kodebunker, hvor risikoen for mangler er den højeste.

Code churn

Code churn er en meget nyttig visualisering af tendenser og udsving, der sker med en kodebase både med hensyn til den samlede proces og tiden før en frigivelse. Churn måler, hvor mange kodelinjer der blev tilføjet, fjernet eller ændret. Nogle gange viser graferne alle tre målinger.

dette eksempel fra Microsoft indeholder alle tre parametre, men du kan bruge dem selektivt

selvom sporingskode churn kan virke en noget primitiv metrisk, giver det mulighed for at vurdere kodestabiliteten i forskellige udviklingsstadier. Du bør forvente den laveste stabilitet under de tidlige sprints og den højeste stabilitet – med den samtidig laveste churn – lige før en frigivelse. Hvis din kode er meget ustabil, og udgivelsesdatoen nærmer sig, skal du slå alarmen.

kode churn use cases

se efter regelmæssigheder. Regelmæssige pigge i kodeændringer kan afsløre, at opgavegenereringsmetoden ikke er fokuseret nok og producerer mange store opgaver på tilbagevendende basis.

uregelmæssige, men høje pigge kræver undersøgelse. Hvis du har uregelmæssige, men kraftige pigge i kodeændringer, kan du undersøge, hvilke opgaver der forårsagede sådanne seismiske toppe i din kode og genoverveje afhængighedsniveauet, især hvis antallet af nye kodelinjer også øgede antallet af ændrede linjer.

Vær opmærksom på tendenser. Stabiliteten af dit produkt bliver ret kritisk før en frigivelse. Som vi nævnte, bør churn-satsen have en faldende tendens, jo tættere dit team kommer på en frigivelse. En voksende tendens betyder mulig produktinstabilitet efter en frigivelse, fordi det er sandsynligt, at den nye kode ikke vil blive underkastet tilstrækkelig test.

mål for fremskridt, ikke kontrol

ligesom alle andre præstationsindikatorer har agile metrics ikke altid forskellige svar eller handlingsmæssige tip, der vil forsegle din succes. Du skal dog bruge den viden, de giver, til at starte en diskussion, foretage en evaluering og tilbyde din egen plan til håndtering af problematiske problemer.

mens metrics giver den numeriske indsigt i et teams præstationer og generelle tilfredshed med arbejdet, skal du ikke fiksere dem. I betragtning af at agile metrics ikke er standardiserede, er der ingen mening i at sammenligne succeser fra forskellige hold. Sørg snarere for at omfavne dit teams feedback, indlede regelmæssige diskussioner og nære en atmosfære af fælles mål og støtte.