Produktivitetsmålinger. Hva du trenger å vite om ytelsesmåling i programvare?

Selv om praktiske ferdigheter og kunnskap om spesifikke programmeringsspråk, verktøy og teknologier er nøkkelen til å få en heltidsjobb som programvareutvikler, er det en annen verdifull indikator som på mange måter kan sees på som en forutsetning for suksess i dette yrket: produktivitet. Produktivitetsmåling er noe alle profesjonelle programvareutviklere trenger å forstå og ta i betraktning, da ytelsesmålinger er iboende viktige for ethvert programvareutviklingsteam i dagens forretningsmiljø.

Hvorfor er produktiviteten din som utvikler viktig?

I en tid med smidig utvikling, DevOps og krympende programvareutgivelsessykluser, når utviklere trenger å sende nye versjoner av produkter så raskt som mulig, bruker bedrifter flere forskjellige produktivitetsmålinger for å evaluere ytelsen til individuelle programmerere og et team som helhet. Ser vi på dette fra en utviklers synspunkt, kan ytelsesmåling tjene en rekke verdifulle formål, og hjelpe deg med å spore fremdriften til dine programmeringsferdigheter, noe som vil tillate deg å oppnå konsekvent profesjonell vekst. Svært produktive kodere er de som ender opp med å motta overveldende lønnstilbud og får jobbe med de mest spennende prosjektene. Men selv om du ikke akkurat er en høypresterende person og bare vil ha hvilken som helst jobb innen programvareutvikling og være rimelig vellykket i det, du må fortsatt ha minst en grunnleggende forståelse av ytelsesindikatorer og hvordan de brukes til å måle produktiviteten til innsatsen din på jobben. Det er det vi skal snakke om i dag.

Produktivitetsmålinger for programvareutvikling

Hva er produktivitetsberegninger for programvareutvikling?

Programvareutviklingsmålinger er områdene for programmeringsarbeid der kvantitative målinger kan brukes for å spore ytelsen, kvaliteten på arbeidet og produktiviteten til en utvikler. Hver produktivitetsmåling er basert på å ta data fra utviklingsprosessen og bruke den til å måle produktivitet. Siden stort sett ingenting relatert til programvareutvikling er enkelt og greit, kan du si at måling av programmeringsproduktivitet også er ganske inkonsekvent og fragmentert på tvers av bransjen. Eller rett og slett, ulike team og selskaper kan bruke helt forskjellige resultatindikatorer og nærme seg dette problemet fra en rekke vinkler. Så du trenger ikke å bry deg med å lære hver eneste beregning som kan brukes av programvareutviklingsteam.

Hvilke typer produktivitetsmål for programvareutvikling finnes det?

Naturligvis er det flere forskjellige produktivitetsmålinger som nærmer seg måling av ytelse på forskjellige nivåer og vinkler. Her er de vanligste typene av slike produktivitetsmålinger:

• Formelle størrelsesfokuserte beregninger.

Disse beregningene er fokusert på å måle størrelsen på en programmerers arbeidsresultat, for eksempel kodelinjer (LOC), kodeinstruksjonslengde, kodekompleksitet osv. Disse beregningene anses i økende grad for å være utdaterte i dagens programvareutviklingsindustri.

• Tids- og funksjonsfokuserte produktivitetsmålinger.

Det er et utvalg av tradisjonelle produktivitetsmålinger som brukes i utvikling av fosseprogramvare, for eksempel aktive dager, omfanget av funksjonalitet som sendes i en bestemt tidsperiode, kodeavgang, antall oppgaver som er tildelt, etc.

• Agile utviklingsprosessberegninger.

Agile utviklingsprosess-beregninger, som sprint-utbrenningsrapport, hastighet, ledetid, syklustid og andre, er sannsynligvis de mest brukte beregningene blant programvareutviklingsteam i dag. Vi vil snakke om smidige beregninger mer detaljert senere i artikkelen.

• Beregninger for operasjonell analyse.

Dette settet med beregninger er fokusert på å måle programvareytelse i det nåværende produksjonsmiljøet. Gjennomsnittlig tid mellom feil (MTBF), gjennomsnittlig tid til gjenoppretting (MTTR) og programkrasjfrekvens er de mest brukte beregningene her.

• Testing av beregninger.

Programvaretesting har sitt eget sett med beregninger for å måle kvaliteten på systemtesting, for eksempel prosentandel av automatiserte tester, kodedekning, etc.

• Kundetilfredshetsmålinger.

Til slutt, den ultimate beregningen for ethvert stykke programvare er sluttkundeopplevelsen, og det er et helt sett med beregninger for det også, for eksempel kundeinnsatsscore (CES), kundetilfredshetsscore (CSAT), netto promoterscore (NPS) og andre.

Agile programvareutviklingsmålinger

