vores erfaring med at bruge mest almindelige Agile Metrics

vores erfaring med at bruge mest almindelige Agile Metrics

brug af Agile metrics til at måle teamets produktivitet er den centrale del af Agile ‘ s filosofi. Teamledere og alle medlemmer bør se konsekvenserne af deres arbejde og bruge disse data til at forbedre arbejdsgangen og øge effektiviteten.

slutbrugere og klienter kan også drage fordel af brugen af Agile projektmålinger, der fokuserer på at evaluere resultatet af produktet. Metrics giver scrum masters, udviklere, designere og testere mulighed for at måle applikationens ydeevne og spore, om aktuelle og tidligere opgaver gør produktet bedre.

i denne artikel gennemgår vi Agile metrics, der betyder noget, og deler vores erfaring med at anvende dette Agile metrics dashboard til et virkeligt projekt. Det viser sig, at for at lede et team med succes og levere resultater, behøver du ikke kun at vide, hvilke målinger der skal anvendes, men hvordan man gør det — vi deler, hvordan vi regnede det ud.

typer af fælles Agile metrics

klassificeringen af Agile metrics er ikke sat i sten — det er altid skiftende og omstrukturering. I årenes løb har vi set stigningen i tre hovedtyper af Agile metrics i forskellige Agile rammer.

1. Kanban — metrics-disse målinger er baseret på måling af investeret tid (cyklustider) og leverede resultater (gennemstrømning) og deres forhold.
2. Scrum metrics — metrics, der er fokuseret på planlægning og forståelse af arbejdsgangen og demonstrerer, hvor meget arbejde der blev udført i en given periode;
3. Lean metrics — den kontinuerlige måling af produktionseffektivitet og produktkvalitet med teknisk vurdering ved at teste funktioner, kontrollere mulige fejl og forudse negative effekter.

vi bruger alle tre typer metrics til at vurdere de vigtigste aspekter af programmeludviklingsprocessen og resultaterne: produktkvalitet, teamets produktivitet og sundhed.

Agile kvalitetsmålinger

før du begynder at måle holdets hastighed og effektivitet, skal du vide, om du generelt bevæger dig i den rigtige retning. Hvad er brugen i hurtig levering af alle udviklingsopgaver, hvis opgaverne selv er dannet på den forkerte måde? Prioriteringen for hvert programudviklingsteam og manager er at sikre, at alle aktiviteter er relateret til forbedring af produktet — dette gøres ved at måle dets kvalitet og opdage negative tendenser.

Escaped defects

hvert Agile projekt har sprints eller arbejdscyklusser, i slutningen af hvilken en bestemt opgave leveres. Efter at arbejdet var afsluttet, skal holdets leder vurdere kvaliteten af turned-it-resultater. Alle ændringer, redigeringer og ikke — faste fejl er undslapede fejl-problemer, som udviklere kunne have løst, men ikke gjorde. registrer deres nøjagtige antal og karakter for at vide, hvilke fejl der normalt undslipper udviklernes øjne.

når du har lavet en rapport om undslapne defekter og indsamlet håndgribelige statistikker, skal du diskutere resultaterne med dit team. Sørg for, at hvert teammedlem ved, hvilke slags fejl teamet typisk går glip af. Hvis du har individuelle forslag, skal du diskutere dem med teammedlemmer en-til-en.

mislykkede implementeringer

hvis produktet blev implementeret, men ikke frigivet eller ikke kunne tiltrække brugere, registreres dette som en mislykket implementering. Nogle gange sker en mislykket implementering med beslutninger fra en af interessenterne, eller forretningsmodellen viser sig at være upålidelig. Uanset hvad der var årsagen til problemet, skal du registrere alle mislykkede implementeringer sammen med årsagerne til deres fiasko.

før du frigiver en ny implementering, kan teamet altid se på listen over tidligere mislykkede implementeringer og undersøge, om denne ikke kan gennemgå den samme proces. Analyse af årsagerne til svigt i tidligere versioner gør det muligt at undgå fremtidige problemer.

Release Net Promoter Score (NPS)

