The post Rikke kombinerer sine kompetencer som testmanager med rollen som Scrum Master appeared first on Key2Quality.

The post Er testmanagement-rollen død? appeared first on Key2Quality.

Vi bruger meget ordet “kvalitet”:

• Vi har et mål om at have høj kvalitet
• Vi har et “kvalitets-mindset”
• Vi bygger kvalitet ind
• Vi måler på mange forskellige ting for at kunne fortælle/rapportere om kvaliteten

Men hvad mener vi, når vi siger kvalitet? Og mener vi det samme som kunden, slutbrugeren eller ledelsen?

Husk på det første agile princip: “Vores højeste prioritet er at tilfredsstille kunden gennem tidlig og kontinuerlig levering af værdifuld software.”

Med det i tankerne – hvorfor så ikke flytte fokus til, hvilken værdi vores kunde ønsker, med den løsning vi skaber for dem? Og så finde ud af en måde at måle, om vi leverer denne værdi?

Dét ville være interessant af flere årsager: Ifølge forskning fra McKinsey “overstiger store IT-projekter i gennemsnit budgettet med over 45 procent, de går 7 procent over tid, og de leverer 56 procent ringere værdi end forudsagt”. Derfor er det første agile princip et værdifuldt fokus for vores kunder – og for os selv – ikke kun ud fra et forretningsmæssigt værdiperspektiv, men også ud fra et økonomisk synspunkt.

Alt det vil Gitte komme meget mere ind på i sin keynote “Let’s stop talking about quality” på konferencen German Testing Day onsdag d. 24. maj 2023 kl. 9.20-10.05.
Læs mere om Gittes keynote her, og tilmeld dig konferencen her.
Obs! Der er early bird indtil 28. april!

Du behøver dog ikke at tage helt til Frankfurt for at høre Gittes foredrag. Du kan blot booke Gitte til komme ud og holde foredraget hos jer, lige når det passer jer. Book foredraget her!

The post Oplev Gittes keynote på “German Testing Day” 23.-24. maj 2023 appeared first on Key2Quality.

Nu er der så gået 20 år, siden det agile manifest, og mange kæmper stadig med udfordringen om, hvordan agile ser ud i deres kontekst. Vi har samtidig fået selskab af diverse skalerede rammeværk som SAFe®, LESS, Scrum@Scale osv. Og sideløbende med dét, har vi også erkendt, at der i nogle situationer stadig eksisterer vandfalds/v-models lignende modeller i en del organisationer, dels af nød og dels fordi det måske bare passer bedst til deres kontekst.

Hvordan skal en testmanager så se ud i dag? Hvordan skaber man en profil, der passer ind i så forskelligartede kontekster som dét? Hvilke kompetencer og evner skal der til?

I forbindelse med min præsentation på EuroStar kiggede jeg en del på de forskellige definitioner på roller, som jeg har kunnet grave frem rundt omkring, nærmere bestemt de tre roller, som er nævnt i titlen på denne artikel; testmanager, orchestrator og Quality Coach. I det følgende kommer en hurtig gennemgang af de tre.

Testmanager

Testmanager rollen er defineret i ISTQB med følgende overordnede opgaver:

