vår erfarenhet av att använda de vanligaste Agile Metrics

vår erfarenhet av att använda de vanligaste Agile Metrics

använda Agile metrics för att mäta teamets produktivitet är den viktigaste delen av Agile filosofi. Teamchefer och alla medlemmar bör se konsekvenserna av sitt arbete och använda dessa data för att förbättra arbetsflödet och öka effektiviteten.

slutanvändare och kunder kan också dra nytta av användningen av smidiga projektmått som fokuserar på att utvärdera resultatet av produkten. Metrics tillåter scrum masters, utvecklare, designers och testare att mäta programmets prestanda och spåra om nuvarande och tidigare uppgifter gör produkten bättre.

i den här artikeln kommer vi att granska Agila mätvärden som är viktiga och dela vår erfarenhet av att tillämpa denna Agile metrics-instrumentpanel på ett verkligt projekt. Det visar sig att för att leda ett team framgångsrikt och leverera resultat behöver du inte bara veta vilka mätvärden som ska tillämpas utan hur man gör det — vi delar hur vi tänkte ut det.

typer av vanliga Agile metrics

klassificeringen av Agile metrics är inte i sten — det förändras alltid och omstruktureras. Ändå har vi genom åren sett ökningen av tre huvudtyper av agila mätvärden i olika Agila ramar.

1. Kanban — mätvärden-dessa mätvärden baseras på mätning av investerad tid (cykeltider) och levererade resultat (genomströmning) och deras förhållande.
2. Scrum metrics — metrics, som är inriktade på att planera och förstå arbetsflödet och visa hur mycket arbete som utfördes under en viss period;
3. Lean metrics — kontinuerlig mätning av produktionseffektivitet och produktkvalitet med teknisk bedömning genom att testa funktioner, kontrollera eventuella fel och förutse negativa effekter.

vi använder alla tre typer av mätvärden för att bedöma de viktigaste aspekterna av mjukvaruutvecklingsprocessen och resultaten: produktkvalitet, lagets produktivitet och hälsa.

Agile quality metrics

innan du börjar mäta lagets hastighet och effektivitet måste du veta om du i allmänhet rör dig i rätt riktning. Vad är användningen vid snabb leverans av alla utvecklingsuppgifter, om själva uppgifterna bildas på fel sätt? Prioriteten för varje mjukvaruutvecklingsteam och chef är att se till att alla aktiviteter är relaterade till att förbättra produkten — detta görs genom att mäta dess kvalitet och upptäcka negativa tendenser.

utrymda defekter

varje agilt projekt har sprints eller arbetscykler, i slutet av vilken en viss uppgift levereras. Efter att arbetet var klart måste lagets chef bedöma kvaliteten på turned-it-resultat. Alla ändringar, redigeringar och ofixerade buggar är flyktiga defekter — problem som utvecklare kunde ha fixat men inte gjorde. spela in deras exakta antal och natur för att veta vilka misstag som vanligtvis undviker utvecklarens ögon.

när du har gjort en rapport om escaped defects och samlat in konkret statistik måste du diskutera resultaten med ditt team. Se till att varje teammedlem vet vilka typer av fel laget vanligtvis missar. Om du har individuella förslag, diskutera dem med teammedlemmar en-mot-en.

misslyckade distributioner

om produkten distribuerades men inte släpptes eller misslyckades med att locka användare registreras detta som en misslyckad distribution. Ibland händer en misslyckad distribution med en av intressenternas beslut, eller affärsmodellen visar sig vara opålitlig. Oavsett orsaken till problemet måste du registrera alla misslyckade distributioner tillsammans med orsakerna till deras misslyckande.

innan du släpper en ny distribution kan teamet alltid titta på listan över tidigare misslyckade distributioner och undersöka om den här inte kan genomgå samma process. Att analysera orsakerna till misslyckandet av tidigare versioner gör det möjligt att undvika framtida problem.

Release Net Promoter Score (NPS)