Net Promoter Score er den måling, der involverer evaluering af brugernes reaktioner i kvantitativ (tal, statistik, gennemsnitlige vurderinger) og kvalitativ feedback (anmeldelser, direkte feedback, meddelelser, e-mails, opkald). Efter at holdet har indsamlet og analyseret feedbacken, foreslår hvert teammedlem en score, der vurderer, hvor meget brugeren sandsynligvis vil anbefale produktet (typisk er scoringer sat i grænser fra 1 til 10).

Agile project management metrics

når du har en fuld historie med tidligere fejl og succeser, kan du analysere retningen taget for alle aktuelle ufuldstændige projekter og give relevante opgaver ud fra tidligere erfaringer. Når du har etableret udviklingsretningen — “hvad skal man gøre” af produktet, “skal du vurdere holdets effektivitet-det er” hvordan gør vi ” faktoren. Du kan bruge Agile projektmålinger til at vide, om teammedlemmer lever op til dine forventninger, forstår deres opgaver, administrerer deadlines, og om alle processer koordineres og synkroniseres.

ledetid

ledetid er en måling, der gør det muligt for hold at kontrollere, hvor meget det tog for product backlog-posten at nå frem til slutningen af sprinten. Det kan bruges til at spore produkter på ethvert udviklingsstadium, opgave for opgave eller vurdere de samlede tidsudgifter, fra ideation til frigivelse. Det er en langsigtet måling, som udviklere kan bruge, mens de planlægger deres fremtidige arbejde og estimerer priser.

sørg for at registrere leveringstid for hvert af dine projekter. Det er bedst at holde både større billedstatistikker, der dækker hele projektet, og har organiseret sprintmålinger-så du kan undersøge hvert trin separat.

Cyklustid

hvis ledetiden er blandt langsigtede teampræstationsmålinger, fokuserer cyklustiden på individuelle opgaver. Denne måling evaluerer varigheden af en enkelt cyklus, hvor en cyklus tages af en opgave, beregner antallet af cyklusser pr.projekt og måler opnåede resultater for slutbrugeren, hvis produktet allerede er betatestet eller frigivet.

med cyklustid kan hold straks se, om en opgave tager for meget tid, eller om nogle teammedlemmer ikke leverer på deres ender. Denne kortsigtede måling gør projektstyring meget lettere og hjælper med hurtigt at identificere problemer, når de opstår.

Sprintnedbrydning

denne måling anvendes både på kort og lang sigt. Ledere kan oprette sprint burn-Scrum-rapporter i realtid for at spore deres teams fremskridt med det aktuelle projekt-til dette skal de estimere det samlede antal sprints og forudsige sandsynlige tidsudgifter. Det kan også bruges på lang sigt-ledere kan analysere rapporter om tidligere projekter, lokalisere faser, der mislykkedes forventede tidsrammer, og analysere årsager til forsinkelser.

vigtigst af alt, sprint burn ned tillader sporing dynamikken i teams arbejdsgang. Nogle medlemmer har en tendens til at arbejde langsommere i de første faser, mens andre brænder ud mod slutningen af projektet. Med sprint-nedbrud kan teamledere opdage disse tendenser, bestemme deres årsager og hjælpe medlemmer med arbejdsfordeling og tidsstyring.

Epic& release burn ned

denne måling svarer til Sprint Burn ned — den eneste nøgleforskel er, at den fokuserer på holdets produktivitet før og efter udgivelsen. Ledere kan tilføje nye krav og indarbejde opgaver, der er baseret på slutbrugernes feedback. Det er en forbedret version af sprint-nedbrydning, da den også indeholder opgaver, der er givet efter udgivelsen af projektet.

hastighed

denne måling evaluerer antallet af afsluttede historiepunkter over en bestemt periode. Baseret på din historie kan du forudse tidsudgifter til fremtidige historiepunkter. Faldet i holdets hastighed på bestemte sprints kan pege på misforståelse blandt teammedlemmer eller angivne opgaver, der er sværere end tidligere forventet.

yderligere Agile metrics

Agile metrics hjælper teamet med at kende deres projekt bedre og holde styr på mange vigtige aspekter af produktudvikling. Der er også Agile målinger for ledende medarbejdere, der gør det muligt at se det større billede af udvikling og holdets trivsel. Ifølge vores erfaring hjælper disse yderligere målinger med at måle ethvert aspekt af dit arbejde. Alligevel definerede vi de vigtigste egenskaber, der fortæller mest om det endelige produkt og hjælper med at levere et fuldt komplet resultat.

