Produktivitetsmålinger. Hvad du behøver at vide om præstationsmåling i software?

Selvom praktiske færdigheder og viden om specifikke programmeringssprog, værktøjer og teknologier er nøglen til at få et fuldtidsjob som softwareudvikler, er der en anden værdifuld indikator, som på mange måder kan ses som en forudsætning for succes i dette fag: produktivitet. Produktivitetsmåling er noget, som alle professionelle softwareudviklere skal forstå og tage i betragtning, da præstationsmålinger i sagens natur er vigtige for ethvert softwareudviklingsteam i dagens forretningsmiljø.

Hvorfor betyder din produktivitet som udvikler noget?

I en æra med agil udvikling, DevOps og krympende softwareudgivelsescyklusser, når udviklere skal sende nye versioner af produkter så hurtigt som muligt, bruger virksomheder flere forskellige produktivitetsmålinger til at evaluere individuelle programmørers og et team som helhed. Ser man på dette fra en udviklers synspunkt, kan præstationsmåling tjene en række værdifulde formål, der hjælper dig med at spore fremskridtene for dine programmeringsevner, hvilket vil give dig mulighed for at opnå konsekvent professionel vækst. Meget produktive kodere er dem, der ender med at modtage forbløffende løntilbud og kommer i gang med de mest spændende projekter. Men selvom du ikke ligefrem er en høj præstation og bare vil have et hvilket som helst job inden for softwareudvikling og have nogenlunde succes med det, du skal stadig have mindst en grundlæggende forståelse af præstationsindikatorer og hvordan de bruges til at måle produktiviteten af ​​dine input på arbejdet. Det er det, vi skal tale om i dag.

Softwareudviklings produktivitetsmålinger

Hvad er softwareudviklingsproduktivitetsmålinger?

Softwareudviklingsmålinger er de områder af programmeringsarbejde, hvor kvantitative målinger kan anvendes for at spore en udviklers ydeevne, kvalitet og produktivitet. Hver produktivitetsmåling er baseret på at tage data fra udviklingsprocessen og bruge dem til at måle produktivitet. Da stort set intet relateret til softwareudvikling er nemt og ligetil, kan man sige, at måling af programmeringsproduktivitet også er ret inkonsekvent og fragmenteret på tværs af branchen. Eller ganske enkelt sagt, forskellige teams og virksomheder kan bruge helt forskellige præstationsindikatorer og angribe dette problem fra en række vinkler. Så du behøver ikke besvære dig med at lære hver eneste metrik, der kan bruges af softwareudviklingsteams.

Hvilke typer softwareudviklingsproduktivitetsmålinger findes der?

Naturligvis er der flere forskellige produktivitetsmålinger, der nærmer sig måling af ydeevne på forskellige niveauer og vinkler. Her er de mest almindelige typer af sådanne produktivitetsmålinger:

• Formelle størrelsesfokuserede målinger.

Disse målinger er fokuseret på at måle størrelsen af ​​en programmørs arbejdsresultat, såsom kodelinjer (LOC), kodeinstruktionslængde, kodekompleksitet osv. Disse målinger anses i stigende grad for at være forældede i nutidens softwareudviklingsindustri.

• Tids- og funktionsfokuserede produktivitetsmålinger.

Der er et udvalg af traditionelle produktivitetsmålinger, der bruges i udvikling af vandfaldssoftware, såsom aktive dage, omfanget af funktionalitet, der sendes i en bestemt tidsperiode, kodeafgang, antal tildelte opgaver osv.

• Agile udviklingsprocesmetrikker.

Agile udviklingsprocesmålinger, såsom sprint-afbrændingsrapport, hastighed, gennemløbstid, cyklustid og andre, er sandsynligvis de mest almindeligt anvendte målinger blandt softwareudviklingsteams i dag. Vi vil tale om Agile metrics mere detaljeret senere i artiklen.

• Operationelle analytiske målinger.

Dette sæt metrikker er fokuseret på at måle softwareydeevne i dets nuværende produktionsmiljø. Gennemsnitstid mellem fejl (MTBF), middeltid til genopretning (MTTR) og programnedbrudsfrekvens er de mest anvendte målinger her.

• Test af metrics.

Softwaretest har sit eget sæt målinger til at måle kvaliteten af ​​systemtest, såsom procentdel af automatiserede test, kodedækning osv.

• Kundetilfredshedsmålinger.

Endelig er den ultimative metrik for ethvert stykke software slutkundens oplevelse, og der er også et helt sæt målinger for det, såsom kundeindsatsscore (CES), kundetilfredshedsscore (CSAT), netpromotorscore (NPS) og andre.

Agile softwareudviklingsmålinger