Net Promoter Score är det mått som innebär att utvärdera användarnas reaktioner i kvantitativ (siffror, statistik, genomsnittliga betyg) och kvalitativ feedback (recensioner, direkt feedback, meddelanden, e-post, samtal). Efter att teamet samlat in och analyserat feedbacken föreslår varje teammedlem en poäng som utvärderar hur mycket användaren sannolikt kommer att rekommendera produkten (vanligtvis sätts poäng i gränser från 1 till 10).

Agile project management metrics

när du har en fullständig historia av tidigare misslyckanden och framgångar kan du analysera riktningen för alla nuvarande ofullständiga projekt och ge ut relevanta uppgifter med utgångspunkt i tidigare erfarenheter. När du har etablerat utvecklingsriktningen — ”vad ska man göra” av produkten, ”måste du bedöma lagets effektivitet-det är” hur mår vi ” – faktorn. Du kan använda Agila projektmått för att veta om teammedlemmar uppfyller dina förväntningar, förstår deras uppgifter, hanterar tidsfrister och om alla processer är samordnade och synkroniserade.

ledtid

ledtid är ett mått som gör det möjligt för lag att kontrollera hur mycket det tog för produktbackloggposten att komma fram i slutet av sprinten. Den kan användas för att spåra produkter på något utvecklingsstadium, uppgift för uppgift, eller bedöma den totala tidskostnader, från ideation att släppa. Det är en långsiktig mätvärden som utvecklare kan använda när de planerar sitt framtida arbete och beräknar priser.

var noga med att registrera ledtid för vart och ett av dina projekt. Det är bäst att behålla både större bildstatistik som täcker hela projektet och har organiserat sprint — mätvärden-så att du kan undersöka varje steg separat.

Cykeltid

Om ledtiden är bland långsiktiga teamprestanda, fokuserar cykeltiden på enskilda uppgifter. Detta mått utvärderar varaktigheten för en enda cykel, där en cykel tas av en uppgift, beräknar antalet cykler per projekt och mäter uppnådda resultat för slutanvändaren om produkten redan är betatestad eller släppt.

med cykeltid kan lag omedelbart se om en uppgift tar för mycket tid eller om vissa teammedlemmar inte levererar i sina ändar. Detta kortsiktiga mått gör Projektledning mycket enklare och hjälper till att snabbt hitta problem när de uppstår.

Sprint burndown

detta mått tillämpas både på kort och lång sikt. Chefer kan skapa sprint burndown Scrum rapporter i realtid för att spåra deras lags framsteg på det aktuella projektet-för detta måste de uppskatta det totala antalet sprintar och förutsäga sannolika tidskostnader. Det kan också användas på lång sikt-chefer kan analysera rapporter om tidigare projekt, precisera steg som misslyckades förväntade tidsramar, och analysera orsakerna till förseningar.

viktigast, sprint burndown gör det möjligt att spåra dynamiken i lagens arbetsflöde. Vissa medlemmar tenderar att arbeta långsammare i de första etapperna, medan andra brinner ut mot slutet av projektet. Med sprint burndowns kan teamledare upptäcka dessa tendenser, bestämma deras orsaker och hjälpa medlemmar med arbetsfördelning och tidshantering.

Epic & Release burndown

detta mått liknar Sprint Burndown — den enda viktiga skillnaden är att den fokuserar på lagets produktivitet före och efter utgivningen. Chefer kan lägga till nya krav och införliva uppgifter som bygger på slutanvändarnas feedback. Det är en förbättrad version av sprint burndown, eftersom den också innehåller uppgifter som ges efter lanseringen av projektet.

Velocity

detta mått utvärderar antalet slutförda berättelsepunkter under en viss period. Baserat på din historia kan du förutse tidskostnader för framtida historiapunkter. Minskningen av lagets hastighet på vissa sprintar kan peka på missförstånd bland lagmedlemmar eller angivna uppgifter som är svårare än tidigare förväntat.

ytterligare Agile metrics

Agile metrics hjälper teamet att känna till sitt projekt bättre och hålla reda på många viktiga aspekter av produktutvecklingen. Det finns också smidiga mätvärden för ledande befattningshavare som gör det möjligt att se den större bilden av utveckling och teamets välbefinnande. Enligt vår erfarenhet hjälper dessa ytterligare mätvärden att mäta alla aspekter av ditt arbete. Ändå definierade vi de viktigaste egenskaperna som berättar mest om slutprodukten och hjälper till att leverera ett helt komplett resultat.

