som jag noterade i artikeln ”Varför metrics spelar ingen roll i mjukvaruutveckling (om du inte parar dem med affärsmål)”, att välja metrics kräver stor tanke och omsorg för att stödja de specifika frågorna som ett företag verkligen behöver svara på. Här är den kritiska punkten: mätningar bör endast utformas som ett sätt att svara på affärsfrågor. Och dessa frågor är aldrig, ” hur många KLOCs är vi hittills?”
den här artikeln plockar upp var den föregående slutade, genom att först diskutera de specifika mätvärdena som varje lag bör börja använda, eller åtminstone planera att använda snart som ett sätt att förbättra märkbar prestanda. Observera att titeln på den här artikeln hävdar att det finns ”9 mätvärden som kan göra skillnad…”—för det som verkligen är viktigt, vad som verkligen kommer att göra skillnad, är hur dessa mätvärden faktiskt används för att förbättra affärsvärdet. Den användningen är upp till dig. Sedan avslutar den här artikeln med att förklara hur du kan kombinera dessa mätvärden för att skapa mening, samt formulera och testa en affärsvärdeshypotes.
börja med att mäta rätt saker
här är nio objektiva mätvärden (markerade med punktpunkter) som du bör övervaka kontinuerligt för att göra stegvisa förbättringar av processer och produktionsmiljöer. Förbättringar i dessa siffror garanterar inte att dina kundnöjdhetsnivåer kommer att stiga med språng. Men åtminstone är det rätt saker att mäta. I ett senare avsnitt av den här artikeln, ”sätta ihop allt”, ser du varför.
Agile process metrics
för agile och lean processer är de grundläggande mätvärdena ledtid, cykeltid, laghastighet och öppna/stänga priser. Dessa mätvärden hjälper till att planera och informera beslut om processförbättring. Även om de inte mäter framgång eller mervärde, och de inte har något att göra med mjukvarans objektiva kvalitet, bör du mäta dem ändå. Jag förklarar varför nedan.
- Leadtime—hur lång tid det tar att gå från idea till levererad programvara. Om du vill vara mer lyhörd för dina kunder, arbeta för att minska din ledtid, vanligtvis genom att förenkla beslutsfattandet och minska väntetiden. Leadtime inkluderar cykeltid.
- Cykeltid—hur lång tid det tar dig att göra en ändring i ditt mjukvarusystem och leverera den förändringen till produktion. Lag som använder kontinuerlig leverans kan ha cykeltider uppmätta i minuter eller till och med sekunder istället för månader.
- Team velocity—hur många ”enheter” av programvara som laget vanligtvis Slutför i en iteration (aka ”sprint”). Detta nummer bör endast användas för att planera iterationer. Att jämföra laghastigheter är nonsens, eftersom mätvärdet är baserat på icke-objektiva uppskattningar. Att behandla hastighet som ett framgångsmått är olämpligt och att göra en specifik hastighet till ett mål snedvrider dess värde för uppskattning och planering.
- öppna/stänga priser—hur många produktionsproblem rapporteras och stängs inom en viss tidsperiod. Den allmänna trenden betyder mer än de specifika siffrorna.
när någon eller alla dessa mätvärden ligger utanför det förväntade intervallet eller trender i alarmerande riktningar, anta inte en orsak. Prata med laget, få hela historien och låt laget bestämma om det finns anledning till oro, och i så fall hur man fixar det.
du kan inte veta eller anta grundorsaker från siffrorna, men dessa mätvärden ger dig inblick i var dina väsentliga processer behöver uppmärksamhet. En hög öppen takt och en låg stängningshastighet över några iterationer kan till exempel innebära att produktionsproblemen för närvarande är lägre prioriterade än nya funktioner, eller kanske att laget är inriktat på att minska teknisk skuld för att fixa hela klasser av problem, eller att den enda personen som visste hur man åtgärdar dem slutar eller något annat. Du kan inte veta eller anta grundorsaker från siffrorna.
Produktionsanalys
- medeltid mellan fel (MTBF)
- medeltid för att återställa / reparera (MTTR)
båda är övergripande mått på ditt mjukvarusystems prestanda i sin nuvarande produktionsmiljö.
- application crash rate—hur många gånger ETT program misslyckas dividerat med hur många gånger det användes. Detta mått är relaterat till MTBF och MTTR.
Observera att ingen av dessa tre mätvärden berättar om enskilda funktioner eller användare som påverkas. Ändå, ju mindre siffrorna desto bättre. Modern operations-övervakning programvara gör att samla detaljerade mått på enskilda program och transaktioner ganska lätt, men det tar tid och noggrann eftertanke att ställa in lämpliga intervall för varningar och/eller triggers för skalning upp eller ner (för molnbaserade system).
vi vill att vår programvara aldrig ska misslyckas, men det är statistiskt osannolikt. När vår programvara misslyckas vill vi att den aldrig ska förlora några kritiska data och återhämta sig direkt, men det kan vara utomordentligt svårt att uppnå. Om din programvara är din inkomstkälla, dock, ansträngningen är värt.
utöver MTBF och MTTR baseras mer finkorniga mätningar på enskilda transaktioner, applikationer och så vidare, och de återspeglar det levererade affärsvärdet och kostnaden för att åtgärda fel. Om din transaktionsbehandlingsapplikation kraschar en gång i hundra men återhämtar sig på en sekund eller två och inte förlorar någon kritisk information, kan den 1 procent kraschfrekvensen vara tillräckligt bra. Men om varje krasch är av en app som kör 100 000 transaktioner om dagen, förlorar en $100-försäljning och kostar $50 för att avhjälpa på baksidan, kommer den 1-procentiga kraschfrekvensen att vara en prioritet. Att fixa det kommer att påverka bottenlinjen avsevärt.
säkerhetsmått
säkerhet är en aspekt av programkvalitet som ofta förbises förrän senare (eller för sent). Säkerhetsanalysverktyg kan användas i byggprocessen, förutom mer specialiserade utvärderingar och stresstester. Säkerhetskrav är ofta enkla och vanliga, men mjukvaruutvecklingsteamet måste vara uppmärksam på dem och de mätvärden som härrör från dem.
hela utbudet av säkerhetspraxis och relaterade mätvärden ligger utanför ramen för den här artikeln, men som med agila processmått och produktionsmått finns det några specifika mätvärden som kan betyda mycket för dina kunders övergripande tillfredsställelse.
- Endpoint incidenter—hur många endpoints (mobila enheter, arbetsstationer, etc.) har upplevt en virusinfektion under en viss tidsperiod?
- MTTR (mean time to repair)—i säkerhetsmått är detta tiden mellan upptäckten av ett säkerhetsbrott och en utplacerad, fungerande åtgärd. Som med Produktions MTTR metriska noterade ovan, säkerhet MTTR bör spåras över specifika tidsintervall. Om MTTR-värdet blir mindre med tiden blir Utvecklare mer effektiva när det gäller att förstå säkerhetsproblem som buggar och hur man åtgärdar dem.
för båda dessa mätvärden betyder mindre tal över tiden att du rör dig i rätt riktning. Färre slutpunktsincidenter talar för sig själv. När MTTR-värdet blir mindre blir Utvecklare mer effektiva när det gäller att förstå säkerhetsproblem som buggar och hur man åtgärdar dem.
du kan hitta fler sätt att tillämpa säkerhetsmått på mjukvaruutveckling i artiklarna Application Security for Agile Projects and Security Threat Models: An Agile Introduction.
en anteckning om källkodsmått
idag är det enkelt att ansluta en källkodsskanner till din byggrörledning och producera mängder av objektiva mätvärden. Det finns empiriska medelvärden och föreslagna intervall och logiska argument om den relativa betydelsen av dessa mätvärden. Men i praktiken är dessa verktyg mest användbara för att genomdriva kodningsstilar, flagga vissa antimönster och identifiera avvikare och trender.
det är bara inte värt att hänga på siffrorna. Här är ett exempel, som förklaring.
Antag att du hittar en metod i en klass med en löjlig metrisk, till exempel en npath-komplexitet på 52 miljoner. Det betyder att det skulle ta 52 miljoner testfall att fullt ut utöva varje väg genom koden. Du kan refactor koden till en enklare struktur, men innan du gör det, överväga vad affärseffekten skulle vara. Chansen är att den gamla, fula koden fungerar tillräckligt bra (även om testdäckningen kan vara otillräcklig). Att ringa ut antimönstret till laget så att de kan undvika att upprepa det är värdefullt lärande, men att fixa det skulle förmodligen inte flytta nålen på någon relevant affärsmätning.
det är bäst om laget håller med om nivån på överensstämmelse och regler som deras kod utsätts för, men var medveten om att undersöka avvikare och bli bekymrad över trendblips kan slösa mycket tid.
lägg sedan allt ihop: Framgång är det ultimata måttet
glädjen med att använda automatiserade verktyg för att spåra och mäta kvalitetsmått och användaranalys är att det frigör tid att fokusera på de mätvärden som verkligen betyder något: framgångsmått.
hur man använder mätvärden för framgång
företag har mål. Mål innebär frågor, till exempel ”hur ser framgång ut?”eller” hur kommer detta att påverka kundernas beteende?”Korrekt kvantifierade frågor innebär mätvärden.
på ett annat sätt bör mätvärden endast användas för att svara på frågor, för att testa hypoteser som stöder ett specifikt affärsmål. Och detta bör bara göras så länge frågorna och svaren hjälper till att driva positiva förändringar.
nu har inte alla projekt i allmänhet någon uppsättning invarianta mål, Frågor och hypoteser och därmed mätvärden?
Ja, men bara ur företagets synvinkel. Åtgärder på affärsnivå av saker som användarengagemang, nära priser, intäktsgenerering och så vidare ger feedback om hur verksamheten gör i den verkliga världen. Ändringar av programvara som påverkar verksamheten kommer också att påverka dessa typer av mätvärden.
vid en finare upplösning kan varje funktion och användarhistoria ha sin egen framgångsmått-helst bara en och en som är direkt relaterad till ett värdemått som levereras till kunden. Att slutföra nio av tio berättelser i en sprint för funktioner som aldrig levereras är slöseri, inte framgång. Att leverera historier som kunder inte vill ha eller använder är slöseri, inte framgång. Att leverera en historia som förbättrar någon aspekt av användarnas lycka är en framgång. Att leverera en berättelse som bevisligen inte förbättrar användarnas engagemang är också en framgång, eftersom du kommer att ha lärt dig något som inte fungerade, ogiltigförklarade en affärshypotes och frigjort resurser för att driva andra vägar.
hur man formulerar en värdehypotes
en värdehypotes är ett uttalande om vad du tror kommer att hända som ett resultat av leveransen av en specifik funktion. Förhållandet mellan programvaran, det önskade resultatet och mätvärdena utgör värdehypotesen för funktionen (eller systemet, eller berättelsen eller uppgraderingen etc.). Hypotesen bör uttrycka hur det riktade måttet förväntas förändras, över vilken tidsram och hur mycket som ska anses vara effektivt. Du måste åtminstone prata med teamet och produktägaren för att ta reda på det specifika som den här funktionen eller berättelsen är avsedd att skapa eller förbättra med avseende på verksamheten för att formulera sin värdehypotes. Du kanske måste fråga ”varför” några gånger (som en treåring) för att dra tillbaka lagren av ostaterade antaganden; var tålamod. När du förstår vad affärsvärdet ska vara kan du börja ställa frågorna som leder dig till de mätvärden som svarar på frågan.
till exempel kan en ”teknisk” historia för att förbättra hastigheten på en e-handelsutcheckningsprocess ha som underliggande antagande att en snabbare utcheckning leder till mer försäljning. Men varför tror vi det? Är många människor överger sina kundvagnar under kassan? Om det är konsensus (eftersom den konsensus stöds av baslinjedata), kan värdehypotesen vara ”vi tror att en snabbare kassaprocess kommer att resultera i minskade kundvagnsövergivningshastigheter, vilket leder till högre försäljning och förbättrad användarupplevelse.”
du kan antagligen anta att användarna kommer att gilla snabbare utcheckning, men det skadar inte att fråga om de har märkt det. Kundvagn-nedläggning priser och försäljning kan mätas före och efter den nya processen är på plats, under en tidsperiod. Om vagnens övergivningsgrad sjunker och försäljningen ökar (utöver statistiska fluktuationer), stöder bevisen hypotesen och du kan överväga om ytterligare hastighetsförbättringar är motiverade. Om de inte är det, låt den här metriska blekna in i bakgrunden (eller ta bort den, om den är distraherande) och uppmärksamma nästa hypotes. Om nedläggning av kundvagn minskar men försäljningen är oförändrad, mät under en längre tid eller ompröva den antagna länken mellan nedläggning av kundvagn och försäljning. Med andra ord, använd mätvärden för att lära dig, och bara så länge de visar sig vara användbara för att driva förbättringar.
i vissa fall kan hypotesen vara klart fel, så vi släpper mätvärdena (och ångrar programändringarna!) efter några dagar. I andra fall kan hypotesen vara korrekt, så vi fortsätter att driva förbättringar på detta område i flera år.
sex heuristik för effektiv användning av mätvärden
vi har sett hur subjektiva mjukvarumätvärden betyder mycket mer för affärsframgång än de traditionella, objektiva kvalitetsmätarna för gamla. Den ansträngning som krävs för att hitta och mäta relevanta affärsmätningar för funktioner uppvägs av de insikter och inlärningsmöjligheter som uppnåtts. Affärsförhållanden och möjligheter förändras ständigt, så snarare än att sammanfatta en formel att följa, som kan vara ömtålig, här är sex tumregler, eller heuristik, för att upprätthålla fokus och flexibilitet. Må de hjälpa dig på din resa till kvalitetsprogramvara och affärsframgång!
- Metrics kan inte berätta historien; bara laget kan göra det (med ett hatttips till Todd DeCapula).
- att jämföra snöflingor är slöseri.
- du kan mäta nästan vad som helst, men du kan inte vara uppmärksam på allt.
- Business success metrics Driver programvaruförbättringar, inte tvärtom.
- varje funktion lägger till värde; antingen mäta det eller gör det inte.
- mät bara det som är viktigt nu.