som jeg bemærkede i artiklen “Hvorfor metrics ikke betyder noget i programmeludvikling (medmindre du parrer dem med forretningsmål),” kræver valg af metrics betydelig tanke og omhu for at understøtte de specifikke spørgsmål, en virksomhed virkelig har brug for at besvare. Her er det kritiske punkt: målinger bør kun udformes som en måde at besvare forretningsspørgsmål på. Og disse spørgsmål er aldrig, “hvor mange KLOCs er vi op til nu?”
denne artikel fortsætter, hvor den forrige slap, ved først at diskutere de specifikke målinger, som hvert hold skal begynde at bruge, eller i det mindste planlægge at bruge snart som en måde at forbedre mærkbar ydeevne på. Bemærk, at titlen på denne artikel hævder, at der er “9 målinger, der kan gøre en forskel…”—fordi det, der virkelig er vigtigt, hvad der virkelig vil gøre en forskel, er, hvordan disse målinger faktisk bruges til at forbedre forretningsværdien. Denne brug er op til dig. Derefter afsluttes denne artikel med at forklare, hvordan du kan kombinere disse målinger for at skabe mening, samt formulere og teste en forretningsværdihypotese.
Start med at måle de rigtige ting
her er ni objektive målinger (markeret med punkttegn), som du skal overvåge kontinuerligt for at foretage trinvise forbedringer af processer og produktionsmiljøer. Forbedringer i disse tal garanterer ikke, at dine kundetilfredshedsniveauer stiger med spring og grænser. Men i det mindste er disse de rigtige ting at måle. I et senere afsnit af denne artikel, “sætte det hele sammen,” vil du se hvorfor.
Agile process metrics
for agile og lean processer er de grundlæggende metrics leadtime, cycle time, team velocity og open/close satser. Disse målinger hjælper med at planlægge og informere beslutninger om procesforbedring. Selvom de ikke måler succes eller værditilvækst, og de ikke har noget at gøre med programmets objektive kvalitet, skal du alligevel måle dem. Jeg forklarer hvorfor nedenfor.
- Leadtime—hvor lang tid det tager dig at gå fra ide til leveret program. Hvis du vil være mere lydhør over for dine kunder, skal du arbejde for at reducere din leveringstid, typisk ved at forenkle beslutningstagningen og reducere ventetiden. Leadtime inkluderer cyklustid.
- Cyklustid—hvor lang tid det tager dig at foretage en ændring af dit system og levere denne ændring til produktion. Hold, der bruger kontinuerlig levering, kan have cyklustider målt i minutter eller endda sekunder i stedet for måneder.
- Team velocity—hvor mange “enheder” af programmet holdet typisk fuldender i en iteration (aka “sprint”). Dette nummer skal kun bruges til at planlægge iterationer. Sammenligning af holdhastigheder er nonsens, fordi metricen er baseret på ikke-objektive estimater. At behandle hastighed som en succesforanstaltning er upassende, og at gøre en bestemt hastighed til et mål fordrejer dens værdi til estimering og planlægning.
- Åbn/Luk satser—hvor mange produktionsproblemer rapporteres og lukkes inden for en bestemt tidsperiode. Den generelle tendens betyder mere end de specifikke tal.
når en eller alle disse målinger er uden for det forventede interval eller tendenser i alarmerende retninger, skal du ikke antage en årsag. Tal med holdet, få hele historien, og lad holdet beslutte, om der er grund til bekymring, og i bekræftende fald, hvordan man løser det.
du kan ikke kende eller antage grundlæggende årsager fra tallene, men disse målinger giver dig indsigt i, hvor dine væsentlige processer har brug for opmærksomhed. En høj åben sats og en lav tæt sats på tværs af et par iterationer, for eksempel, kan betyde, at produktionsproblemerne i øjeblikket er en lavere prioritet end nye funktioner, eller måske at teamet er fokuseret på at reducere teknisk gæld for at løse hele klasser af problemer, eller at den eneste person, der vidste, hvordan man løser dem, holder op, eller noget andet. Du kan ikke kende eller antage grundlæggende årsager fra tallene.
Produktionsanalyse
- Middeltid mellem fejl (MTBF)
- Middeltid til gendannelse / reparation (MTTR)
begge er overordnede mål for dit programs ydeevne i det nuværende produktionsmiljø.
- Application crash rate—hvor mange gange et program fejler divideret med hvor mange gange det blev brugt. Denne måling er relateret til MTBF og MTTR.
Bemærk, at ingen af disse tre metrics fortæller dig om individuelle funktioner eller berørte brugere. Stadig, jo mindre tal, jo bedre. Moderne operationsovervågningsprogrammer gør det nemt at indsamle detaljerede målinger på individuelle programmer og transaktioner, men det tager tid og omhyggelig overvejelse at oprette korrekte intervaller for advarsler og/eller udløsere til skalering op eller ned (for skybaserede systemer).
vi vil gerne have, at vores program aldrig fejler, men det er statistisk usandsynligt. Når vores program fejler, vil vi gerne have, at det aldrig mister kritiske data og genopretter øjeblikkeligt, men det kan være ekstraordinært svært at opnå. Hvis dit program er din indtægtskilde, er indsatsen dog umagen værd.
ud over MTBF og MTTR er mere finkornede målinger baseret på individuelle transaktioner, applikationer og så videre, og de afspejler den leverede forretningsværdi og omkostningerne ved afhjælpning af fejl. Hvis din transaktionsbehandlingsapplikation går ned en gang i hundrede, men genopretter om et sekund eller to og ikke mister nogen kritiske oplysninger, kan den 1 procent crashrate være god nok. Men hvis hvert nedbrud er af en app, der kører 100.000 transaktioner om dagen, mister et salg på $100 og koster $50 for at afhjælpe på bagsiden, vil den 1 procent crashrate være en prioritet. Fastsættelse det vil påvirke bundlinjen betydeligt.
Sikkerhedsmålinger
sikkerhed er et aspekt af programmelkvalitet, der ofte overses indtil senere (eller for sent). Sikkerhedsanalyseværktøjer kan bruges i byggeprocessen ud over mere specialiserede evalueringer og stresstest. Sikkerhedskrav er ofte enkle og almindelige, men programmeludviklingsholdet skal være opmærksom på dem og de målinger, der stammer fra dem.
hele spektret af sikkerhedspraksis og relaterede målinger ligger uden for denne artikels anvendelsesområde, men som med agile procesmålinger og produktionsmålinger er der et par specifikke målinger, der kan betyde meget for dine kunders samlede tilfredshed.
- endpoint hændelser—hvor mange endepunkter (mobile enheder, arbejdsstationer osv.) har oplevet en virusinfektion over en given periode?
- MTTR (mean time to repair)—i sikkerhedsmålinger er dette tiden mellem opdagelsen af et sikkerhedsbrud og et implementeret, fungerende middel. Som med produktionen MTTR metrisk nævnt ovenfor, sikkerhed MTTR bør spores over bestemte tidsintervaller. Hvis MTTR-værdien bliver mindre over tid, bliver udviklere mere effektive til at forstå sikkerhedsproblemer som fejl og hvordan man løser dem.
for begge disse målinger betyder mindre tal over tid, at du bevæger dig i den rigtige retning. Færre endpoint hændelser taler for sig selv. Da MTTR-værdien bliver mindre, bliver udviklere mere effektive til at forstå sikkerhedsproblemer som fejl og hvordan man løser dem.
du kan finde flere måder at anvende sikkerhedsmålinger på programudvikling i artiklerne Application Security for Agile Projects and Security Threat Models: en agil introduktion.
en note om kildekode metrics
i dag er det nemt at tilslutte en kildekode scanner til din build pipeline og producere bunker af objektive målinger. Der er empiriske gennemsnit og foreslåede intervaller og logiske argumenter om den relative betydning af disse målinger. Men i praksis er disse værktøjer mest nyttige til at håndhæve kodningsstile, markere visse anti-mønstre og identificere outliers og tendenser.
det er bare ikke værd at blive hængt op på tallene. Her er et eksempel, som forklaring.
Antag at du finder en metode i en klasse med en latterlig metrisk, såsom en NPATH-kompleksitet på 52 millioner. Det betyder, at det ville tage 52 millioner testsager for fuldt ud at udøve hver sti gennem koden. Du kan refactor koden til en enklere struktur, men før du gør det, skal du overveje, hvad forretningsvirkningen ville være. Chancerne er, at den gamle, grimme kode fungerer godt nok (selvom dens testdækning kan være utilstrækkelig). At kalde anti-mønsteret til holdet, så de kan undgå at gentage det, er værdifuld læring, men at rette det ville sandsynligvis ikke flytte nålen på nogen relevant forretningsmåling.
det er bedst, hvis holdet accepterer niveauet for overholdelse og regler, som deres kode er underlagt, men vær opmærksom på at undersøge outliers og blive bekymret for trendblips kan spilde meget tid.
sæt det hele sammen: Succes er den ultimative måling
glæden ved at bruge automatiserede værktøjer til sporing og måling af kvalitetsmålinger og brugeranalyse er, at det frigør tid til at fokusere på de målinger, der virkelig betyder noget: succesmålinger.
Sådan bruges metrics til succes
virksomheder har mål. Mål indebærer spørgsmål, såsom “Hvordan ser succes ud?”eller” hvordan vil dette påvirke kundeadfærd?”Korrekt kvantificerede spørgsmål indebærer målinger.
sæt en anden måde, metrics bør kun bruges til at besvare spørgsmål, for at teste hypoteser, der understøtter et specifikt forretningsmål. Og dette skal kun ske, så længe spørgsmålene og svarene hjælper med at skabe positive ændringer.
nu har ikke alle projekter generelt nogle sæt invariante mål, Spørgsmål og hypoteser og dermed målinger?
Ja, men kun fra virksomhedens synspunkt. Foranstaltninger på forretningsniveau af ting som brugerengagement, tætte satser, indtægtsgenerering og så videre giver feedback om, hvordan virksomheden klarer sig i den virkelige verden. Ændringer i programmer, der påvirker virksomheden, vil også påvirke disse typer af målinger.
på et finere opløsningsniveau kan hver funktion og brugerhistorie have sin egen succesmåling—helst kun en og en, der er direkte relateret til et mål for værdi leveret til kunden. At færdiggøre ni ud af ti historier i en sprint for funktioner, der aldrig leveres, er affald, ikke succes. At levere historier, som kunderne ikke ønsker eller bruger, er affald, ikke succes. At levere en historie, der forbedrer et eller andet aspekt af brugerlykke, er en succes. At levere en historie, der påviseligt ikke forbedrer brugerengagement, er også en succes, fordi du vil have lært noget, der ikke fungerede, ugyldiggjort en forretningshypotese og frigjort ressourcer til at forfølge andre veje.
sådan formuleres en værdihypotese
en værdihypotese er en erklæring om, hvad du tror vil ske som et resultat af leveringen af en bestemt funktion. Forholdet mellem programmet, det ønskede resultat og metrics danner værdihypotesen for funktionen (eller systemet, historien eller opgraderingen osv.). Hypotesen skal udtrykke, hvordan den målrettede måling forventes at ændre sig, over hvilken tidsramme og hvor meget der skal betragtes som effektiv. Du bliver i det mindste nødt til at tale med teamet og produktejeren for at finde ud af den specifikke ting, denne funktion eller historie er beregnet til at skabe eller forbedre med hensyn til virksomheden for at formulere dens værdihypotese. Du bliver muligvis nødt til at spørge “hvorfor” et par gange (som en treårig) for at skrælle lagene af ikke-angivne antagelser tilbage; vær tålmodig. Når du forstår, hvad forretningsværdien skal være, kan du begynde at stille de spørgsmål, der fører dig til de målinger, der besvarer spørgsmålet.
for eksempel kan en “teknisk” historie for at forbedre hastigheden af en e-handel checkout proces have som sin underliggende antagelse, at en hurtigere checkout vil føre til mere salg. Men hvorfor tror vi det? Er en masse mennesker opgive deres indkøbsvogne under købsprocessen? Hvis det er konsensus (fordi denne konsensus understøttes af baseline data), så kan værdihypotesen være “vi mener, at en hurtigere købsproces vil resultere i nedsat cart-abandonment-satser, hvilket fører til højere salg og forbedret brugeroplevelse.”
du kan sikkert antage, at brugerne vil kunne lide hurtigere checkout, men det gør ikke ondt at spørge, om de har bemærket det. Cart-nedlæggelse satser og salg kan måles før og efter den nye proces er på plads, i en periode. Hvis cart-abandonment rate falder og salget stiger (ud over statistiske udsving), understøtter beviset hypotesen, og du kan overveje, om endnu yderligere hastighedsforbedringer er berettigede. Hvis de ikke er det, lad denne metrik falme i baggrunden (eller fjern den, hvis den er distraherende), og vend din opmærksomhed mod den næste hypotese. Hvis cart-nedlæggelse sats falder, men salget er uændret, måle for en længere periode eller genoverveje den formodede sammenhæng mellem cart-nedlæggelse og salg. Med andre ord, brug målinger til at lære, og kun så længe de viser sig nyttige til at køre forbedringer.
i nogle tilfælde kan hypotesen være klart forkert, så vi taber metrics (og fortryder programændringerne!) efter et par dage. I andre tilfælde kan hypotesen være korrekt, så vi fortsætter med at drive forbedringer på dette område i årevis.
seks heuristikker til effektiv brug af metrics
vi har set, hvordan subjektive metrics betyder langt mere for forretningssucces end de traditionelle, objektive kvalitetsmålinger fra gamle. Den indsats, der kræves for at finde og måle relevante forretningsmålinger for funktioner, opvejes af de opnåede indsigter og læringsmuligheder. Forretningsbetingelser og muligheder ændres konstant, så i stedet for at opsummere en formel, der skal følges, som kan være skrøbelig, her er seks tommelfingerregler, eller heuristik, for at hjælpe med at bevare fokus og fleksibilitet. Må de hjælpe med at guide dig på din rejse til kvalitetsprogrammer og forretningssucces!
- Metrics kan ikke fortælle dig historien; kun holdet kan gøre det (med en hat tip til Todd DeCapula).
- sammenligning af snefnug er affald.
- du kan måle næsten alt, men du kan ikke være opmærksom på alt.
- business success metrics driver forbedringer af programmer, ikke omvendt.
- hver funktion tilføjer værdi; enten måle det eller ikke gøre det.
- mål kun det, der betyder noget nu.