kumulativ strøm

metrikkens navn kommunikerer klart sit formål — at akkumulere alle projektstrømme og evaluere dem i et enkelt diagram. At have en sådan graf giver dig en storstilet visning-den kan sendes til projektinteressenter, der ikke har tid til at analysere mere detaljerede Agile rapporter.

diagrammet beskriver normalt følgende processer:

• opgaver i backlog: hvor mange opgaver i backlog teammedlemmer har over den givne tidsramme;
• godkendt arbejde: hvor mange opgaver blandt de planlagte blev afsluttet — teamlederen ser straks forskellene mellem planlagte og afsluttede aktiviteter;
• Bufferopgaver: alt arbejde, der venter på godkendelse, er defineret til at være i et buffersone;
• i gang: du skal evaluere den aktuelle arbejdsbyrde.

Code churn

denne metric viser udviklingen i kodebaseændringer før udgivelsen. Churn-diagrammer viser, hvor meget kode der blev tilføjet, fjernet eller ændret en gang ad gangen. Ved tidlige sprints vil der være mange pigge og falder på grafen, fordi koden stadig er ustabil, men efterhånden som projektet skrider frem, skal kodekurngrafen blive stabil uden drastiske op-og nedture.

før udgivelsen skal churn få en tilbagegang — tilføjelse eller redigering af kode før selve udgivelsen betyder, at den ikke vil gennemgå tilstrækkelig test. Samlet set, når der er en uregelmæssighed på de Agile diagrammer, undersøge årsagerne.

kontroldiagram

et kontroldiagram er et diagram, hvor holdet kan se oplysninger om varigheden af deres cyklustider. Det ideelle resultat ville have linjen på diagrammet støt ned med tiden — det ville betyde stigningen i holdets hastighed-mindre tid kræves pr. Et andet vigtigt aspekt er konsistens-cyklustider skal forblive lige uanset opgavens type-det betyder, at du har korrekt arbejdsfordeling.

Health metrics

Programmeludviklingsteams skal fokusere på langsigtede prioriteter, såsom at holde kommunikationen mellem medlemmerne glat og kontrollere, om alle er tilfredse. Agile er en fleksibel metode, hvilket betyder, at den kan tilpasse sig forskellige medlemmers interesser, så snart ledere ved, hvad de skal være opmærksomme på. Sådan finder vi ud af, om alle vores teammedlemmer er tilfredse med arbejdsgangen.

lykke

hvis du har tillid til uformelle relationer i dit team, er det lettere at starte med en åben dialog med hvert medlem. Bed alle om at bedømme deres erfaring i virksomheden fra 1 til 5. Du kan stille assisterende spørgsmål-Hvad er de bedste og værste aspekter af deres arbejde, hvad kunne forbedres, og hvad kunne øge lykken? Hvis teamet ikke har venlige kommunikationsvaner, kan brug af anonyme undersøgelser føre til mere objektive resultater.

Holdmoral

Holdmoral og lykke er ikke de samme ting. Lykke har mere at gøre med komfort, mens holdmoralen er bundet til produktivitet, selvværd, evaluering af egne faglige kvaliteter. Igen kan du bede medarbejderne om at bedømme deres moral fra 1 til 5 og stille følgende spørgsmål;

• har arbejdet i virksomheden bidraget til at forbedre dine færdigheder?
• hvor meget udforskes dit fulde potentiale med den aktuelle arbejdsbyrde?
• nyder du dit arbejde?
• ser du de klare resultater af dit arbejde?
• er du begejstret for nye projekter?

målet her er at forstå, at holdets udviklingsstrøm går i den rigtige retning. Nogle gange tager programudviklingsteamets leder rentable, men kedelige opgaver og ignorerer medlemmernes interesser. Denne undersøgelse hjælper dig med at se, om medarbejderne er begejstrede og udfordret af deres arbejde.

teammedlemsomsætning

