9 beregninger som kan gjøre en forskjell for dagens programvareutviklingsteam

som jeg nevnte i artikkelen «Hvorfor beregninger ikke betyr noe i programvareutvikling( med mindre du kobler dem med forretningsmål),» velger beregninger krever betydelig tanke og omsorg for å støtte de spesifikke spørsmålene en bedrift virkelig trenger å svare på. Her er det kritiske punktet: Målinger bør bare utformes som en måte å svare på forretningsspørsmål. Og disse spørsmålene er aldri, » Hvor mange KLOCs er vi opp til nå ?»

denne artikkelen fortsetter der den forrige slapp, ved først å diskutere de spesifikke beregningene hvert lag skal begynne å bruke, eller i det minste planlegge å bruke snart som en måte å forbedre merkbar ytelse på. Merk at tittelen på denne artikkelen hevder at det er «9 beregninger SOM kan gjøre en forskjell…» – fordi det som virkelig er viktig, hva som virkelig vil gjøre en forskjell, er hvordan disse beregningene faktisk brukes til å forbedre forretningsverdien. Denne bruken er opp til deg. Deretter avsluttes denne artikkelen ved å forklare hvordan du kan kombinere disse beregningene for å skape mening, samt formulere og teste en forretningsverdihypotese.

Start med å måle de riktige tingene

her er ni objektive beregninger (merket med punkter) som du bør overvåke kontinuerlig, for å gjøre trinnvise forbedringer i prosesser og produksjonsmiljøer. Forbedringer i disse tallene vil ikke garantere at dine kundetilfredshet nivåer vil stige i store sprang. Men i det minste er disse de riktige tingene å måle. I en senere del av denne artikkelen,» Sette det hele sammen, » vil du se hvorfor.

agile process metrics

for agile og lean prosesser er de grunnleggende beregningene ledetid, syklustid, teamhastighet og åpne/lukke priser. Disse beregningene hjelpe planlegging og informere beslutninger om prosessforbedring. Selv om de ikke måler suksess eller verdiskaping, og de ikke har noe å gjøre med den objektive kvaliteten på programvaren, bør du måle dem uansett. Jeg forklarer hvorfor nedenfor.

• Leveringstid—hvor lang Tid det tar deg å gå fra ide til levert programvare. Hvis du vil være mer lydhør overfor kundene dine, kan du jobbe for å redusere ledetiden, typisk ved å forenkle beslutningsprosessen og redusere ventetiden. Ledetid inkluderer syklus tid.
• Syklustid—hvor lang Tid det tar deg å gjøre en endring i programvaresystemet og levere den endringen til produksjon. Team som bruker kontinuerlig levering kan ha syklustider målt i minutter eller sekunder i stedet for måneder.
• Team velocity—Hvor mange «enheter» av programvare laget vanligvis fullfører i en iterasjon (aka «sprint»). Dette nummeret skal bare brukes til å planlegge iterasjoner. Sammenligning av laghastigheter er tull, fordi metriske er basert på ikke-objektive estimater. Å behandle hastighet som et suksessmål er upassende, og å gjøre en bestemt hastighet til et mål forvrenger verdien for estimering og planlegging.
• åpne/lukke priser – hvor mange produksjonsproblemer rapporteres og lukkes innen en bestemt tidsperiode. Den generelle trenden betyr mer enn de spesifikke tallene.

når noen eller alle disse beregningene er utenfor forventet område eller trending i alarmerende retninger, må du ikke anta en årsak. Snakk med teamet, få hele historien, og la teamet avgjøre om det er grunn til bekymring, og i så fall hvordan å fikse det.

du kan ikke vite eller anta grunnårsaker fra tallene, men disse beregningene gir deg innsikt i hvor dine viktige prosesser trenger oppmerksomhet. En høy åpen rente og en lav lukkrate over noen få iterasjoner, for eksempel, kan bety at produksjonsproblemene for øyeblikket er lavere prioritet enn nye funksjoner, eller kanskje at teamet er fokusert på å redusere teknisk gjeld for å fikse hele klasser av problemer, eller at den eneste personen som visste hvordan de skulle fikse dem, sluttet, eller noe annet. Du kan ikke vite eller anta grunnårsaker fra tallene.

Produksjonsanalyse

• Gjennomsnittlig tid mellom feil (MTBF)
• Gjennomsnittlig tid for gjenoppretting/reparasjon (MTTR)

Begge er generelle tiltak av programvaresystemets ytelse i sitt nåværende produksjonsmiljø.

• programkrasj—hvor mange ganger et program mislykkes delt på hvor mange ganger det ble brukt. Denne beregningen er relatert TIL MTBF og MTTR.

Merk at ingen av disse tre beregningene forteller deg om individuelle funksjoner eller brukere som er berørt. Likevel, jo mindre tallene, desto bedre. Moderne operasjoner-overvåkingsprogramvare gjør det ganske enkelt å samle detaljerte beregninger på individuelle programmer og transaksjoner, men det tar tid og forsiktig å sette opp riktige områder for varsler og/eller utløsere for skalering opp eller ned (for skybaserte systemer).

