Även om praktiska färdigheter och kunskaper om specifika programmeringsspråk, verktyg och teknologier är nyckeln till att få ett heltidsjobb som mjukvaruutvecklare, finns det ytterligare en värdefull indikator som på många sätt kan ses som en förutsättning för framgång i detta yrke: produktivitet. Produktivitetsmätning är något som alla professionella mjukvaruutvecklare behöver förstå och ta hänsyn till eftersom prestandamått är i sig viktiga för alla mjukvaruutvecklingsteam i dagens affärsmiljö.
Varför spelar din produktivitet som utvecklare roll?
I en tid präglad av agil utveckling, DevOps och krympande programutgivningscykler, när utvecklare behöver leverera nya versioner av produkter så snabbt som möjligt, använder företag flera olika produktivitetsmått för att utvärdera prestanda hos enskilda programmerare och ett team som helhet. Om man ser på detta ur en utvecklares synvinkel kan prestationsmätning tjäna ett antal värdefulla syften, hjälpa dig att spåra framstegen för dina programmeringsfärdigheter, vilket skulle göra det möjligt för dig att uppnå konsekvent professionell tillväxt. Högproduktiva kodare är de som i slutändan får häpnadsväckande löneerbjudanden och får arbeta med de mest spännande projekten. Men även om du inte precis är en högpresterande och bara vill ha vilket jobb som helst inom mjukvaruutveckling och bli någorlunda framgångsrik i det, du måste fortfarande ha åtminstone en grundläggande förståelse för prestationsindikatorer och hur de används för att mäta produktiviteten för din insats på jobbet. Vilket är vad vi ska prata om idag.
Mjukvaruutveckling produktivitetsmätningsmått
Vad är produktivitetsmått för mjukvaruutveckling?
Mjukvaruutvecklingsmått är de områden av programmeringsarbete där kvantitativa mätningar kan användas för att spåra prestanda, arbetskvalitet och produktivitet hos en utvecklare. Varje produktivitetsmått bygger på att ta data från utvecklingsprocessen och använda den för att mäta produktivitet. Eftersom i stort sett ingenting relaterat till mjukvaruutveckling är enkelt och okomplicerat, kan man säga att mätning av programmeringsproduktivitet också är ganska inkonsekvent och fragmenterat över hela branschen. Eller, enkelt uttryckt, olika team och företag kan använda helt olika resultatindikatorer och närma sig denna fråga från ett antal vinklar. Så du behöver inte bry dig om att lära dig varje mätvärde som kan användas av mjukvaruutvecklingsteam.
Vilka typer av produktivitetsmått för mjukvaruutveckling finns det?
Naturligtvis finns det flera olika produktivitetsmått som närmar sig att mäta prestanda på olika nivåer och vinklar. Här är de vanligaste typerna av sådana produktivitetsmått:
Formella storleksfokuserade mätvärden.
Dessa mätvärden är fokuserade på att mäta storleken på en programmerares arbetsresultat, såsom rader med kod (LOC), kodinstruktionslängd, kodkomplexitet, etc. Dessa mätvärden anses alltmer vara föråldrade i dagens mjukvaruutvecklingsindustri.
Tids- och funktionsfokuserade produktivitetsmått.
Det finns ett urval av traditionella produktivitetsmått som används i utvecklingen av mjukvara för vattenfall, såsom aktiva dagar, omfattningen av funktionalitet som levereras under en viss tidsperiod, kodavgångshastigheter, antal tilldelade uppgifter, etc.
Agila utvecklingsprocessmått.
Agila utvecklingsprocessmått, såsom sprint burndown-rapport, hastighet, ledtid, cykeltid och andra, är förmodligen de mest använda måtten bland mjukvaruutvecklingsteam idag. Vi kommer att prata om Agila mätvärden mer i detalj senare i artikeln.
Operativa analyser.
Denna uppsättning mätvärden är fokuserad på att mäta mjukvarans prestanda i sin nuvarande produktionsmiljö. Medeltid mellan fel (MTBF), medeltid för återställning (MTTR) och programkraschfrekvens är de mest använda måtten här.
Testa mätvärden.
Programvarutestning har sin egen uppsättning mätvärden för att mäta kvaliteten på systemtestning, såsom procentandel av automatiserade tester, kodtäckning, etc.
Kundnöjdhetsmått.
Slutligen, det ultimata måttet för varje mjukvara är slutkundsupplevelsen, och det finns en hel uppsättning mätvärden för det också, som kundansträngningspoäng (CES), kundnöjdhetspoäng (CSAT), nettopromotorpoäng (NPS) och andra.
Agila mätvärden för mjukvaruutveckling
Som du kan se är det ganska lätt att gå vilse i alla krångligheterna med mjukvaruproduktivitetsmått. De enda som en vanlig mjukvaruutvecklare bör vara väl förtrogen med är dock Agile-måtten, som vanligtvis används av mjukvaruutvecklingsteam idag som standarder för teamproduktivitetsmätning över olika delar av mjukvaruutvecklingens livscykel. Låt oss lista de viktigaste och mest använda agila mätvärdena.
1. Sprint Burndown.
Sprint Burndown-rapporter är ett av nyckelmåtten för agila scrumutvecklingsteam. Eftersom i agile är utvecklingsprocessen organiserad genom tidsbundna sprints, används Sprint Burndown som ett sätt att spåra slutförandet av uppgifter under en sprint. Timmar eller berättelsepunkter används som en måttenhet. Målet är att uppnå konsekventa framsteg och leverera arbete i linje med initiala prognoser. Sprint Burndown hjälper team att mäta arbetstakten och justera den vid behov.
2. Team Velocity.
Hastighet är en annan nyckelindikator, som också är baserad på timmar eller berättelsepunkter som en måttenhet. Den mäter den genomsnittliga mängden arbete som ett team slutför under en sprint och används för uppskattning och planering genom hela projektet. Spårningshastighet är viktig för att se till att teamet levererar konsekvent prestanda.
3. Berättelsepoäng.
På en individuell utvecklingsteammedlems nivå är storypoäng ett värdefullt mått, eftersom storleken på berättelserna en programmerare levererar under varje release är en indikator på denna kodares produktivitet.
4. Cykelkontrollschema.
Mäter den totala tiden från det att arbetet med en uppgift eller ett annat eftersläpningsobjekt har påbörjats till dess att det är slutfört. Gör det möjligt att spåra och kontrollera cykeltider och leverera mer förutsägbara resultat.
5. Genomströmning och levererat värde.
Projektledare analyserar uppgifter som tilldelats utvecklare och tilldelar dem värde. Detta mått används sedan för att mäta teamets genomströmning eller, med andra ord, mängden mervärdesarbete som gjorts.
6. Code Churn.
Code churn är ett annat mått som är värt att nämna eftersom det används för att mäta både produktiviteten för ett team som helhet och för att spåra prestanda hos enskilda programmerare. Code churn mäter hur ofta en utvecklare tar bort eller gör ändringar i tidigare tillagda kodrader, och hur stor andel av tidigare skriven kod som ändras eller slängs.
Expertutlåtanden
Slutligen, för att lägga till lite perspektiv, några citat i frågan från erfarna mjukvaruutvecklingspersonal. "Jag hoppas verkligen att du inte vill "jämföra" dina mätvärden med någon typ av standard eller ens med resultatet för ett annat team i ett annat företag. Överallt där jag har arbetat har det haft unika variationer i deras definitioner av berättelsepoäng, hastighet, timuppskattningar, uppgifter, etc. som verkligen skulle göra det nästan omöjligt att jämföra resultatet för ett team från ett företag direkt med det för ett annat team på ett annat. företag”, konstaterade Cliff Gilley, tidigare teknisk produktchef och Agile Coach. "Jag är lite tveksam till mätvärden när det gäller att vägleda teamprestationer. När du väl är uppmärksam på bara en eller två variabler blir det väldigt lätt att falla in i (avsiktligt eller på annat sätt) att spela måttet och lura dig själv att du förbättrar - när allt du gör är att förbättra måttet. Till exempel kan mätvärden baserade på hastighet "förbättras" genom att teamet flyttar till mindre berättelser (mindre arbete per berättelse - så fler berättelser slutförda - så hastigheten går upp). Det kan vara bra om berättelserna är användbara användarberättelser som ger mindre ökningar av affärsvärde. Det kan vara en dålig sak om berättelserna blir mindre och mer "tekniska" uppgifter som inte ger verkligt värde i sig själva, säger Adrian Howard, en annan branschprofessionell.. ”När jag arbetar i ett pull-baserat system värdesätter jag genomströmning och cykeltid. Den första ger mig allmän information om vårt teams kapacitet, och kan med tiden bli ett mycket kraftfullt prediktivt mått. Den andra är användbar som en allmän mätare av våra pipelines effektivitet. Om cykeltiden är hög är det dags att börja titta på pipelinen, eftersom det finns en begränsning som vi förmodligen kan arbeta för att underlätta/utnyttja. Men mätvärden är bara verktyg. Gå inte vilse i dem, och börja absolut inte planera mot ett specifikt mått. Tänk på vad du gör som ett team och hur du naturligt arbetar, bygg sedan systemet runt människorna. Mätvärdena bör hjälpa dig att se hur ditt system stödjer allas arbete. Eller inte”, avslutade Dave Cerra, en producent av videospelsutveckling .
GO TO FULL VERSION