kumulativt flöde

namnet på mätvärdet kommunicerar tydligt sitt syfte — att samla alla projektflöden och utvärdera dem i ett enda diagram. Att ha en sådan graf ger dig en storskalig vy-den kan skickas till projektintressenter som inte har tid att analysera mer detaljerade smidiga rapporter.

diagrammet beskriver vanligtvis följande processer:

• uppgifter i backlog: hur många uppgifter i backlog-teammedlemmar har under den angivna tidsramen;
• godkänt arbete: hur många uppgifter bland planerade slutfördes — teamchefen ser omedelbart skillnaderna mellan planerade och slutförda aktiviteter;
• Buffertuppgifter: allt arbete som väntar på godkännande definieras vara i en buffertzon;
• pågår: du måste utvärdera den aktuella arbetsbelastningen.

Code churn

detta mått visar trenderna för kodbasändringar före utgåvan. Churn-diagram visar hur mycket kod som lagts till, tagits bort eller ändrats en gång i taget. Vid tidiga sprintar kommer det att finnas många spikar och faller på grafen, eftersom koden fortfarande är instabil, men när projektet fortskrider bör kodkärngrafen bli stabil, utan drastiska upp-och nedgångar.

innan utgåvan ska churn få en nedgång — lägga till eller redigera kod innan själva utgåvan betyder att den inte kommer att genomgå tillräcklig testning. Sammantaget, när det finns en oegentlighet på de smidiga diagrammen, undersök orsakerna.

kontrolldiagram

ett kontrolldiagram är ett diagram där teamet kan se information om hur länge deras cykeltider är. Det ideala resultatet skulle få linjen på diagrammet stadigt att gå ner med tiden — det skulle innebära en ökning av lagets hastighet-mindre tid krävs per enda cykel. En annan viktig aspekt är konsekvens-cykeltiderna måste vara jämna oavsett typ av uppgift — det betyder att du har rätt arbetsfördelning.

hälsovärden

Programvaruutvecklingsteam måste fokusera på långsiktiga prioriteringar, som att hålla kommunikationen mellan medlemmarna smidig och kontrollera om alla är nöjda. Agile är en flexibel metod, vilket innebär att den kan anpassa sig till olika medlemmars intressen, så snart chefer vet vad de ska uppmärksamma. Så här får vi reda på om alla våra teammedlemmar är nöjda med arbetsflödet.

lycka

om du har betrodda, informella relationer i ditt team är det lättare att börja med en öppen dialog med varje medlem. Be alla att betygsätta sin erfarenhet i företaget från 1 till 5. Du kan ställa hjälpfrågor-vilka är de bästa och värsta aspekterna av deras arbete, vad kan förbättras och vad kan öka lyckan? Om teamet inte har vänliga kommunikationsvanor kan anonyma undersökningar leda till mer objektiva resultat.

lagmoral

lagmoral och lycka är inte samma saker. Lycka har mer att göra med komfort, medan lagmoralen är knuten till produktivitet, självkänsla, utvärdering av egna yrkeskvaliteter. Återigen kan du be anställda att betygsätta sin moral från 1 till 5 och ställa följande frågor;

• har arbetet i företaget hjälpt till att förbättra dina färdigheter?
• hur mycket är din fulla potential utforskad med den nuvarande arbetsbelastningen?
• tycker du om ditt arbete?
• ser du de tydliga resultaten av ditt arbete?
• är du entusiastisk över nya projekt?

målet här är att förstå att lagets utvecklingsström går i rätt riktning. Ibland tar mjukvaruutvecklingsteamets chef lönsamma men tråkiga uppgifter och ignorerar medlemmarnas intressen. Denna undersökning hjälper dig att se om anställda är glada och utmanade av sitt arbete.

teammedlemsomsättning