vi vil at programvaren vår aldri skal mislykkes, men det er statistisk usannsynlig. Når vår programvare mislykkes, vi ønsker det å aldri miste noen kritiske data og gjenopprette umiddelbart, men det kan være svært vanskelig å oppnå. Hvis programvaren er din inntektskilde, derimot, innsatsen er verdt.

utover MTBF og MTTR er mer finkornede målinger basert på individuelle transaksjoner, applikasjoner og så videre, og de gjenspeiler forretningsverdien som er levert og kostnadene ved å rette opp feil. Hvis transaksjonsbehandlingsprogrammet krasjer en gang i hundre, men gjenoppretter om et sekund eller to og ikke mister noen kritisk informasjon, kan den 1 prosent krasjfrekvensen være god nok. Men hvis hver krasj er av en app som kjører 100 000 transaksjoner om dagen, mister et salg på $100 og koster $50 for å rette opp på baksiden, vil den 1 prosent krasjraten være en prioritet. Å fikse det vil påvirke bunnlinjen betydelig.

sikkerhetsmålinger

Sikkerhet er et aspekt av programvarekvalitet som ofte overses til senere (eller for sent). Sikkerhetsanalyseverktøy kan brukes i byggeprosessen, i tillegg til mer spesialiserte evalueringer og stresstester. Sikkerhetskrav er ofte enkle og vanlige, men programvareutviklingsteamet må være oppmerksom på dem, og av beregningene som er avledet fra dem.

hele spekteret av sikkerhetspraksis og relaterte beregninger er utenfor omfanget av denne artikkelen, men som med agile prosessmålinger og produksjonsmålinger, er det noen få spesifikke beregninger som kan bety mye for kundenes generelle tilfredshet.

• endepunkthendelser-hvor mange endepunkter (mobile enheter, arbeidsstasjoner osv.) har opplevd en virusinfeksjon over en gitt tidsperiode ?
• mttr (mean time to repair)—i sikkerhetsmålinger er dette tiden mellom oppdagelsen av et sikkerhetsbrudd og en distribuert, fungerende løsning. Som med produksjons MTTR metrisk nevnt ovenfor, bør sikkerhet MTTR spores over bestemte tidsintervaller. Hvis mttr-verdien blir mindre over tid, blir utviklere mer effektive når det gjelder å forstå sikkerhetsproblemer som feil og hvordan de skal løses.

for begge disse beregningene betyr mindre tall over tid at du beveger deg i riktig retning. Færre endepunktshendelser snakker for seg selv. Etter HVERT som mttr-verdien blir mindre, blir utviklere mer effektive når det gjelder å forstå sikkerhetsproblemer som feil og hvordan de kan løses.

du finner flere måter å bruke sikkerhetsmålinger på i programvareutvikling i artiklene Application Security for Agile-Prosjekter Og Security Threat Models: En Agile-Introduksjon.

et notat om kildekodemålinger

I Dag er Det enkelt å koble en kildekodeskanner til byggepipelinen din og produsere store mengder objektive beregninger. Det er empiriske gjennomsnitt og foreslåtte områder og logiske argumenter om den relative betydningen av disse beregningene. Men i praksis er disse verktøyene mest nyttige for å håndheve kodestiler, flagge visse anti-mønstre og identifisere outliers og trender.

Det er bare ikke verdt å bli hengt opp på tallene. Her er et eksempel, i form av forklaring.

Anta at du finner en metode i en klasse med en latterlig metrisk, for eksempel EN npath-kompleksitet på 52 millioner. Det betyr at det ville ta 52 millioner testtilfeller for å fullt ut utøve hver vei gjennom koden. Du kan refactor koden til en enklere struktur, men før du gjør det, bør du vurdere hva forretningsvirkningen ville være. Sjansen er at den gamle, stygge koden fungerer godt nok (selv om testdekningen kan være utilstrekkelig). Å ringe ut anti-mønsteret til teamet slik at de kan unngå å gjenta det, er verdifull læring, men å fikse det ville nok ikke flytte nålen på noen relevant forretningsmetode.

det er best hvis teamet er enig i nivået av overholdelse og regler som deres kode er underlagt, men vær oppmerksom på at å undersøke avvikere og bli bekymret for trendblips kan kaste bort mye tid.

sett deretter alt sammen: Suksess er den ultimate beregningen

gleden ved å bruke automatiserte verktøy for sporing og måling av kvalitetsmålinger og brukeranalyse er at det frigjør tid til å fokusere på beregningene som virkelig betyr noe: suksessmålinger.

slik bruker du beregninger for suksess

Bedrifter har mål. Mål innebærer spørsmål, for eksempel » hvordan ser suksess ut?»eller» hvordan vil dette påvirke kundeatferd?»Riktig kvantifiserte spørsmål innebærer beregninger .

på en annen måte bør beregninger bare brukes til å svare på spørsmål, for å teste hypoteser som støtter et bestemt forretningsmål. Og dette bør bare gjøres så lenge spørsmålene og svarene bidrar til å drive positive endringer.