Som du kan se, er det ret nemt at fare vild i alle forviklingerne af softwareproduktivitetsmålinger. De eneste, som en almindelig softwareudvikler dog bør være godt bekendt med, er de agile målinger, der almindeligvis bruges af softwareudviklingsteams i dag som standarder for teamproduktivitetsmåling på tværs af forskellige dele af softwareudviklingens livscyklus. Lad os liste de vigtigste og mest brugte Agile-metrics.

1. Sprint Burndown.

Sprint Burndown-rapporter er en af ​​nøglemålingerne for agile scrum-udviklingsteams. Da udviklingsprocessen i agile er organiseret gennem tidsbestemte sprints, bruges Sprint Burndown som en måde at spore færdiggørelsen af ​​opgaver under en sprint. Timer eller historiepunkter bruges som måleenhed. Målet er at opnå konsekvente fremskridt og levere arbejde i overensstemmelse med indledende prognoser. Sprint Burndown hjælper teams med at måle arbejdstempoet og justere det, når det er nødvendigt.

2. Holdhastighed.

Hastighed er en anden nøgleindikator, som også er baseret på timer eller historiepunkter som en måleenhed. Den måler den gennemsnitlige mængde arbejde, et team udfører under en sprint, og bruges til estimering og planlægning gennem hele projektet. Sporingshastighed er vigtig for at sikre, at holdet leverer ensartet præstation.

3. Historiepunkter.

På et individuelt udviklingsteams niveau er historiepoint en værdifuld metrik, da størrelsen af ​​de historier, en programmør leverer under hver udgivelse, er en indikator for denne koders produktivitet.

4. Cykluskontrolskema.

Måler den samlede tid fra det øjeblik, hvor arbejdet med en opgave eller et andet efterslæb er påbegyndt, til det er afsluttet. Giver mulighed for at spore og kontrollere cyklustider og levere mere forudsigelige resultater.

5. Gennemløb og værdi leveret.

Projektledere analyserer opgaver, der er tildelt udviklere, og tildeler dem værdi. Denne metrik bruges derefter til at måle holdets gennemløb eller, med andre ord, mængden af ​​værdiskabende arbejde udført.

6. Kode Churn.

Code churn er en anden metrik, der er værd at nævne, da den bruges til at måle både produktiviteten for et team som helhed og til at spore individuelle programmørers ydeevne. Code churn måler, hvor ofte en udvikler fjerner eller foretager ændringer i tidligere tilføjede kodelinjer, og hvor stor en procentdel af tidligere skrevet kode, der ender med at blive ændret eller smidt væk.

Ekspertudtalelser

Til sidst, for at tilføje lidt perspektiv, et par citater om sagen af ​​erfarne softwareudviklingsprofessionelle. "Jeg håber ikke, du søger at "sammenligne" dine målinger med en eller anden form for standard eller endda med ydeevnen af ​​et andet team i en anden virksomhed. Overalt, hvor jeg har arbejdet, har der været unikke variationer i deres definitioner af historiepoint, hastighed, timevurderinger, opgaver osv., som virkelig ville gøre det næsten umuligt at sammenligne præstationerne for et hold fra én virksomhed direkte med et andet teams præstationer hos et andet. virksomhed,” bemærkede Cliff Gilley, tidligere teknisk produktchef og Agile Coach. "Jeg er lidt usikker på målinger, når det kommer til at vejlede teampræstationer. Når du først er opmærksom på kun en eller to variable, bliver det meget nemt at falde i (med vilje eller på anden måde) at spille metrikken og narre dig selv, at du forbedrer - når alt, hvad du gør, er at forbedre metrikken. For eksempel kan metrics baseret på hastighed "forbedres" ved at teamet flytter til mindre historier (mindre arbejde pr. historie - så flere historier afsluttet - så hastigheden stiger). Det kan være en god ting, hvis historierne er nyttige brugerhistorier, der leverer mindre trin af forretningsværdi. Det kan være en dårlig ting, hvis historierne bliver mindre og mere "tekniske" opgaver, der ikke leverer reel værdi i sig selv," sagde Adrian Howard, en anden brancheprofessionel.. “Når jeg arbejder i et pull-baseret system, værdsætter jeg gennemløb og cyklustid. Den første giver mig generel information om vores teams kapacitet og kan med tiden blive en meget kraftfuld forudsigende målestok. Den anden er nyttig som en generel målestok for vores rørledningers effektivitet. Hvis cyklustiden er høj, er det tid til at begynde at se på pipelinen, fordi der er en begrænsning, som vi sandsynligvis kan arbejde hen imod at lette/udnytte. Men metrics er kun værktøjer. Gå ikke tabt i dem, og begynd bestemt ikke at planlægge i retning af en bestemt metrik. Tænk over, hvad du laver som et team, og hvordan du naturligt arbejder, og byg derefter systemet op omkring folkene. Målingerne skal hjælpe dig med at se, hvordan dit system understøtter alles arbejde. Eller ej,” konkluderede Dave Cerra, en producent af videospilsudvikling .