Gå til toppen

Produktrisikoanalyse i en agil kontekst

Så er det tid til at dykke ned i produktrisikoanalyse (PRA) i en agil kontekst – et værdifuldt værktøj til både det agile team og det agile release train hvis man arbejder i en skaleret agil model.

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.