om lagledare ofta ersätter teammedlemmar betyder det att arbetsmiljön sannolikt är ohälsosam. En viss omsättningshastighet över tiden är hälsosam-i själva verket vill du inte ha något tillägg av människor i flera år, eftersom det skulle innebära stagnation. Du bör dock se upp för plötsliga spikar i aktivitet-månader när flera personer lämnade laget, eller många gick med. Om du plötsligt lägger till många nya deltagare måste du vara uppmärksam på onboardingprocessen innan du går direkt till det projektrelaterade arbetet.

mäta fördelar för slutanvändare

agila team bör veta hur väl produkten passar behoven hos en slutanvändare och företagsägare. Detta görs med en omfattande kodanalys som bestämmer kodkvaliteten och dess användbarhet för en slutanvändare, samt möjliga underhållskomplikationer.

statisk kodanalys

det är den enkla typen av kodanalys när programvaran är inaktiv. Bara genom att övervaka kod automatiskt med öppen källkodsverktyg kan du identifiera säkerhetsproblem, upptäcka teknisk skuld och buggar och skicka problematiska kodfragment till sophämtaren.

dynamisk kodanalys

dynamisk kodanalys kräver att ditt team kör programvara för att utvärdera upplevelsen som slutanvändarna får. Vi uppmuntrar våra utvecklare och testare att alltid sätta sig i användarnas skor och utforska de vanligaste scenarierna. De kan till exempel introducera sina kollegor och familjemedlemmar till lösningen och begära feedback — såvida det inte är förbjudet enligt avtalet. Viktigast av allt har vi ett team av QA — proffs som är fullt ansvariga för dynamisk kodanalys-även om vi tror att ju fler människor bidrar till att testa mätvärden i Agile, desto bättre är slutproduktens kvalitet.

hur man tillämpar de bästa Agila mätvärdena

av alla olika tillgängliga Agila mätvärden måste du välja de som är relevanta för ditt team och projekt på lång sikt. Att hålla reda på dessa viktiga egenskaper bör vara en vana, medan det inte borde distrahera dig från mer brådskande arbete. Så här införlivade vi smidigt Agila mätvärden i vårt arbetsflöde.

fokusera på prestanda, budget och kvalitet

du måste se till att du, efter att ha valt alla mätvärden, kommer att kunna få en tydlig bild av ditt arbete kvalitet, belastning, tidskostnader och budget. För det första sätter vi upp kortsiktiga mätvärden som relaterar till våra aktiva projekt: cykeltid och hastighet för agil prestandautvärdering, kodanalys för kodkvalitetsbedömning och kumulativt flöde för att hålla reda på alla utvecklingsprocesser och deras kostnader.

under den första sprinten ser vi till att göra följande:

• definiera hur många sprints och cykler kommer projektet att ha;
• uppskatta tidskostnaderna för hela projektet, med hänsyn till kundens behov;
• bedöma konkurrenskraftiga lösningar för att förstå slutproduktens komplexitet;
• samla feedback från våra teammedlemmar om deras förväntningar på projektets mest spännande, utmanande och svåra aspekter.

på så sätt kan vi veta hur mycket tid vi kommer att spendera för att slutföra projektet, sätta kvalitetsstandarder baserade på liknande lösningar och om vårt team är motiverat att arbeta med uppgifterna eller inte (det har en enorm inverkan på produktiviteten).

Metrics efter den första sprinten

här fokuserar vi på att få feedback från kunden och alla teammedlemmar. Efter den första sprinten vill vi veta att alla parter som är involverade i arbetsflödet förstår processen och känner sig bekväma. Vi betonar också att utvärdera kodkvalitet – vi planerar även kodanalys och teknisk skuldutvärdering som en del av var och en av våra nästa sprints. Så snart de första kodraderna skrevs, är det vår prioritet att behålla dess kvalitet.

hastighet kommer efter

hastighet är en av de viktigaste mätvärdena i våra projekt, men inte den viktigaste. Vi avstår från att basera vår bedömning på hastighetsnummer i början. Strategin att snabbt komma igenom de första stegen är en katastrof som väntar på att hända-teamet kan hoppa över planeringen eller glömma att ställa en klient flera viktiga frågor. Vi rusar inte de första stadierna av produkten, så att kunder och teammedlemmar hittar sin takt.

