Förstå tid till kvalitet
Det finns gott om mätvärden som används för att följa framstegen inom kvalitetssäkring idag. De flesta av dem är ganska användbara, men de tenderar alla att vara endimensionella, i den bemärkelsen att de är ögonblicksbilder av en tidpunkt eller sprint. Detta gäller även takt- och trendmätvärden, som är oerhört viktiga men återigen är ögonblicksbilder i tiden.
När jag arbetade på Symantec lade jag märke till detta:
Det fanns många mätvärden som användes för att fastställa den nivå av kvalitet som (förmodligen) hade uppnåtts vid leveransdatumet. Men inga mätvärden samlades in, vare sig under processen eller i efterhand, för att mäta kostnaden för att uppnå denna kvalitet.
Med andra ord brydde vi oss inte om hur effektivt den kvaliteten uppnåddes under projektets livslängd.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Din produkt kanske levererades med hög kvalitet, men behövde det verkligen ta så mycket tid och ansträngning att uppnå den?
Detta är en effektivitetsfråga, inte en kvalitetsfråga i sig, men de två hänger mycket nära samman.
Skärningspunkten mellan kvalitet och effektivitet
Kvalitet och effektivitet möts eftersom en av de främsta orsakerna till att programvaruprojekt ofta överskrider sin fastställda tidsplan avsevärt (och detta kommer ofta som en oväntad “överraskning” i projektets slutfas) är bristande kodkvalitet. Inte bara den ursprungliga kodkvaliteten, utan under hela projektet.
En annan orsak, som egentligen bara är en oundviklig konsekvens av bristande kodkvalitet, är defekter som kräver flera försök till korrigering och sträcker sig över flera testomgångar eller sprintar innan defekten faktiskt åtgärdas. Om den alls gör det.
Dessa ändlösa iterationer av korrigering, testning och nya misslyckanden lägger till oräkneliga personveckor i nästan alla programvaruprojekt.
Ändå fångas detta misslyckandemönster, intressant nog, inte specifikt i några andra projekt- eller kvalitetsmätvärden som jag har sett. Eftersom alla dessa mätvärden, som nämnts ovan, är ögonblicksbilder i tiden och därför inte fångar detta fenomen.
Det slog mig att det fanns ett enkelt sätt att fånga detta misslyckandemönster. Jag kom på ett mätvärde som jag kallade ”Tid till kvalitet”, eller TTQ.
Introduktion av ett nytt mätvärde: Tid till kvalitet (TTQ)
Själva mätvärdet är ganska enkelt. Det fungerar så här:
För varje testomgång (oavsett hur den definieras), följ inte bara hur många tester som klarade eller inte klarade testet, utan också hur många tester som klarade testet vid första försöket. Och hur många som krävde två, tre eller fler försök innan samma tester slutligen klarade testet.
Som ett enkelt exempel: om du körde 20 tester och 5 av dem klarade testet vid första försöket är ditt TTQ-förhållande 25 %. Ju högre siffran är, desto bättre. Det är en enkel, beräkningsbar och lättillgänglig indikator på din övergripande kodkvalitet.
Detta mätvärde är en mycket god indikation på den ursprungliga kodkvaliteten.
Det beror på att ju högre kodkvaliteten är, desto färre gånger behöver du kontrollera ett test mot den innan det klarar testet. Och tvärtom. Detta mätvärde är mycket mer exakt än antal buggar och trender.
TTQ är också ett oerhört användbart mätvärde för projektuppföljning.
Om till exempel 70 % av testerna klarade testet vid din första testomgång och 30 % misslyckades, kan du rimligen anta att projektet fortfarande följer tidsplanen. Men om säg bara 20 % av dina tester klarade testet vid första körningen, då är du, för att uttrycka det i tekniska termer, ”Flicka, du är illa ute! ”
Detta innebär att du faktiskt inte genomförde en lyckad första testomgång. Och den tiden måste läggas tillbaka i en framtida testomgång som en kvalitetsskuld.
TTQ-mätvärdet är extremt användbart som det jag brukar kalla ett ”snubbeltrådsmätvärde”.
Om du använder det konsekvent ger det mycket exakta data som gör det möjligt för projektledaren att avgöra om projektet håller på att spåra ur långt innan tåget faktiskt lämnar spåret.
Det innebär att proaktiva åtgärder kan vidtas mycket tidigare för att återfå kontrollen. På så sätt undviker man pinsamma erkännanden mycket sent i processen om att projektets tidsplan ligger i spillror. Med andra ord: använd ett TTQ-tröskelvärde för att definiera om projektet fortfarande är grönt, befinner sig i gult läge eller är på väg att bli rött. Gör det till en integrerad del av själva projektstatusen.
För låt oss inse det: en av de ständigt återkommande patologierna i programvaruutvecklingsinsatser är ett ihållande förnekande av att saker håller på att gå fel, och dessutom på ett allvarligt sätt, när det först blir uppenbart att så är fallet. Alla är rädda för att stämplas som ”negativa”, eller för att andra ska tro att de helt enkelt är för lata eller oengagerade för att åtgärda problemen, eller att de inte är en ”lagspelare”. Parallellen till dysfunktionella familjer är obehagligt tydlig.
Detta förnekande och denna undertryckning av det som alla vet egentligen pågår skapar ett misslyckandemönster där man vägrar erkänna att projektet ligger långt, långt efter tidsplanen förrän i allra sista minuten.
När detta inte längre kan döljas för den högsta ledningen tjänar den ovälkomna överraskning som detta skapar för dem bara till att undergräva, ibland permanent, deras förtroende för sina egna utvecklingsteam. Och vem kan klandra dem?
Men om du konsekvent införlivar TTQ i dina mätvärden och din projektledning—och agerar utifrån vad mätvärdet säger dig—kan du undvika detta.
Att mäta tid till kvalitet avpersonifierar beslutet att erkänna att tidsplans- och kvalitetsrisker byggs upp i projektet redan under de tidigaste faserna.
Det blir mycket enkelt och entydigt, en fråga om siffror. Inte en fråga om personligt hjältemod, vilket ofta innebär en stor kostnad för personen.
TTQ-måttet är också mycket användbart för ett projekts retrospektiv/efteranalys.
Det gör det möjligt för teamet att exakt fastställa vilka delar av koden som var och förblev svaga under hela projektet. Och därigenom hur effektivt teamet var på att producera kvalitet som sådan. Eller hur dyrt det var.
Det här är en fråga som i stor utsträckning undviks i projektretrospektiv. Dels för att team saknar det begreppsliga ordförrådet för att formulera den, dels för att det ofta är politiskt känsligt att påpeka att ingenjörsteamet konsekvent producerat kod av dålig kvalitet.
Sammanfattning
TTQ kommer att ge dina projekt en enorm transparens och förutsägbarhet till nästan ingen kostnad i tid eller arbete, eftersom det helt enkelt är en metaanalys av mätvärden som du redan samlar in.
Jag har använt TTQ i mina QA-projekt i två decennier, och det har fått ett brett gehör bland de projektledare jag har utbildat i metoden, av alla de skäl som nämns ovan.
Prova det, så får ni se själva. Det kommer verkligen att förändra spelplanen för ert team. Som alltid önskar jag er lycka till.
P.S. Om du vill höra fler erfarenheter från fältet och få veta mer om bakgrunden till TTQ pratade jag med Jonathon Wright i QAL-podden.