nå har ikke alle prosjekter generelt noen sett med invariante mål, spørsmål og hypoteser, og dermed beregninger?

Ja, Men bare fra synspunkt av virksomheten. Mål på bedriftsnivå av ting som brukerengasjement, lukkepriser, inntektsgenerering og så videre gir tilbakemelding på hvordan virksomheten gjør det i den virkelige verden. Endringer i programvare som påvirker virksomheten vil også påvirke slike beregninger.

på et finere oppløsningsnivå kan hver funksjon og brukerhistorie ha sin egen suksessberegning—helst bare en, og en som er direkte relatert til et mål på verdi levert til kunden. Å fullføre ni av ti historier i en sprint for funksjoner som aldri leveres, er avfall, ikke suksess. Å levere historier som kundene ikke vil ha eller bruke, er sløsing, ikke suksess. Levere en historie som forbedrer noen aspekter av brukeren lykke er en suksess. Å levere en historie som påviselig ikke forbedrer brukerengasjementet, er også en suksess, fordi du har lært noe som ikke fungerte, ugyldiggjort en forretningshypotese og frigjort ressurser til å forfølge andre veier.

hvordan formulere en verdihypotese

en verdihypotese er en uttalelse om hva du tror vil skje som følge av levering av en bestemt funksjon. Forholdet mellom programvaren, det ønskede resultatet og beregningene danner verdihypotesen for funksjonen (eller systemet, eller historien, eller oppgraderingen, etc.). Hypotesen skal uttrykke hvordan den målrettede metriske forventes å endres, over hvilken tidsramme, og hvor mye som skal anses som effektiv. Du må minst snakke med teamet og produkteieren for å finne ut den spesifikke tingen denne funksjonen eller historien er ment å skape eller forbedre med hensyn til virksomheten for å formulere verdihypotesen. Du må kanskje spørre «hvorfor» et par ganger (som en treåring) for å skrelle tilbake lagene av uuttalte antagelser; vær tålmodig. Når du forstår hva forretningsverdien skal være, kan du begynne å stille spørsmålene som vil lede deg til beregningene som svarer på spørsmålet.

for eksempel, en «teknisk» historie å forbedre hastigheten på en e-handel betalingsprosessen kan ha som sin underliggende forutsetning at en raskere kassa vil føre til mer salg. Men hvorfor tror vi det? Er mange mennesker forlater sine handlekurver under betalingsprosessen? Hvis det er konsensus (fordi at konsensus er støttet av baseline data), så verdien hypotesen kan være » vi tror at en raskere betalingsprosessen vil resultere i redusert handlevogn-abandonment priser, fører til høyere salg og forbedret brukeropplevelse.»

du kan sannsynligvis anta at brukerne vil like raskere kassen, men det gjør ikke vondt å spørre om de har lagt merke til. Cart-abandonment priser og salg kan måles før og etter den nye prosessen er på plass, for en periode. Hvis cart-abandonment rate faller og salget øker (utover statistiske svingninger), støtter bevisene hypotesen, og du kan vurdere om ytterligere hastighetsforbedringer er berettiget. Hvis de ikke er det, la denne metriske fade inn i bakgrunnen (eller fjern den, hvis den er distraherende), og gjør oppmerksomheten til neste hypotese. Hvis cart-abandonment rate avtar, men salget er uendret, måle for en lengre periode eller revurdere den antatte koblingen mellom cart-abandonment og salg. Med andre ord, bruk beregninger for å lære, og bare så lenge de viser seg å være nyttige for å kjøre forbedringer.

i noen tilfeller kan hypotesen være tydelig feil, så vi slipper beregningene (og angre programvareendringene!) etter noen dager. I andre tilfeller kan hypotesen være riktig, så vi fortsetter å drive forbedringer på dette området i mange år.

Seks heuristikker for effektiv bruk av beregninger

Vi har sett hvordan subjektive programvaremålinger betyr langt mer for suksess for virksomheten enn de tradisjonelle, objektive kvalitetsmålinger fra gammel tid. Innsatsen som kreves for å finne og måle relevante forretningsmål for funksjoner, oppveies av innsiktene og læringsmulighetene som er oppnådd. Forretningsforhold og muligheter endres hele tiden, så i stedet for å oppsummere en formel for å følge, som kan være skjøre, er det seks tommelfingerregler, eller heuristikk, for å opprettholde fokus og fleksibilitet. Kan de hjelpe deg på din reise til kvalitet programvare og suksess!

1. Beregninger kan ikke fortelle deg historien; bare laget kan gjøre det (Med et hattespiss Til Todd DeCapula).
2. Sammenligning av snøflak er avfall.
3. du kan måle nesten hva som helst, men du kan ikke være oppmerksom på alt.
4. beregninger for suksess driver programvareforbedringer, ikke omvendt.
5. Hver funksjon legger til verdi; enten måle det eller ikke gjøre det.
6. Mål Bare det som betyr noe nå.