att öka vårt lags hastighet blir en av våra prioriteringar när vi befinner oss vid genomförandepunkten. Så snart alla funktioner och design läggs ut strävar vi efter att minimera tidskostnader och slutföra alla uppgifter så snabbt som möjligt.

individuella mätvärden

var och en av de använda mätvärdena bör vara tillgängliga för hela teamet och enskilda medlemmar. Utvecklare, testare, designers ska kunna se takten och resultaten av sitt arbete, inte bara ett team som helhet. För att få det att hända använder vi produktivitetsverktyg och tidsspårare, som Jira och Hubstaff. Alla allmänna rapporter synkroniseras med enskilda — medlemmar kan se vilken procentandel av den totala produktiva tiden deras timmar gör.

Vanliga frågor

Vad är KPI i Agile?

viktiga resultatindikatorer i Agile är mätbara värden som visar teamets effektivitet när det gäller att uppnå affärsmål. KPI: er på hög nivå fokuserar på långsiktiga resultat som beror på många faktorer-hur många användare lockades av slutprodukten, omvandlingsfrekvenser, feedbackkvalitet. Nyckeltal på låg nivå är kortsiktiga värden som inte påverkas av många kopplade faktorer — tid som spenderas på projektet (vanligtvis beräknat i timmar), projektets budget (investering per uppgift) etc.

Agile är en utvecklingsmetodik baserad på kontinuerlig förbättring — mjukvaruutveckling analyserar data och anpassar sig till den. Teamet analyserar smidiga KPI: er på prestanda och arbetskvalitet och genomför förändringar direkt i nästa sprint.

Vad är Sprint metrics?

Sprint metrics är mätvärden som utvärderar resultaten från mjukvaruutvecklingsteamet och kontrollerar hur mycket värde som levererades till slutkunden i slutet av varje sprint . Detta värde kan mätas med en ny funktion, designförbättringar eller borttagning av fel.

nästa mål med sprint metrics är att mäta teamets effektivitet i affärsmässiga termer — hur snabbt lösningen levererades till marknaden, vad är kundens feedback och konverteringsnivåerna. Slutligen måste mätvärden visa utvecklarens tillfredsställelse med sitt projekt och med den riktning laget tar i allmänhet.

Varför är mätvärden viktiga för agila projekt?

hela poängen med den smidiga metoden är att utvecklare alltid kan göra korrigeringar i processen efter varje sprint. Att ha konkreta data, statistik och grafer gör det möjligt för utvecklare att förstå vilka förändringar som ska göras för nästa sprint och gör det möjligt att utvärdera slutproduktens kvalitet — annars skulle det vara lätt att fastna i tekniska och organisatoriska detaljer.

vad är en sprint i Agile?

en sprint är en tydligt definierad period med start-och slutdatum när laget är inställt för att slutföra ett visst antal uppgifter. Sprints är grunden för Scrum, Agile och DevOps — Team delar upp sin arbetsbelastning i mindre hanterbara bitar och spårar resultaten för varje sprint. Var och en av dessa perioder behandlas som ett miniprojekt med en planering i förväg, riskbedömning, ansvarsuppgifter och analys efter sprint.

varje projekt består av en serie sprintar. Eftersom varje sprint utvärderas är det enkelt att upptäcka problem tidigt och ta bort dem på nästa sprint — så arbetsflödet optimeras ständigt.

vilka är mätvärdena för mjukvaruutveckling?

mätvärden för mjukvaruutveckling är kvantitativa värden som gör det möjligt att mäta mjukvaruutvecklingsprojektets kvalitet, prestanda och lagets hälsa. De bidrar till att förbättra utvecklingsprocessen när projektet rör sig och kan användas för teamets framtida arbete för att förbättra organisation och planering.

det finns sex huvudtyper av mjukvaruutveckling metrics:

• formella kodmätningar – det här är objektiva kvalitativa värden som beräknar hur mycket arbete som utfördes genom att bestämma antalet kodrader (LOC), Instruktionsbanans längd och andra.
• Developer efficiency metrics — teamet kan beräkna tilldelningskod, aktiva dagar och tid som spenderas på uppgiften.
• Agile process metrics — när projektet är uppdelat i sprintar kan teamet mäta effektiviteten hos mindre delar av projektet – ledtid (hur mycket tid som spenderades för ett visst utvecklingsstadium, som kan innehålla flera sprintar), cykeltid (en sprint faller vanligtvis under en enda cykel) och hastighet (hur många uppgifter som gjordes inom en viss tidsram).
• operativa mätvärden — dessa mätvärden kontrollerar programvarukörningsegenskaperna och bestämmer hur effektiv företagets personal är för att underhålla verktyget utan hjälp från tredje part. Mean Time Between Failures and Mean Time to Recover (MTTR) kontrollera hur programvaran kommer att köras under naturliga omständigheter och hur utrustad är det interna teamet för att hantera lasten.
• Test metrics — dessa mätvärden utvärderar kodtäckningen — hur mycket kod testades, antalet buggar och andelen teknisk skuld.
• kundnöjdhet — teamet får insikter om slutanvändarnas reaktioner på produkten genom att mäta Net Promoter Score, Customer Satisfaction Score och Customer Effort Score. Dessa mätvärden utvärderar om användarna skulle rekommendera produkten och om de är nöjda med resultatet.

Agile metrics är en del av mjukvarunätverk, och de kan bestå av andra kategorier, som du kan märka från vår guide.

vad är SDLC-mätvärden?

SDLC är en livscykel för mjukvaruutveckling — en uppsättning steg som en typisk teknik genomgår under dess utformning, utförande och slutförande. En genomsnittlig SDLC består av följande steg:

• utvärdera befintliga system och definiera deras egenskaper, fördelar, problem;
• definiera krav för det nya projektet funktionalitet, design, målgrupp, etc.;
• designa systemet och skissera en typisk användarväg;
• utveckla programvaran, vilket innebär att skriva kod, förbereda hårdvara och skapa funktioner;
• testa programvara prestanda, funktionalitet, säkerhet, gränssnitt, etc.;
• distribuera Programvaran i sin naturliga miljö, där tekniken kommer att köras på lång sikt;
• underhålla systemet genom att uppdatera koden, ersätta eller redigera vissa fragment och ta bort buggar.

varje steg i SLDC kan mätas med följande egenskaper.

• krav: teamet måste samla alla krav för projektet och utvärdera genomförandet av var och en av dem när det gäller tid och pengar;
• programkvalitet: alla Agila kvalitetsmått kan användas i utvecklingsstadiet för en SDLC;
• testfall: teamet måste beräkna antalet utförda testaktiviteter, dess hastighet och slutliga kodtäckning;
• defekter: för att mäta effektiviteten i sitt arbete måste utvecklare och testare vara medvetna om det exakta antalet problem som uppstår under utvecklingen;
• uppgifter: att mäta tid som spenderas på och pengar som tjänas per uppgift gör det möjligt att utvärdera om alla teammedlemmar är produktiva eller inte.

alla mätvärden, som beskrivs i vår guide, kan användas i olika stadier av mjukvaruutvecklingens livscykel. Projektet har det högsta behovet av övervakning närmare utgåvan eftersom problem kan staplas upp och det är lätt att missa en kritisk defekt i produkten.

Vad är genomströmning i Agile metrics?

det är mätvärdet som beräknar antalet berättelser som slutförts per sprint. I Scrum kallas en liknande metrisk sprinthastighet.

slutsats

Agila mätvärden skapar en solid bas för att fatta välgrundade beslut under ett mjukvaruutvecklingsprojekt. Utvecklare kan använda dessa insikter för att öka effektiviteten i nästa sprint och ständigt förbättra kvaliteten på sin produkt. Det är dock värt att notera att utvecklingsmått inte bör bli en absolut prioritet i mjukvaruutvecklingsprojektet. Utvecklare bör först och främst förlita sig på projektbehov och publikpreferenser.

på Jelvix använder vi ett personligt tillvägagångssätt för att tillämpa mätvärden på projektet. Först diskuterar vi projektets MVP med kunden, undersöker målgruppen, analyserar konkurrenskraftiga lösningar och väljer först de mätvärden som passar projektet bäst. Vi strävar inte efter att tillämpa varje enskild KPI — istället väljer vi de som speglar projektets behov mest.