Fokus på softwarekvalitet? Du gør det forkert
Kan det virkelig lade sig gøre?
Hvad nu hvis du kunne levere endnu højere softwarekvalitet og samtidig gøre det hurtigere?
Kvalitet af software er en svær størrelse at kvantificere, fordi kvalitet kan anskues og måles på rigtig mange måder. Derfor vil jeg ikke forsøge at definere, hvad kvalitet af software er.
I stedet vil jeg præsentere en overordnet strategi, der er løsningen på en vifte af softwarekvalitets-problemer, uden at du går ned i leverancehastighed. Vi er faktisk selv gået væsentlig op i hastighed ved hjælp af strategien.
Brændt barn skyr ilden
Hvis vi lader det at brænde sig på ild være en metafor for det at blive ramt af dårlig software kvalitet, så kan man reagere forskelligt på at blive brændt.
Brændt barn skyr, som vi ved, ilden. Barnet har faktisk fundet en opskrift på at opnå den perfekte softwarekvalitet.
Hvis du for eksempel har et problem med, at der sker regressioner (fejl), når du deploy'er nye features til produktion, så vil barnets reaktion være at holde op med at lave nye features. I stedet vil 'det forsigtige barn' kun lave fejlrettelser, og således til sidst ende i en situation hvor der aldrig er problemer med regressioner.
Barnets forsigtighed findes også i mindre drastiske udgaver, i udviklingsafdeliger med ensidig fokus på kvalitet. Symptomerne er:
- Længere og grundigere test-faser
- Tungere og mere kompleks udviklingsproces
- Mere tid brugt på analyse
- Flere møder
- Gates og kontroller der skal udføres
- Længere tid mellem releases
- Svært at få taget beslutninger
Når jeg holder foredrag, om hvordan vi deploy'er til produktion ti gange om dagen, kommer der desperate udviklere fra store dansk virksomheders IT-udviklingsafdelinger op til mig, og fortæller at de bruger 80% af deres tid på møder, mens de kun bruger 20% af deres tid på rent faktisk at udvikle.
Det er 'det forsigtige barns' virksomhed i dets værste variant.
Det er ikke sjovt at være udvikler i den type virksomhed. Udviklere vil udvikle, ikke holde møder. Mange af de gode medarbejdere smutter. De gode, der bliver, holder man på med meget høje lønninger og andre dyre tiltag, der skal få udviklerne til at holde ud at være virksomheden.
Virksomhedens strategi er håbløs. I en verden hvor udviklingen går hurtigere og hurtigere og konkurrenterne står på spring for at snuppe dine kunder, dur det ikke at levere langsommere og langsommere.
Du skal være en vildhest
Vildhesten har fundet en måde at overleve en steppebrand.
I stedet for at løbe væk fra steppebranden, løber vildhesten imod den og gennem den og sådan overlever den. I eksemplet med problemer med regressioner når en ny feature deploy'es til produktion, vil vildhestens strategi være at deploy'e til produktion oftere.
Hvis det gør ondt, så gør det oftere. Det er den stategi, du skal bruge, for at få løst dine problemer med softwarekvalitet. For kun ved at gøre det der gør ondt værre, kan du overvinde det og komme ud på den anden side.
Hvis du for eksempel har en manuel smoke-test, som er tung og langsom, så beslut at udføre testen ti gange så ofte, som du gør i dag. Det vil tvinge dig til at gøre den mindre tung og automatisere dele af den.
Ensidigt fokus på kvalitet er direkte skadeligt
Hvis din virksomhed siger, at der skal være fokus på kvalitet og lader det stå alene, så er det 'det forsigtige barn', der taler. Fokus på kvalitet skal ikke stå alene.
Hvis fokus på kvalitet står alene, vil du få indført kvalitets-kontroller, der gør dig langsommere. Alle bliver mere forsigtige og begynder at overanalysere. Der kan nemt komme en tendens til at overvurdere risici. Det bliver svært for den enkelte at tage ansvar, fordi det involverer flere og flere mennesker, gates og kontroller.
Det ironiske er, at jo langsommere du leverer, jo mere daler din kvalitet. Martin Fowler mener ligefrem, at det er en eksponentielt stigende kurve. Jo langsommere, jo mere gør det ondt.
Ensidigt fokus på kvalitet er ikke bare uambitiøst, det er direkte skadeligt.
Du skal gå efter at levere bedre kvalitet hurtigere
Det mål vi har sat op i vores udviklingsafdeling er, at vi skal levere bedre kvalitet hurtigere.
Det er meget vigtigt, at vi ikke skal levere hurtigere ved at stresse, overarbejde og knokle mere. Det skal gå hurtigere ved, at vi arbejder mere intelligent.
Bedre kvalitet alene er ikke svært. Det problem har det forsigtige barn løst og samtidig kørt virksomheden i sænk.
Men at levere bedre kvalitet, og samtidig gøre det hurtigere uden at knokle mere, se det er svært! Og det er de svære udfordringer, der er de sjoveste.
At levere bedre kvalitet hurtigere kræver at alle i udviklingsafdelingen bidrager til at opnå dette fælles mål. Det er en vision og et fokus, vi skal dele og arbejde hen imod sammen, ellers vil det ikke lykkes.
Tjekliste for kvalitetsforbedringer
Når vi vurderer en ny måde at højne vores softwarekvalitet på, holder vi den op mod en tjekliste af røde flag. Tjeklisten af røde flag er ting vi ved, gør udviklingen langsommere, hvis vi gør mere af det. Tjeklisten er:
- Manuelle processer som:
- Manuelle tests
- Kodereviews
- Møder
- Ventetid eller køer
- Afhængigheder af andre afdelinger
- Afhængigheder af kollegaer
- Handovers, at videregive ansvaret for en opgave til en anden person
- Gates - ting du skal gøre
- Grim kode - spaghetti
- Mere kode, højere kompleksitet
- Stort scope af opgaver
Vi siger ikke, at alle tingene på listen er forbudte. Vi er for eksempel store tilhængere at kodereview.
Vi har dog ændret vores udviklingsprocess, så kodereview ikke er obligatorisk, men udvikleren i stedet selv vurderer, hvornår der er brug for det. Således har vi reduceret mængden af kodereview uden at gå på kompromis med kvaliteten. Kodereview er på listen, fordi det er en dyr manuel process. Derfor har vores reduktion af kodereview sat vores leverance-hastighed i vejret.
Enhver ændring af vores udviklingsproces holdes op imod listen. Hvis der er røde flag, vil vi forsøge at gøre noget ved det.
Hvis vi for eksempel indfører en afhængighed af en anden afdeling, prøver vi at fjerne afhængigheden ved at tage noget ansvar.
Fordelingen af ansvar, med tilhørende beslutningskompetence, er en meget stor del af nøglen til at levere hurtigere og med bedre kvalitet. Udfra tjeklisten følger det, at det er en kæmpe fordel at gøre den enkelte udvikler mere autonom, og samtidig, på niveauet over det, gøre det enkelte team mere autonomt.
Sig nej til tiltag, der nedsætter din leverancehastighed
Hvis vi har et forslag til at forbedre vores software-kvalitet, ved en ændring af vores udviklingsproces, kan man groft sige, at:
- Hvis ændringen gør os langsommere, er vi slet ikke interesserede.
- Hvis ændringen gør, at vi kan levere med samme hastighed, men med bedre kvalitet, er vi mildt interesserede.
- Hvis ændringen gør, at vi kan levere hurtigere, med samme kvalitet, er vi ret interesserede.
- Hvis ændringen gør, at vi kan levere hurtigere og med bedre kvalitet, så har du vores fulde opmærksomhed.
Resultat indtil videre
Vores fokus på kvalitet og hastighed har betydet, at vores udviklere i dag kan bruge op til 90% af deres tid på at kode og levere og kun 10% af deres tid er reserveret til møder. Vi leverer med en hastighed på 140% ifht for et år siden. Samtidig registrer vi 44% færre bugs.
Den enkelte udvikler har fået meget mere ansvar og beslutningskompetence. Ændringerne er blevet godt modtaget af langt de fleste udviklere, men det har også været en svær omstilling for enkelte. Vi har lavet ændringerne langsommere end dem der er helt fremme i skoene gerne ville have og hurtigere end de mere konservative ville have. Sådan må det nødvendigvis være.
Det gode ved strategien er, at vi alle kan stå sammen om den. Selvfølgelig vil ledelsen gerne have højere kvalitet hurtigere. Men for mig er det nærmest vigtigere, at det bare er meget sjovere at være udvikler i en virksomhed, hvor du kan få noget ansvar med tilhørende beslutningskompetence, og bruger tiden på at udvikle og levere i høj kvalitet.
Arbejder du selv i en virksomhed, der er 'et forsigtigt barn' eller en vildhest? Hvor meget af din tid går rent faktisk med at udvikle?
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
