Forståelse af tid til kvalitet

Der findes i dag masser af målinger, der bruges til at følge udviklingen inden for kvalitetssikring. De fleste af dem er ganske nyttige, men de har alle en tendens til at være endimensionelle, i den forstand at de er øjebliksbilleder af et tidspunkt eller en sprint. Det gælder endda for målinger af hastighed og tendenser, som er utroligt vigtige, men som igen er øjebliksbilleder.

Da jeg arbejdede hos Symantec, bemærkede jeg dette:

Der blev anvendt mange målinger til at fastslå det niveau af kvalitet, der angiveligt var opnået ved leveringsdatoen. Men der blev ikke indsamlet nogen målinger, hverken under processen eller retrospektivt, for at måle omkostningen ved at opnå denne kvalitet.

Med andre ord var vi ligeglade med, hvor effektivt denne kvalitet blev opnået gennem hele projektets levetid.

Dit produkt er måske blevet leveret med høj kvalitet, men behøvede det at kræve så meget tid og arbejde at opnå den?

Dette er et spørgsmål om effektivitet, ikke i sig selv et spørgsmål om kvalitet, men de to ting hænger i høj grad sammen.

Skæringspunktet mellem kvalitet og effektivitet

Kvalitet og effektivitet mødes, fordi en af de væsentligste årsager til, at softwareprojekter ofte overskrider deres aftalte tidsplan betydeligt (og dette kommer ofte som en uventet “overraskelse” i projektets afsluttende fase), er dårlig kodekvalitet. Ikke kun den indledende kodekvalitet, men gennem hele projektet.  

En anden årsag, som egentlig blot er en uundgåelig konsekvens af dårlig kodekvalitet, er defekter, der kræver flere forsøg på rettelser og strækker sig over flere testgennemløb eller sprint, før defekten rent faktisk bliver rettet. Hvis det overhovedet.  

Disse endeløse gentagelser med rettelser, test og nye fejl tilføjer utallige personuger til næsten alle softwareprojekter.

Alligevel bliver dette fejlmønster interessant nok ikke særskilt registreret i nogen af de andre projekt- eller kvalitetsmålinger, jeg har set. For som nævnt ovenfor er alle disse målinger øjebliksbilleder, og de formår derfor ikke at opfange dette fænomen.

Det slog mig, at der var en enkel måde at opfange dette fejlmønster på. Jeg fandt på en måling, som jeg kaldte “Tid til kvalitet”, eller TTQ.

Introduktion til en ny måling: Tid til kvalitet (TTQ)

Selve målingen er ganske enkel. Den fungerer sådan:

For hvert testgennemløb (uanset hvordan det defineres) skal du ikke blot registrere, hvor mange test der bestod eller fejlede, men også hvor mange test der bestod i første forsøg. Og hvor mange der krævede to, tre eller flere forsøg, før de samme test endelig bestod.

Som et enkelt eksempel: Hvis du kørte 20 test, og 5 af dem bestod i første forsøg, er dit TTQ-forhold 25 %. Jo højere tallet er, desto bedre. Det er en enkel, beregnelig og let tilgængelig indikator for din overordnede kodekvalitet.

Denne måling er en meget god indikation af den indledende kodekvalitet.

Det skyldes, at jo højere kodekvaliteten er, desto færre gange skal du teste den, før testen består. Og omvendt. Denne måling er langt mere præcis end optællinger af fejl og tendenser.

TTQ er også en utroligt nyttig måling til opfølgning på projektet.

Hvis 70 % af testene for eksempel bestod i dit første testgennemløb, og 30 % fejlede, kan du med rimelighed antage, at dit projekt stadig følger tidsplanen. Men hvis kun 20 % af dine test bestod i første gennemløb, så er du, for at sige det med tekniske termer, "Skat, du er i problemer! "

Det betyder, at du faktisk ikke gennemførte et vellykket første gennemløb. Og den tid skal føjes til et fremtidigt gennemløb som kvalitetsgæld.

TTQ-målingen er ekstremt nyttig som det, jeg ynder at kalde en "alarmtrådsmåling".

Hvis du bruger den konsekvent, giver den meget præcise data, som gør det muligt for projektlederen at afgøre, om projektet er ved at løbe af sporet, længe før toget faktisk forlader sporet. 

Det betyder, at der kan træffes proaktive foranstaltninger langt tidligere for at få tingene under kontrol igen. Dermed undgår man pinlige indrømmelser meget sent i forløbet om, at projektplanen er i laser. Med andre ord: Brug en TTQ-tærskel til at definere, om projektet stadig er grønt, gult eller er på vej til at blive rødt. Gør den til en integreret del af selve projektstatussen.

For lad os se det i øjnene: En af de vedvarende dysfunktioner i softwareudviklingsindsatser er den konstante benægtelse af, at tingene går galt, og endda i stor stil, når det først bliver tydeligt, at det er tilfældet. Alle er bange for at blive stemplet som “negative”, eller for at andre skal tro, at de blot er for dovne eller uengagerede til at rette op på tingene, eller at de ikke er en “holdspiller”. Parallellen til dysfunktionelle familier er ubehageligt tydelig.

Denne benægtelse og undertrykkelse af det, som alle ved rent faktisk foregår, skaber det fejlmønster, at man nægter at anerkende, at projektet er langt, langt bagud i forhold til tidsplanen, indtil det allersidste øjeblik.

Når dette ikke længere kan skjules for den øverste ledelse, tjener den uvelkomne overraskelse, det skaber for dem, kun til at undergrave – nogle gange permanent – deres tillid til deres egne udviklingsteams. Og hvem kan bebrejde dem det?

Men hvis du konsekvent indarbejder TTQ i dine målinger og din projektstyring—og handler på det, som målingen fortæller dig—kan du undgå dette.

Måling af tid til kvalitet gør beslutningen om at erkende, at tidsplan- og kvalitetsrisici opbygges i projektet, i dets tidligste faser, upersonlig.

Det bliver meget klart og tydeligt, at det er et spørgsmål om tal. Ikke et spørgsmål om personligt heltemod, som ofte kommer med store omkostninger for personen. 

TTQ-metrikken er også meget nyttig i forbindelse med et projekts retrospektiv/efteranalyse.

Det giver teamet mulighed for at identificere præcis, hvilke dele af koden der var og forblev svage gennem hele projektet. Og dermed hvor effektivt teamet var til at producere kvalitet som sådan. Eller hvor dyrt det var.

Dette er et spørgsmål, som i vid udstrækning undgås i projektretrospektiver. Dels fordi teamene ikke har det begrebsmæssige ordforråd til at formulere det, dels fordi det ofte er politisk følsomt at påpege konsekvent dårlig kodekvalitet fra udviklingsafdelingen.

Sammenfatning

TTQ vil give enorm gennemsigtighed og forudsigelighed i jeres projekter til næsten ingen omkostninger i tid eller indsats, eftersom det blot er en metaanalyse af målinger, som I allerede indsamler.

Jeg har brugt TTQ i mine kvalitetssikringsprojekter i to årtier, og det har vundet bred accept blandt de projektledere, jeg har oplært i det, af alle de ovenfor nævnte årsager.

Prøv det, så vil I selv se resultatet. Det vil virkelig ændre spillereglerne for jeres team. Som altid ønskes I held og lykke.

P.S. Hvis I vil høre flere krigshistorier og årsagerne bag TTQ, talte jeg med Jonathon Wright i QAL Podcast.