• Udvikling eller review af testpolitik og teststrategi for organisationen
• Planlægning af testaktiviteter ved at overveje konteksten og forstå testformål og -risici
• Forfatning og opdatering af testplaner
• Koordinering af testplanen med projektleder, product owners og evt. andre parter
• Påvirkning af projektplanlægningen med testperspektiver, f.eks. ved planlægning af integration
• Igangsætning af analyse, design, implementering og afvikling af tests, overvågning af testens fremdrift og resultater, tjek af slutkriteriernes status (eller ”Definition of Done”) og facilitering af testafslutningsaktiviteter
• Forbereding og levering af testfremdriftsrapporter og testopsummeringsrapporter, baseret på de indsamlede oplysninger
• Tilpasning af planlægningen baseret på testresultater og -fremdrift og udførsel af alle handlinger, der er nødvendige for testkontrol
• Understøttelse af opsætning af defektstyringssystem og passende konfigurationsstyring af testware
• Introduktion af passende metrikker for måling af testfremdrift og evaluering af testens og produktets kvalitet
• Understøttelse af udvælgelse og implementering af værktøjer til at støtte testprocessen, herunder anbefaling af budget for værktøjsvalg, tildeling af tid og indsats til pilotprojekter og vedvarende support til anvendelsen af værktøjerne.
• Beslutningstagning vedrørende implementering af testmiljøer
• Fortaler for testere, testteamet og testprofessionen inden for organisationen
• Udvikling af testernes færdigheder og karriere (f.eks. ved uddannelsesplaner, performanceevaluering, coaching osv.

Alt i alt en lang række opgaver, som har til formål at sikre, at vi

1. får defineret en teststrategi og får den implementeret
2. har de kompetencer, der skal til for at kunne udleve strategi og planer
3. får fulgt op på, at ”testprojektet” så også afvikles som planlagt
4. supporterer, når der opstår problemer.

Hvis du føler, at beskrivelsen er antikveret og handler om en testmanager i et vandfald eller v-models projekt, så prøv lige at parkere den tanke indtil videre.

Orchestrator

Den anden rolle på min liste var ”orchestrator”. Jeg har valgt at bibeholde det engelske navn, da denne syllabus ikke er oversat til dansk. Rollen er blevet defineret af Sogeti i forbindelse med udviklingen af TMAP® og fokuserer på en rolle, der arbejder med at supportere test og kvalitetssikring på tværs af flere agile teams, altså en skaleret agil kontekst som f.eks. SAFe®. TMAP beskriver rollen som følger:

• Skab kontrol med kvaliteten ved implementering af ændringer i applikationskæden
• Skab og sikr gennemsigtighed, og kommuniker og kontroller på grundlag af dette
• Støt den løbende forbedringsproces
• Organiser end-to-end test
• Udfør interessentanalyser
• Estimer indsatsen for virtuelle teammedlemmer, og arranger disse aktiviteter
• Sikr værktøj til backlog og testware
• Definer og prioriter backlog for end-to-end kvalitet og test
• Organiser procesmæssig justering af features med relevante interessenter
• Organiser virtuelle teamsessioner (refinement, sprintplanlægning, sprintgennemgang mv.)
• Suppler DoD på end-to-end niveau.

Der er altså tale om en rolle, der stadig arbejder med noget af den ”klassiske testledelse” omkring teststrategi og planlægning men også med fokus på mere forebyggende aktiviteter i forhold til features samt primært med fokus på end-to-end test og kvalitetssikring på tværs af teams.

Quality Coach

Sidst men ikke mindst er der begyndt at dukke en rolle op, der kaldes ”quality coach”. Her er der ikke nogen officiel definition at finde, men Anne-Marie Charrett har defineret en rigtig god én af slagsen. Her listes en række områder, som en quality coach med fordel kan have kompetencer indenfor:

• Forandringsagent (ADKAR, Roadmap, Feedback)
• Coaching (testpraksis, motivation, samarbejde)
• Mentoring (distribuere information, rådgive)
• Facilitering (input til procesforbedring)
• Forskning (værktøjer, teknikker, tilgange)
• Rådgivning (identificere metrikker, udvikle metoder)
• Fortaler (forklare proces, kvalitet m.m.)
• Marketing (visualisere information, kommunikere udover teamet)

Detaljerne omkring de enkelte kompetenber kan du få i hendes artikel What is a quality coach? Men i denne rolle er der meget fokus på at gøre teamet i stand til at løse opgaverne omkring test og kvalitetssikring – og den testledelse, der hører med. Hun har et rigtig godt eksempel sidst i artiklen, hvor hun skriver:

Testlead udvikler teststrategi til teamet – quality coach faciliterer skabelsen af en teststrategi

Testlead er ansvarlig for testaktiviteterne – quality coach er ansvarlig for at muliggøre og forbedre testaktiviteter i teamet

Testlead rapporterer om status på test indenfor teamet eller på tværs af et antal teams – quality coach hjælper teamet med at rapportere på status på test og kontinuerlig kvalitetsforbedring på tværs af et antal teams.

Testlead er mentor/coach for andre testere – quality coach er mentor/coach for tværfunktionelle teams

Med andre ord fokuserer quality coachen på at sætte teamet i stand til at løse opgaven i stedet for at løse opgaven selv.

Betyder det så, at du skal vælge en af de tre løsninger? Det korte svar er nej, jeg ser det mere som en buffet af muligheder; her er alle mulige kompetencer, der MÅSKE er relevante for mig – det afhænger af konteksten. Hver gang jeg befinder mig i en ny kontekst, et nyt job eller et nyt projekt skal jeg derfor stoppe op og vurdere, hvilke kompetencer har jeg brug for her for at løse min opgave. Og mangler jeg nogen, jeg skal have styr på, inden der går for lang tid?

Et par eksempler:

Det store K02 projekt

Hvis jeg sidder som testmanager i et stort projekt på kundesiden af en K02 kontrakt, vil jeg nok hælde til dét, der er beskrevet om testmanageren i ISTQB. Men hvis jeg samtidig i den situation har et antal testere, som aldrig har testet før, og som nu skal sættes i stand til at gøre klar til al den accepttest, der er fastlagt i kontrakten, har jeg brug for coache dem – at hjælpe dem med at blive i stand til at løse deres opgave. Så dels skal jeg have kompetencer som mentor/coach, dels skal jeg have en grundlæggende testanalytisk faglighed, så jeg kan hjælpe dem i gang med at skrive testcases, og endelig skal jeg måske facilitere nogle workshops for at få hul på opgaven.

Den hjemmestrikkede skalerede agile model

Hvis jeg sidder i et program med et antal projekter og har ansvaret på tværs af alle projekter – og vi vel at mærke vil forsøge at køre en eller anden form for skaleret agil model (evt. hjemmestrik), vil jeg sandsynligvis tage lidt fra alle tre: Jeg skal have sat en strategi på tværs af programmet, jeg skal sandsynligvis håndtere accepttests i enden af et antal inkrementer, men jeg skal også sikre at der testes løbende i det enkelte teams – og at vi får testet end-to-end. Og hvis nu ikke jeg har testere i de teams, skal jeg coache teams til at tage opgaven selv, ligesom jeg skal have sikre, at vi får forretningen involveret i forbindelse med acceptests. Så reelt nok mest orchestrator, men med lidt fra testmanager og quality coachen også.

Et agilt projekt med 3-4 agile teams

Lad os antage, at jeg er heldig at skulle supportere et agilt ”projekt” med 3-4 agile teams, og der ikke i den sammenhæng er den store afleveringsforretning til kunden i form af formelle accepttests med den planlægning, styring og rapportering, der skal til i den kontekst. Her kan jeg som quality coach fokusere mit arbejde på at hjælpe ”mine” teams til at blive endnu bedre til at tage ejerskab i forhold til kvalitet. I starten kan det godt være, at jeg trækker lidt testmanagement kompetencer ind for at få noget startet, men stille og rolig bevæger jeg mig over til at blive mere coach og mindre manager.

Det var blot tre eksempler. Der er ikke to kontekster der er ens, og min anbefaling er, at du bruger ovenstående som inspiration til, hvordan du kan gå ind og ”fylde din tallerken ved buffeten”. Hvad er den rigtige kombination for dig – hvordan kan du bedst muligt hjælpe og skabe værdi, der hvor dit arbejdsliv er?

På vores kursusside kan du læse mere om mulighederne for at lære mere om nogle af de kompetencer, der er beskrevet her. Her kan du blandt andet finde kurset Organizing build-in quality at scale fra TMAP® der fokuserer på rollen som orchestrator, og selvfølgelig ISTQB Advanced Level Test Manager der giver dig kompetencerne til den klassiske testmanager rolle. Endnu eksisterer der ikke et quality coach kursus – her skal du ud og fange mange forskellige kompetencer, der ikke nødvendigvis er testfaglige (coaching, mentoring, facilitering), men du kan også få inspiration til den agile test til teamet via ISTQB Foundation Acceptance Testing eller TMAP: Quality for cross-functional teams

Er du i tvivl, er du velkommen til at kontakte mig på gitte@key2quality.dk, så finder vi ud af noget sammen.

The post Testmanager, orchestrator, quality coach – kært barn har mange navne appeared first on Key2Quality.

I mange agile teams er det primære fokus på den enkelte user story – det er ”pakken af brugerværdi”, vi arbejder på. Men med testbrillerne på er det vigtigt også at huske at komme op i helikopteren og tænke på kvaliteten af den samlede feature, potentielle afhængigheder til andre features mv. – og så skal der testplanlægning til. Også i agile.

Gitte Ottosen giver i denne video en lynintroduktion til, hvad testplanlægning er for en størrelse, både i forhold til det enkelte team og i en skaleret kontekst.

The post Testplanlægning i agil udvikling appeared first on Key2Quality.

Hvis du f.eks. ser på tallene fra World Quality Report 2019/20 (de blå) eller The Definitive Quality Survey fra Forrester (de grønne) nedenfor, så kan de måske give lidt stof til eftertanke.

Nu står der godt nok ”have challenges with testing in SAFe”, men min erfaring er, at det ikke er meget anderledes, uanset hvilken skaleringsmetode man så vælger. Når systemlandskabet bliver stort og komplekst, når mange mennesker skal arbejde på tværs af disse, og når måden, man skal arbejde på, er under stadig forandring, så bliver det også svært at få styr på testaktiviteterne.

Der kan være rigtig meget værdi at hente i at se nærmere på den problematik – at fokusere på at få en mere effektiv og værdiskabende tilgang til test, men hvordan? Man vil ofte se nogle af problematikkerne blive rejst på retrospective-møderne i de enkelte teams, og man vil forhåbentlig sætte målrettede aktiviteter i gang til at løse teamets konkrete problemer i forhold til test og kvalitetssikring. Men her er test bare én af potentielt mange problematikker, der skal diskuteres. Hvad nu hvis historien gentager sig, hvis der er problematikker, der går på tværs af teams – på tværs af organisationen? Hvad nu hvis man med fordel kunne hjælpe forbedringer på vej, der kunne give værdi for større dele af organisationen?

Det er så her testmodenhedsevaluering kommer ind i billedet. Før vi tager hul på at lave forbedringer til højre og venstre i organisationen, så er det godt at få et fælles billede af, hvad udfordringerne er, hvor er det vi er gode, og hvor er det, vi kunne blive bedre. At skabe det fælles billede kan hjælpe med at prioritere, hvor det er der først skal tages fat, og hvordan vi kan løfte kvaliteten af den test, der bliver lavet på tværs af organisationen og i de enkelte teams bedst muligt.

Tænk på det som en GPS…

Et billede på det er lidt ligesom, når du bruger en GPS; du har som minimum brug for to ting, for at din GPS virker: din nuværende placering, og hvor det er du vil hen. Med de informationer (og kontakt til relevante satellitter forstås) kan den komme med et oplæg til din rute – nogle gange kommer den endda med flere du kan vælge imellem. Undervejs holder din GPS øje med forholdene, og er det nødvendigt så ændrer den ruten eller flager i hvert fald som minimum for dig, at det måske var værd at overveje, hvis ikke du skal hænge fast i en kø.

En testmodenhedsevaluering er din nuværende placering, hvis vi skal blive i GPS-analogien. Den kan du lave selv, eller du kan få hjælp – det afhænger helt af din situation, hvad der virker bedst. I nogle organisationer har man stærke testkompetencer, der kan gå ind og lave en sådan evaluering, og man har også rammerne, der gør, at resultatet af en sådan intern evaluering vil have tilstrækkelig tyngde, til at man kan bruge den som løftestang til efterfølgende forbedringstiltag. Ofte vil der dog være værdi i at få hjælp til det ”udefra” – at få et sæt friske øjne på måden, man arbejder på, uden at være påvirket af kultur og politiske problematikker i organisationen.

Det næste er så, hvordan det kan gennemføres, og igen er der flere muligheder – uanset om man vælger at gøre det internt, eller om man får hjælp udefra. Der findes som nævnt formelle metoder til dette, både generelle testmodenhedsevalueringer og metoder, der er specialiserede i forhold til agil kontekst – og man kan naturligvis også definere sin egen metode og lave en uformel evaluering. Det sidste kræver dog, at man har ret tunge testkompetencer i organisationen, der både kan definere og drive en sådan evaluering.

TPI NEXT®-tilgangen

Jeg har ad mange omgange kigget på de forskellige formelle tilgange til testmodenhedsevalueringer gennem de sidste 10 år og har blandt andet fået en del praktisk erfaring med brugen af TPI NEXT® både i forhold til evaluering og den efterfølgende implementering af forbedring på basis af en sådan evaluering, så det er den jeg tager mit udgangspunkt i denne artikel. En af de væsentligste grunde til denne præference er desuden, at den er offentligt tilgængelig i sin helhed. Fundamentet kan findes i Bogen ”TPI® Next”, og du kan finde værktøjet til dokumentation af evalueringen på www.tmap.net. Samtidig er den er meget praktisk orienteret. Den fokuserer ikke på, at du skal opfylde specifikke niveauer, men kan tilpasses det forretningsmæssige fokus, og den findes i både en generel og bredt anvendelig udgave og i en udgave specialiseret i forhold til agil udvikling og test.

Der er reelt to forskellige tilgange til TPI® i dag. Den ene er den verdenskendte TPI NEXT®, som ofte genkendes via den modenhedsmatrice, der illustrerer resultatet af en analyse:

Den anden tilgang er en agil udgave, der er udviklet gennem de sidste år. Formatet på visningen ligner TPI NEXT® en del, dog er der ikke identificeret de fire modenhedsniveauer – der er i stedet fokuseret på modenhed på professional, team og organisatorisk niveau:

Princippet for de to tilgange er dog det samme; der arbejdes med key areas, check points og clusters i konteksten af matricen.

• Key areas: Test er delt op i 16 forskellige key areas som f.eks teststrategi, testmetode, testmiljø mv.
• Check points: For hvert key area er defineret en række spørgsmål (eller check points) – illustreret ved de enkelte felter pr. key area. Disse skal besvares med enten ja, nej eller ikke relevant. På basis af disse besvarelser kan man så tegne modenhedsmatricen som vist i de to tegninger.
• Clusters: Spørgsmålene er grupperet, efter hvilke der med fordel kan laves forbedringer for sammen – det kaldes ”clusters”. Disse er indikeret med bogstaverne i felterne.

Selve evalueringsdelen bør være en kombination af en række interviews med forskellige roller som f.eks. tester, udvikler, produktejer, kunde, testmanager, arkitekt, ledelsen, samt en analyse af de forskellige arbejdsprodukter, der relaterer sig til test og kvalitetssikring. På basis af dette udarbejdes resultatet, og både styrker og svagheder belyses i den efterfølgende gennemgang. Samtidig bør der komme en række forslag til forbedringer, og dette gerne i form af et overordnet roadmap. Output kan indeholde to forskellige aspekter:

• Forbedringstiltag: Tiltag, der fokuserer på forbedring af selve testprocessen
• Enablers: Tiltag, der ligger udenfor testprocessen, men hvor man kan drage fordel af hinandens bedste praksis. Dette kan være aktiviteter, der påvirker testprocessen, eller som testprocessen påvirker.

Resultatet af analysen samt forslag til forbedringer inklusiv et roadmap er det, du får i hånden efter en testmodenhedsevaluering. Så nu står du med en rapport og måske en præsentation – her er et billede af jeres nu-situation. Nu skal du så ”bare” i gang med at lave forbedringerne, at implementere roadmap. Og det er lige her, det går galt for mange – det er nemlig langt fra ”bare”; et hurtigt skud fra hoften er, at det at definere en proces er ca. 10-20 % af indsatsen, mens de 80-90 % er at implementere den og at få den integreret i den nuværende tilgang og få den til at være en del af kulturen i teams, trains, projekter osv. Men det er en helt anden historie. Et hurtigt tip er dog: lad være med at sætte jer ned og tegne hele den forkromede løsning og så efterfølgende gå i gang med at implementere det hele på bedste ”big bang”-vis. Bryd i stedet jeres roadmap ned i en masse små forbedringstiltag, og tag dem lidt efter lidt – og husk PDCA (plan-do-check-adjust/act).

Jeg har i den sidste måneds tid været i gang med en TPI® evaluering hos en kunde, og her blev vi enige om at vælge den fulde TPI NEXT®-tilgang, selvom de arbejder i en agil kontekst, da der var et ønske om en generel evaluering af tilgangen til test i organisationen. Vi har gennemført en analyse af nu-tilstanden gennem interviews og analyser og kunne inden juleferien levere rapporten til dem. Rapporten er dels en detaljeret gennemgang af analysen og det deraf følgende resultat, og dels en gennemgang af oplæg til forbedringstiltag, der kan løfte modenheden både i de enkelte teams og på tværs af organisationen – denne suppleret med oplæg til overordnet roadmap. Den står naturligvis ikke alene men bliver suppleret med en gennemgang for ledelsen i starten af det nye år. Dette for at give lejlighed, til at der kan stilles spørgsmål til resultatet, men også for at diskutere, hvad det næste logiske skridt så er for organisationen. Med det har de et klart billede af, hvor de står lige nu, og hvilke aktiviteter der kan igangsættes for at modne test i organisationen.

Hvis du er blevet nysgerrig efter at vide mere, er der nedenfor listet en række kilder op, som du kan dykke ned i. Du er også velkommen til at række ud til mig på telefon 4940 8552 eller e-mail gitte@key2quality.dk, så vi kan tage en diskussion om, hvad der er smart i din kontekst.

TPI NEXT®: Test Process Improvement (TPI) | TMap

TPI NEXT® bog: TPI® NEXT – Business Driven Test Process Improvement (ict-books.com)

TPI NEXT® agile whitepaper: Microsoft Word – Agile Test Practice Improvement 2.4.doc (tmap.net)

TMMI® modellen: TMMi Model – TMMi

TMMI® assessment method: About TMMi Assessment Method – TMMi

TMMI® bøger: Books – TMMi

PDCA: PDCA Cycle – What is the Plan-Do-Check-Act Cycle? | ASQ

The post Testmodenhedsevaluering – også i en agil kontekst appeared first on Key2Quality.

The post Sådan kan test understøtte det første agile princip appeared first on Key2Quality.

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.

The post En værdidrevet tilgang til udvikling og test appeared first on Key2Quality.

Men forstår alle det samme med ordet “kvalitet”? Teamet, ledelsen, kunden, slutbrugeren?

I Eurostar deep dive webinaret d. 22. marts 2021 gennemgik jeg de forskellige perspektiver for kvalitet, og hvordan vi kan bruge dette i vores daglige arbejde til at stræbe efter at opfylde det allerførste agile princip: “Vores højeste prioritet er at stille kunden tilfreds gennem tidlig og kontinuerlig aflevering af værdifuld software”.

Nyttige links:

VOICE modellen

GQM modellen

Garvins 8 perspektiver på kvalitet

The post Kvalitet i Agile – forskellige perspektiver appeared first on Key2Quality.

Der skal ikke herske nogen tvivl om at produktrisikoanalyse er en af mine yndlingsemner, der er tidligere kommet en lille video og en længere artikel om emnet Her gav jeg en introduktion til grundlæggende produktrisikoanalyse, og en tilgang til det som kan bruges uanset hvilken udviklingsmodel du arbejder i. Men i denne artikel vil jeg forsøge at fokusere på hvordan man kan få PRA integreret i det daglige arbejde i teamet når man er en del af et agilt projekt, eller måske ligefrem et agile release train hvis du arbejder i en skaleret agil kontekst.

Hvorfor lave produktrisikoanalyse?

Hvis du har været forbi den sidste artikel eller videoen så ved du allerede at PRA er en essentiel brik i opgaven med at identificere en risikobaseret test strategi, uanset hvilken udviklingsmodel du bruger, således også i den agile kontekst. Baseret på hvad vi ved om opgaven samt en dialog mellem interessenter identificerer vi det risikobillede som vi efterfølgende skal finde ud af hvordan vi bedst kan mitigere – med test, review eller andre kvalitetssikrende aktiviteter.

Hvornår laver man produktrisikoanalyse i agile?

Det grundlæggende omkring PRA er det samme uanset hvordan du i praksis gennemfører den. Dine interessenter på sprint niveau er som udgangspunkt dit team og jeres product owner, i skal naturligvis have fokus på både funktionalitet og de non-funktionelle aspekter og sidst men ikke mindst skal produkt risici også her vurderes både i forhold til konsekvens og sandsynlighed.

Men når man arbejder i korte iterationer som man gør i agile, så er det en fordel hvis man kan få fundet frem til en metode der kan integreres i de ceremonier der allerede er i teamet (eller på toget!), fremfor at køre det som en separat PRA-workshop som jeg ellers traditionelt vil gøre. Og det gælder såvel forberedelse som selve afholdelsen af produktrisikoanalysen at det bør integreres i de ceremonier der allerede eksisterer.

Forberedelsen til PRA, altså arbejdet omkring at finde ud af scope, kan med fordel ske som en del af backlog refinement/grooming. Det er her features og stories bliver afklarede og man får et billede af hvad opgaven er. Faktisk kan med fordel også tage en indledende snak om hvilke kvalitetsattributter der er relevante for de enkelte features/stories og få det dokumenteret som en del af opgaven.

Selve PRA’en bør integreres i sprintplanlægningen (eller PI planning hvis vi taler SAFe); her har teamet afklarende diskussioner med produktejer, estimerer opgaven. Derfor er det vigtigt at have et billede af de produktrisici der er i forhold til de enkelte stories, og om der er nogen non-funktionelle attributter der skal fokuseres på både. Det vil sandsynligvis have en indflydelse på estimatet for den enkelte story, og det er derfor ikke hensigtsmæssigt hvis PRA-fokus først kommer EFTER stories er estimerede og sprintet er planlagt.

Så langt så godt, nu ved vi hvor i lifecycle vi skal forberede og afholde PRAen, nu mangler bare en lille detalje; hvordan skal vi så gøre det i praksis? Hvis vi skal have teamet med og skabe den fælles forståelse for opgaven, så har jeg et par forskellige forslag til hvordan det kan gøres i praksis

Hvordan laver man produktrisikoanalyse i agile?

Det første forslag tager udgangspunkt i PRISMA modellen.

Her lægges der op til at man i en interaktiv workshop gennemfører PRA lidt som vi også gør ved klassiske risikoworkshops. Der tegnes en graf der splittes op i et antal kvadranter. Ud af x-aksen placeres konsekvens, og op ad y-aksen placeres sandsynlighed.

Nu laves der en brainstorm hvor de enkelte produktrisici noteres på post-its, og ejeren af de enkelte post-its placerer dem hvor han mener de passer i grafen. Dette diskuteres af deltagerne og man når til en konsensus.

Hvis du nu tager det videre til sprintplanlægningen, så tager vi en user story ad gangen, laver den afklaring der skal til som vanligt i denne aktivitet i samarbejde med PO, og derefter bliver teamet enig om hvor den skal placeres i risikografen – og den placeres der i form af en post it. Først derefter estimeres storien og puttes i sprintbackloggen.

Tag et billede af grafen – er den på en flipover så kan I jo med fordel hænge den op i teamet efterfølgende.

Et alternativ til dette kommer fra TMap. Her har Rik Marselis og Leo Van der Aalst defineret konceptet risikopoker.

Ligesom ved PRISMA starter man med at afklare en story sammen med PO som en del af sprintplanlægningen. Når man har et billede af scope så gennemføres risikopoker INDEN man estimerer sin story. I bruger planning poker kort ganske som til estimering, men for at holde det simpelt så nøjes med 0-1-2-3.

Der spilles på helt samme måde som ved planning poker, hvor man vælger sit kort, alle deltagere præsenterer deres valg og såfremt der eventuelt er valgte kort der falder udenfor flertallets valg, så vil valget blive præsenteret for gruppen for at give afklaring. Man kører en gang til og forhåbentlig er man så ved at være nået frem til en konsensus.

Ved risiko poker bliver der spillet med to forskellige fokus, først for at afklare konsekvens, anden omgang afklarer sandsynlighed. De to tal ganges sammen – og man har en risikoklasse. Jo højere tal – jo højere risiko.

Nu kan man så gå videre i sprintplanlægningen og estimere den enkelte story, for den afklaring man har fået dækker nu både scope og risiko, og man kan derfor give et mere nuanceret estimat.

Et af de spørgsmål jeg ofte får er; jamen hvad så bagefter – hvor skal vi gøre af det tal. Min umiddelbare anbefaling er, at I tilføjer et felt i jeres værktøj (Jira, Azure eller hvad I nu bruger) hvor I kan fastholde det, fuldstændig på linje med estimatet. Det skal være synligt for teamet når de åbner en user story hvor høj risiko man har identificeret.

Så to simple metoder til at få PRAen integreret i den agile måde at arbejde på, men husk PRA er jo stadig kun første skridt i at identificere jeres test strategi, nu er næste punkt at få fundet ud af hvordan i så bedst og mest effektivt kan mitigere de produktrisici, I har identificeret.

The post Produktrisikoanalyse i en agil kontekst appeared first on Key2Quality.