Forstå tid til kvalitet

Det finnes mange måltall som brukes til å følge fremdriften i kvalitetssikringen i dag. De fleste av dem er ganske nyttige, men de har alle en tendens til å være endimensjonale, i den forstand at de er øyeblikksbilder av et tidspunkt eller en sprint. Dette gjelder også måltall for frekvens og trender, som er utrolig viktige, men som igjen er øyeblikksbilder i tid.

Da jeg jobbet i Symantec, la jeg merke til dette:

Det ble brukt mange måltall for å fastslå nivået på kvaliteten som (angivelig) var oppnådd innen leveringsdatoen. Men det ble ikke samlet inn noen måltall, verken underveis eller retrospektivt, for å måle kostnaden ved å oppnå denne kvaliteten.

Med andre ord, vi brydde oss ikke om hvor effektivt denne kvaliteten ble oppnådd gjennom prosjektets levetid.

Produktet ditt kan ha blitt levert med høy kvalitet, men måtte det ta så mye tid og innsats å oppnå den?

Dette er et spørsmål om effektivitet, ikke egentlig et kvalitetsspørsmål, men de to henger svært tett sammen.

Skjæringspunktet mellom kvalitet og effektivitet

Kvalitet og effektivitet møtes fordi en av hovedgrunnene til at programvareprosjekter ofte går betydelig over den avtalte tidsplanen (og dette kommer ofte som en uventet «overraskelse» i prosjektets sluttfase), er dårlig kodekvalitet. Ikke bare den innledende kodekvaliteten, men gjennom hele prosjektet.  

En annen grunn, som egentlig bare er en uunngåelig konsekvens av dårlig kodekvalitet, er feil som krever flere forsøk på retting, fordelt over flere testrunder eller sprinter før feilen faktisk blir rettet. Hvis den i det hele tatt blir det.  

Disse endeløse iterasjonene med retting, testing og nye feil legger til utallige personuker i nesten alle programvareprosjekter.

Likevel blir dette feilforløpet interessant nok ikke fanget opp særskilt i noen andre prosjekt- eller kvalitetsmåltall jeg har sett. For som nevnt ovenfor er alle disse måltallene øyeblikksbilder i tid, og de klarer derfor ikke å fange opp dette fenomenet.

Det slo meg at det fantes en enkel måte å fange opp dette feilforløpet på. Jeg kom frem til et måltall jeg kalte «Tid til kvalitet», eller TTQ.

Introduksjon av et nytt måltall: Tid til kvalitet (TTQ)

Selve måltallet er ganske enkelt. Det fungerer slik:

For hver testrunde (uansett hvordan den er definert) skal du ikke bare følge med på hvor mange tester som besto eller feilet, men også hvor mange tester som besto ved første forsøk. Og hvor mange som krevde to, tre eller flere forsøk før de samme testene til slutt besto.

Som et enkelt eksempel: Hvis du kjørte 20 tester og 5 av dem besto ved første forsøk, er TTQ-forholdet ditt 25 %. Jo høyere tallet er, desto bedre. Det er en enkel, beregnbar og lett tilgjengelig indikator på den samlede kodekvaliteten.

Dette måltallet er en svært god indikasjon på den innledende kodekvaliteten.

Det skyldes at jo høyere kvalitet koden har, desto færre ganger må du kjøre en test mot den før den består. Og omvendt. Dette måltallet er langt mer nøyaktig enn antall feil og trender.

TTQ er også et utrolig nyttig måltall for prosjektoppfølging.

Hvis for eksempel 70 % av testene besto i den første testrunden, og 30 % feilet, kan du med rimelighet anta at prosjektet fortsatt følger tidsplanen. Men hvis bare 20 % av testene besto i første runde, så er du, for å si det med tekniske termer, «Jenta mi, du er i trøbbel! »

Det betyr at du faktisk ikke gjennomførte en vellykket første testrunde. Og den tiden må legges til igjen i en fremtidig testrunde som kvalitetsgjeld.

TTQ-måltallet er ekstremt nyttig som det jeg liker å kalle et «snubletråd»-måltall.

Hvis du bruker det konsekvent, gir det svært nøyaktige data som gjør det mulig for prosjektlederen å se om prosjektet er i ferd med å spore av, lenge før toget faktisk forlater sporet. 

Det betyr at forebyggende tiltak kan iverksettes langt tidligere for å få ting under kontroll igjen. Da unngår man pinlige innrømmelser svært sent i prosessen om at prosjektplanen er i filler. Med andre ord: Bruk en TTQ-terskel til å definere om prosjektet fortsatt er grønt, gult eller i ferd med å bli rødt. Gjør den til en integrert del av selve prosjektstatusen.

For la oss innse det: En av de vedvarende svakhetene i programvareutviklingsarbeid er en vedvarende fornektelse av at ting går galt, og i stor grad, når det først blir åpenbart at dette er tilfelle. Alle er redde for å bli stemplet som «negative», eller for at de bare er for late eller lite engasjerte til å fikse ting, eller ikke er en «lagspiller». Parallellen til dysfunksjonelle familier er ubehagelig tydelig.

Denne fornektelsen og undertrykkelsen av det alle vet faktisk foregår, skaper et feilforløp der man nekter å erkjenne at prosjektet ligger langt, langt etter tidsplanen helt til siste øyeblikk.

Når dette ikke lenger kan skjules for toppledelsen, bidrar den uvelkomne overraskelsen dette skaper for dem bare til å svekke, noen ganger permanent, deres tillit til sine egne utviklingsteam. Og hvem kan klandre dem?

Men hvis du konsekvent innarbeider TTQ i måltallene og prosjektstyringen—og handler ut fra det måltallet forteller deg—kan du unngå dette.

Måling av tid til kvalitet gjør beslutningen om å erkjenne at tidsplan- og kvalitetsrisikoer bygger seg opp i prosjektet i de tidligste fasene, upersonlig.

Det blir svært klart og tydelig, et spørsmål om tall. Ikke et spørsmål om personlig heltemot, som ofte har store kostnader for personen. 

TTQ-målingen er også svært nyttig for prosjektets retrospektiv/etteranalyse.

Den gjør det mulig for teamet å finne nøyaktig hvilke deler av koden som var, og forble, svake gjennom hele prosjektet. Og dermed hvor effektivt teamet var til å produsere kvalitet på denne måten. Eller hvor kostbart det var.

Dette er et spørsmål som i stor grad unngås i prosjektretrospektiver. Delvis fordi teamene ikke har det begrepsmessige vokabularet som trengs for å formulere det, og delvis fordi det ofte er politisk følsomt å påpeke vedvarende dårlig kodekvalitet i utviklingsteamet.

Oppsummert

TTQ vil gi prosjektene deres enorm åpenhet og forutsigbarhet, med nesten ingen kostnad i tid eller innsats, siden det ganske enkelt er en metaanalyse av måltall dere allerede samler inn.

Jeg har brukt TTQ i QA-prosjektene mine i to tiår, og det har fått bred aksept blant prosjektledere jeg har lært opp i metoden, av alle grunnene som er nevnt ovenfor.

Prøv det, så vil dere se selv. Det vil virkelig bli en avgjørende faktor for teamet deres. Som alltid, lykke til.

PS. Hvis du vil høre flere røverhistorier og få vite mer om årsakene bak TTQ, snakket jeg med Jonathon Wright på QAL Podcast.