hvis teamledere ofte erstatter teammedlemmer, betyder det, at arbejdsmiljøet sandsynligvis er usundt. En vis omsætningshastighed over tid er sund — faktisk vil du ikke have nogen tilføjelse af mennesker i årevis, da det ville betyde stagnation. Du skal dog passe på pludselige stigninger i aktivitetsmåneder, hvor flere mennesker forlod holdet, eller mange mennesker sluttede sig til. Hvis du pludselig har tilføjet mange nye deltagere, skal du være opmærksom på onboardingprocessen, før du går direkte til det projektrelaterede arbejde.

måling af fordele for slutbrugere

Agile teams skal vide, hvor godt produktet passer til en slutbrugers og virksomhedsejers behov. Dette gøres med en omfattende kodeanalyse, der bestemmer kodekvaliteten og dens anvendelighed for en endelig bruger samt mulige vedligeholdelseskomplikationer.

statisk kodeanalyse

det er den enkle type kodeanalyse, når programmet er inaktivt. Bare ved at overvåge kode automatisk med open source-værktøjer kan du identificere sikkerhedsproblemer, opdage teknisk gæld og fejl og sende problematiske kodefragmenter til affaldssamleren.

dynamisk kodeanalyse

dynamisk kodeanalyse kræver, at dit team kører programmer for at evaluere den oplevelse, som slutbrugerne modtager. Vi opfordrer vores udviklere og testere til altid at sætte sig i brugernes sko og udforske de mest almindelige scenarier. For eksempel kan de introducere deres kolleger og familiemedlemmer til løsningen og anmode om feedback — medmindre det ikke er forbudt i henhold til aftalen. Vigtigst er det, at vi har et team af kvalitetssikrede fagfolk, der er fuldt ansvarlige for dynamisk kodeanalyse — selvom vi mener, at jo flere mennesker bidrager til at teste målinger i Agile, jo bedre er den endelige produktkvalitet.

sådan anvendes de bedste Agile metrics

ud af alle de forskellige tilgængelige Agile metrics skal du vælge dem, der vil være relevante for dit team og projekter på lang sigt. At holde styr på disse nøgleegenskaber bør være en vane, mens det ikke bør distrahere dig fra mere presserende arbejde. Sådan indarbejdede vi problemfrit Agile metrics i vores arbejdsgang.

fokus på ydeevne, budget og kvalitet

du skal sørge for, at du, når du har valgt alle metrics, vil kunne få et klart billede af dit arbejde kvalitet, belastning, tid udgifter og budget. For det første opretter vi kortsigtede målinger, der vedrører vores aktive projekter: cyklustid og hastighed til smidig præstationsevaluering, kodeanalyse til kodekvalitetsvurdering og kumulativ strøm for at holde styr på alle udviklingsprocesser og deres omkostninger.

under den første sprint sørger vi for at gøre følgende:

• Definer, hvor mange sprints og cyklusser projektet vil have;
• anslå tidsudgifterne for hele projektet under hensyntagen til kundens behov;
• vurdering af konkurrencedygtige løsninger for at forstå niveauet af kompleksitet af det endelige produkt;
• Saml feedback fra vores teammedlemmer om deres forventninger til projektets mest spændende, udfordrende og vanskelige aspekter.

på denne måde kan vi vide, hvor meget tid vi vil bruge på at gennemføre projektet, sætte kvalitetsstandarder baseret på lignende løsninger, og om vores team er motiveret til at arbejde på opgaverne eller ej (det har en enorm indflydelse på produktiviteten).

Metrics efter den første sprint

her fokuserer vi på at få feedback fra klienten og alle teammedlemmer. Efter den første sprint vil vi vide, at alle parter, der er involveret i arbejdsgangen, forstår processen og føler sig godt tilpas. Vi lægger også vægt på evaluering af kodekvalitet-vi planlægger endda kodeanalyse og teknisk gældsevaluering som en del af hver af vores næste sprints. Så snart de første kodelinjer blev skrevet, er det vores prioritet at opretholde dens kvalitet.

Velocity kommer efter

Velocity er en af de vigtigste målinger i vores projekter, men ikke nøglen. Vi afholder os fra at basere vores vurdering på hastighedstal i de indledende faser. Strategien om hurtigt at komme igennem de første trin er en katastrofe, der venter på at ske — holdet springer måske over planlægningen eller glemmer at stille en klient flere vigtige spørgsmål. Vi skynder os ikke de første faser af produktet, så kunder og teammedlemmer finder deres tempo.

