Det agile manifest blev skabt for 20 år siden, og med den kom også de 12 agile principper. I konteksten af denne artikel, er det især det første princip der har fokus:
Vores højeste prioritet er at stille kunden tilfreds gennem tidlige og løbende afleveringer af værdifuld software
Efter 20 år kunne man forestille sig, at dette er blevet til en solid fremgangsmåde og fokus i agile teams. Jeg kan dog ikke lad være med at tænke:
- Ved teams og projekter godt hvorfor de bygger dét, de bygger?
- Ved de, hvilken forskel de gør for modtagerne af løsningen?
- Ved de, hvilken værdi det vil have for slutbrugeren?
Min oplevelse er, at der stadigvæk er en del projekter og teams, der ikke helt har mestret det fokus. Vi taler selvfølgelig om kvalitet, som i ”vi har brug for god kvalitet i vores løsning”, ”vores kunder forventer høj kvalitet” osv, men hvad ”god kvalitet” betyder, har vi ikke rigtigt et klart billede af – udover; ingen alvorlighed 1 og 2, og højest 19 alvorlighed 3 fejl, når produktionen begynder … og lignende.
Med andre ord er der stadig brug for en diskussion internt i teamet og med interessenter. Dette er ikke åbenlyst for alle – og I har ikke nødvendigvis det samme billede. Det er aldrig for sent at begynde, hvis ikke i har haft diskussionen endnu.
Hvad er kvalitet?
Der er mange forskellige formelle definitioner på kvalitet f.eks. ISO25010 der fastslår flere forskellige kvalitets egenskaber alt efter, hvorvidt der er tale om produkt kvalitet eller kvalitet i brug. Men Gerald Weinberg havde en meget simpel definition af kvalitet, som jeg godt kan lide og som senere blev beriget af både James Bach og Michael Bolton:
Quality Is Value to Some Person, At Some Time, Who Matters
Så for at få en idé om, hvad kvalitet er i din kontekst, er det første punkt på dagsordenen at finde ud af, hvem de mennesker der betyder noget er. Slutbrugere, kunder, produktindehavere, marketing, salg, support osv. har alle en idé om, hvad værdi betyder for dem, men afhængigt af din kontekst skal du identificere det rigtige sæt interessenter at diskutere med.
Men når du har en idé om, hvem de er, så kan du begynde at diskutere, hvilken værdi der er for dem, og det bringer mig til VOICE -modellen.
VOICE-modellen
I bogen “Quality for DevOps Teams” (TMAP®) blev jeg introduceret til VOICE -modellen for første gang. Med VOICE -modellen får du en tilgang til at få snakken med de “mennesker, der betyder noget” om, hvad de forventer. Gør målene målbare som kvantificerbare delmål og brug dem som pejlemærker til at finde ud af, om du leverer den værdi, interessenterne forventer at modtage.
Lad os se på modellen. Formålet med VOICE -modellen er at fastslå graden af tillid til, at den forfulgte forretningsværdi kan opnås. Modellen består af 5 termer;
Value, Objectives, Indicators, Confidence and Experience.
(c) Sogeti
Jeg har tilladt mig at lade modellen være engelsk for at være tro mod forkortelsen ?
Value: Uanset hvad du udvikler, er det meningen at det skal tilføre værdi til nogen et eller andet sted. Denne værdi skal være defineret og synlig for dig, og i processen med at definere den sammen med vores interessenter vil du ofte identificere implicitte forventninger til løsningerne og have mulighed for at gøre dem eksplicitte, når du definerer den forfulgte værdi.
Objectives: Med kendskabet til den forventede værdi skal du oversætte dem til kvantificerbare delmål for korrekt at forstå systemets formål.
Indicators: Som et team har du brug for en måde at måle, om disse delmål nås, og dermed om den forventede forretningsværdi vil blive nået, dette gøres ved at identificere specifikke indikatorer, og den primære måde at måle disse indikatorer på er at udføre test af løsningen.
Confidence: Med output fra test, måling af indikatorer kan du levere information til dine interessenter, så de kan få tillid til, om løsningen vil give den forventede værdi.
Experience: Uanset hvor mange indikatorer du har, er det bedste sted at finde ud af, om systemet giver den forventede værdi ved at få erfaring, ved at bruge systemet i praksis. Baseret på slutbrugernes praktiske erfaring med den operationelle brug af systemet får du feedback, og du kan også identificere yderligere områder, der skal forbedres, og dette vil derefter igen udløse en ny cyklus af VOICE -modellen – den såkaldte værdiforbedringssløjfe.
Sådan bruger du VOICE-modellen
Én ting er teori og modeller, men hvordan bruges det i praksis? Mit forslag ville være; når du starter en ny iteration, et nyt projekt, et nyt trin, en ny funktion – uanset hvilket niveau der passer bedst til din kontekst, start det med denne diskussion, når du identificerer omfanget. Få en solid – og FÆLLES forståelse af omfanget, og hvilken værdi det skal bringe, og ikke kun det praktiske ved hvad funktionerne skal gøre med hensyn til funktionalitet.
Et par eksempler på mål kan være:
“Vi vil give vores salgsmedarbejdere en bedre og mere effektiv måde at registrere ordrer i en virksomhed-til-virksomhed-del af vores virksomhed.”
eller
“Vi vil give vores kunder mulighed for at betale for deres ordrer med et kreditkort”
Begge er realistiske mål for et nyt ordresystem, men det kan være lidt svært at måle. Så du skal tage dem et skridt videre – og lave målbare delmål.
For det første mål kunne delmålene være:
- Bestillingsregistrering skal kun være mulig ved brug af tastatur (mere effektivt)
- Valideringsregler kan konfigureres for alle felter i ordrevinduet
For det andet mål kunne delmålene være:
- Det skal være muligt at betale med følgende kreditkort: Visa, Master Card, American Express
- Betalingen skal inkludere kreditkortselskabets verifikationsmetode.
- Betaling med kreditkort bør ikke tage længere tid, som andre betalinger tager.
Disse delmål kan også bruges som grundlag for din kvalitetsrisikoanalyse, hvilket gør det muligt for dig at visualisere kvalitetsrisikoen i forbindelse med hver, men vigtigst af alt; med de definerede mål kan du nu angive de indikatorer, der er nødvendige for at kontrollere, om målene er opfyldt eller ej. Et par anbefalinger relateret til indikatorerne: Hav ikke for mange indikatorer, et sted mellem 5 og 10 bør være det maksimale antal (Med en præference for det lavere antal ?). Indikatorer bør aldrig være et statisk sæt, genovervej dine indikatorer regelmæssigt for at være sikre på, at du har det rigtige fokus – måske hver tredje måned eller deromkring.
Et par eksempler på indikatorer, der kan understøtte kommunikationen omkring opfyldelse af delmål, kan være:
-
- IT -relaterede indikatorer:
-
- Test bestået/ikke bestået -ratio (Organiser testen, så målene kan identificeres ud fra dem, f.eks. en testpakke, der håndterer valideringsreglerne for det første mål, og en dækker navigation. For det andet mål skal du overveje at organisere testcases pr. kreditkorttype)
- Kvalitetsrisici formindskes i forhold til identificeret kvalitetsrisiko (brug som nævnt målene som input til din kvalitetsrisikoanalyse, hvilket gør det muligt at kommunikere målrettet mod hver af disse).
-
Problemrelaterede indikatorer:
-
- Antal defekter identificeret i testen grupperet i forhold til målene
- Middel tid til at undersøge og rette fejl i forhold til aftalt niveau
Så hvis du ser på indikatorerne ovenfor, er de ikke så forskellige fra det, du er vant til. Men den måde, du organiserer datafundamentet for dem på, er afgørende for at kunne kommunikere om tilstanden for hvert delmål.
Som en del af testen kan du nu dokumentere resultatet af indikatorerne og kommunikere resultatet til dine interessenter for at give dem grundlag for at beslutte, om de har tillid til løsningen og er klar til at sende det i produktion.
Med denne tilgang skaber du en rød tråd fra vores interessenters mål og værdier, til de indikatorer, du bruger til at evaluere den skabte løsning, og kan kommunikere med vores interessenter baseret på disse mål/værdier frem for at bruge et standardsæt af målinger, som genbruges fra projekt til projekt. Brug VOICE -modellen til at sikre en værdidrevet tilgang til udvikling og test, og sikre, at det, dine interessenter virkelig har brug for, er centrum for opmærksomheden i teamet i løbet af hele livscyklussen.