Som du kan se, er det ganske lett å gå seg vill i alle vanskelighetene med programvareproduktivitetsmålinger. De eneste en vanlig programvareutvikler bør imidlertid være godt kjent med, er Agile-målingene, som vanligvis brukes av programvareutviklingsteam i dag som standarder for teamproduktivitetsmåling på tvers av ulike deler av programvareutviklingens livssyklus. La oss liste opp de viktigste og mest brukte Agile-beregningene.

1. Sprint Burndown.

Sprint Burndown-rapporter er en av nøkkelberegningene for smidige scrum-utviklingsteam. Ettersom i smidig utviklingsprosessen er organisert gjennom tidsbestemte sprints, brukes Sprint Burndown som en måte å spore fullføringen av oppgaver under en sprint. Timer eller historiepunkter brukes som en måleenhet. Målet er å oppnå jevn fremgang og levere arbeid i tråd med innledende anslag. Sprint Burndown hjelper team med å måle arbeidstempoet og justere det ved behov.

2. Team Velocity.

Hastighet er en annen nøkkelindikator, som også er basert på timer eller historiepunkter som en måleenhet. Den måler den gjennomsnittlige mengden arbeid et team fullfører i løpet av en sprint og brukes til estimering og planlegging gjennom hele prosjektet. Sporingshastighet er viktig for å sikre at teamet leverer konsekvent ytelse.

3. Historiepoeng.

På nivået til et individuelt utviklingsteammedlem er historiepoeng en verdifull beregning, ettersom størrelsen på historiene en programmerer leverer under hver utgivelse er en indikator på denne koderens produktivitet.

4. Sykluskontrolldiagram.

Måler den totale tiden fra det øyeblikket arbeidet med en oppgave eller en annen etterslep har startet til den er fullført. Gjør det mulig å spore og kontrollere syklustider og levere mer forutsigbare resultater.

5. Gjennomstrømning og verdi levert.

Prosjektledere analyserer oppgaver tildelt utviklere og tildeler verdi til dem. Denne beregningen brukes deretter til å måle gjennomstrømningen til teamet eller, med andre ord, mengden verdiøkende arbeid som er utført.

6. Kode Churn.

Code churn er en annen beregning som er verdt å nevne ettersom den brukes til å måle både produktiviteten til et team som helhet og for å spore ytelsen til individuelle programmerere. Code churn måler hvor ofte en utvikler fjerner eller gjør endringer i tidligere lagt til linjer med kode, og hvor stor prosentandel av tidligere skrevet kode som ender opp med å endres eller kastes.

Ekspertuttalelser

Til slutt, for å legge til litt perspektiv, noen få sitater om saken av erfarne fagfolk innen programvareutvikling. "Jeg håper du ikke er ute etter å "sammenligne" beregningene dine med en slags standard eller til og med med ytelsen til et annet team i et annet selskap. Overalt hvor jeg har jobbet har det hatt unike variasjoner i deres definisjoner av historiepoeng, hastighet, timeanslag, oppgaver osv. som virkelig ville gjort det nesten umulig å sammenligne ytelsen til ett team fra ett selskap direkte med det til et annet team i et annet. selskapet," bemerket Cliff Gilley, tidligere teknisk produktsjef og smidig coach. «Jeg er litt usikker på beregninger når det kommer til å veilede teamprestasjoner. Når du først tar hensyn til bare én eller to variabler, blir det veldig lett å falle inn i (med vilje eller på annen måte) å spille metrikken og lure deg selv at du forbedrer - når alt du gjør er å forbedre metrikken. For eksempel kan beregninger basert på hastighet "forbedre" ved at teamet flytter til mindre historier (mindre arbeid per historie - så flere historier fullført - så hastigheten går opp). Det kan være en god ting hvis historiene er nyttige brukerhistorier som gir mindre økninger av forretningsverdi. Det kan være en dårlig ting hvis historiene blir mindre og mer "tekniske" oppgaver som ikke gir reell verdi alene, sa Adrian Howard, en annen bransjeprofesjonell.. «Når jeg jobber i et pull-basert system, verdsetter jeg gjennomstrømning og syklustid. Den første gir meg generell informasjon om teamets kapasitet, og kan over tid bli et veldig kraftig prediktivt mål. Den andre er nyttig som en generell målestokk for rørledningens effektivitet. Hvis syklustiden er høy, er det på tide å begynne å se på rørledningen, fordi det er en begrensning som vi sannsynligvis kan jobbe mot å lette/utnytte. Men beregninger er bare verktøy. Ikke gå deg vill i dem, og absolutt ikke begynn å planlegge mot en bestemt beregning. Tenk på hva du lager som et team og hvordan du naturlig jobber, og bygg deretter systemet rundt menneskene. Beregningene skal hjelpe deg å se hvordan systemet ditt støtter alles arbeid. Eller ikke,» konkluderte Dave Cerra, en produsent av videospillutvikling .