at øge vores teams hastighed bliver en af vores prioriteter, når vi er på udførelsesstedet. Så snart alle funktioner og design er lagt ud, stræber vi efter at minimere tidsudgifter og udføre alle opgaver så hurtigt som muligt.

individuelle metrics

hver af de anvendte metrics skal være tilgængelig for hele teamet og individuelle medlemmer. Udviklere, testere, designere skal kunne se tempoet og resultaterne af deres arbejde, ikke kun et team som helhed. For at få det til at ske bruger vi produktivitetsværktøjer og tidssporere, som Jira og Hubstaff. Alle generelle rapporter er synkroniseret med individuelle — medlemmer kan se, hvilken procentdel af den samlede produktive tid deres timer laver.

ofte stillede spørgsmål

Hvad er KPI i Agile?

Key Performance Indicators in Agile er målbare værdier, der viser teamets effektivitet i at nå forretningsmål. KPI ‘ er på højt niveau fokuserer på langsigtede resultater, der afhænger af mange faktorer-hvor mange brugere der blev tiltrukket af det endelige produkt, konverteringsfrekvenser, feedbackkvalitet. KPI ‘ er på lavt niveau er kortsigtede værdier, der ikke påvirkes af mange forbundne faktorer-tid brugt på projektet (normalt beregnet i timer), projektets budget (investering pr.opgave) osv.

Agile er en udviklingsmetode baseret på løbende forbedringer — programmeludvikling analyserer data og tilpasser sig dem. Holdet analyserer Agile KPI ‘ er på dets ydeevne og arbejdskvalitet og implementerer ændringer med det samme i den næste sprint.

Hvad er Sprint metrics?

Sprint-metrics er metrics, der evaluerer programudviklingsteamets leverancer og kontrollerer, hvor meget værdi der blev leveret til slutkunden ved udgangen af hver sprint . Denne værdi kan måles med en ny funktion, designforbedringer eller sletning af fejl.

det næste mål med sprint metrics er at måle teamets effektivitet i forretningsbetingelser — hvor hurtigt løsningen blev leveret til markedet, hvad er kundens feedback og konverteringsniveauerne. Endelig skal metrics vise udviklernes tilfredshed med deres projekt og med den retning holdet tager generelt.

Hvorfor er metrics vigtige for Agile projekter?

hele pointen med den Agile metode er, at udviklere altid kan foretage korrektioner i processen efter hver sprint. At have håndgribelige data, statistikker og grafer giver udviklere mulighed for at forstå, hvilke ændringer der skal foretages til næste sprint, og tillader evaluering af slutproduktets kvalitet — ellers ville det være let at blive fanget i tekniske og organisatoriske detaljer.

hvad er en sprint i Agile?

en sprint er en klart defineret periode med start-og slutdato, når holdet er sat til at udføre et bestemt antal opgaver. Sprints er grundlaget for Scrum, Agile og DevOps — hold deler deres arbejdsbyrde i mindre håndterbare bidder og sporer resultaterne af hver sprint. Hver af disse perioder behandles som et mini-projekt med en forudgående planlægning, risikovurdering, ansvarsopgaver og analyse efter sprint.

hvert projekt består af en række sprints. Fordi hver sprint evalueres, er det nemt at få øje på problemer tidligt og fjerne dem på den næste sprint — så arbejdsgangen er konstant optimeret.

hvad er metrics for programmeludvikling?

programmeludviklingsmålinger er kvantitative værdier, der gør det muligt at måle programmeludviklingsprojektets kvalitet, ydeevne og teamets sundhed. De hjælper med at forbedre udviklingsprocessen, når projektet bevæger sig fremad og kan bruges til teamets fremtidige arbejde med at forbedre organisering og planlægning.

der er seks hovedtyper af programmeludviklingsmålinger:

• formelle kodemetrikker – disse er objektive kvalitative værdier, der beregner, hvor meget arbejde der blev udført ved at bestemme antallet af kodelinjer (LOC), Instruktionsstiens længde og andre.
• udviklereffektivitetsmålinger — teamet kan beregne tildelingskode, aktive dage og tid brugt på opgaven.
• Agile process metrics — når projektet er opdelt i sprints, kan teamet måle effektiviteten af mindre dele af projektet – ledetid (hvor meget tid der blev brugt til et bestemt udviklingsstadium, som kan indeholde flere sprints), cyklustid (en sprint falder normalt under en enkelt cyklus) og hastighed (hvor mange opgaver der blev udført i en bestemt tidsramme).
• operationelle målinger — disse målinger kontrollerer programmets køreegenskaber og bestemmer, hvor effektivt virksomhedens personale er til at vedligeholde værktøjet uden hjælp fra tredjepart. Mean Time mellem fejl og Mean Time to Recover (MTTR) kontroller, hvordan programmet vil køre under naturlige omstændigheder, og hvor udstyret er det interne team til håndtering af belastningen.
• testmålinger — disse målinger vurderer kodedækningen — hvor meget kode der blev testet, antallet af fejl og procentdelen af teknisk gæld.
• kundetilfredshed — teamet får indsigt i slutbrugernes reaktioner på produktet ved at måle Net Promoter Score, Kundetilfredshedsscore og Kundeindsatsscore. Disse målinger vurderer henholdsvis, om brugerne vil anbefale produktet, og om de er tilfredse med resultatet.

Agile metrics er en del af programnetværk, og de kan bestå af andre kategorier, som du kan se fra vores guide.

hvad er SDLC-metrics?

SDLC er et programudviklingslivscyklus — et sæt faser, som en typisk teknologi gennemgår under dens undfangelse, udførelse og færdiggørelse. En gennemsnitlig SDLC består af følgende faser:

• evaluering af eksisterende systemer og definition af deres funktioner, fordele, problemer;
• definition af krav til den nye projektfunktionalitet, design, målgruppe osv.;
• design af systemet og skitsering af en typisk brugersti;
• udvikling af programmet, hvilket betyder at skrive kode, forberede udstyr og skabe funktioner;
• test af programmelydelse, funktionalitet, sikkerhed, interface osv.;
• implementering af programmet i dets naturlige miljø, hvor teknologien vil køre langsigtet;
• vedligeholdelse af systemet ved at opdatere koden, erstatte eller redigere visse fragmenter og fjerne fejl.

hvert trin i SLDC kan måles ved hjælp af følgende egenskaber.

• krav: holdet skal indsamle alle krav til projektet og evaluere implementeringen af hver af dem med hensyn til tid og penge;
• Programmelkvalitet: alle Agile kvalitetsmålinger kan bruges i udviklingsfasen af en SDLC;
• testtilfælde: teamet skal beregne antallet af udførte testaktiviteter, dets hastighed og den endelige kodedækning;
• mangler: for at måle effektiviteten af deres arbejde skal udviklere og testere være opmærksomme på det nøjagtige antal problemer, der opstår under udviklingen;
• opgaver: måling af brugt tid og opgave gør det muligt at evaluere, om alle teammedlemmer er produktive eller ej.

alle metrics, der er beskrevet i vores vejledning, kan bruges på forskellige stadier af Programudviklingens livscyklus. Projektet har det største behov for overvågning tættere på frigivelsen, fordi problemer kan hobe sig op, og det er let at gå glip af en kritisk defekt i produktet.

Hvad er gennemstrømning i Agile metrics?

det er metrikken, der beregner antallet af afsluttede historier pr. I Scrum kaldes en lignende metrisk sprinthastighed.

konklusion

Agile metrics skaber et solidt grundlag for at træffe informerede beslutninger gennem et udviklingsprojekt. Udviklere kan bruge disse indsigter til at øge deres effektivitet i de næste sprints og konstant forbedre kvaliteten af deres produkt. Det er dog værd at bemærke, at udviklingsmålinger ikke bør blive en absolut prioritet i programmeludviklingsprojektet. Udviklere bør først og fremmest stole på projektbehov og publikums præferencer.

hos Jelvi bruger vi en personlig tilgang til at anvende metrics på projektet. Først diskuterer vi projektets MVP med klienten, undersøger målgruppen, analyserer konkurrencedygtige løsninger og vælger først de målinger, der passer bedst til projektet. Vi stræber ikke efter at anvende hver enkelt KPI — i stedet vælger vi dem, der afspejler projektbehov mest.