Productrisicoanalyses in een agile project

In veel projecten is het een uitdaging om goed te bepalen wat je nu wel en wat je nu niet diepgaand moet testen. Vanuit het testen is daar een principe voor: de productrisicoanalyse (ook wel: de pra). Met een pra bepaal je wat de kritische systeemdelen zijn, en welke minder kritisch. Dit kun je onder meer gebruiken om je testdiepgang op te bepalen. Vanuit de agile gedachte is het wenselijk om meerdere varianten van de pra te hebben , zodat je al naar gelang van de complexiteit en omvang van het project kunt bepalen welke variant jouw project het best past. In deze blog passeren 5 varianten kort de revue.
Wat is een productrisicoanalyse?

Een pra is het inventariseren van de productrisico’s voor die items/gebieden die het hoogste risico niveau hebben en die daarom het belangrijkst zijn om te testen. Het doel is om met het team en de stakeholders gezamenlijk tot één beeld komen van wat de meer of minder risicovolle kenmerken en delen van het te testen product zijn.  Deze analyse dient als basis voor de teststrategie waardoor onderdelen met het hoogste risico als eerste en meer intensief worden getest dan die met lagere risico’s. Het resultaat wordt vastgelegd in een risicomatrix, waarbij de ene as de mogelijke faalkans weergeeft (gebaseerd op complexiteit en insensiteit van gebruik), en de andere geeft de verwachte schade weer (hoe groot is de impact van een fout op het bedrijfsproces). Hierbij een eenvoudig voorbeeld van zo’n matrix:

Een voorbeeld van een risico matrixDe 5 mogelijke varianten van een pra die wij onderscheiden zijn:

  1. Eenvoudig, individueel
  2. Eenvoudig, als team
  3. Eendimensionale pra van Smartest
  4. Tweedimensionale pra van Smartest
  5. BDTM volgens TMapNext

Variant 1: Eenvoudig, individueel

De meest lichtgewicht variant van een pra is om je als agile teamlid bij de start van de iteratie een inschatting te maken welke user stories zwaar, gemiddeld of licht getest moeten worden. Zorg dan wel dat je helder hebt hoe je dat zwaar/gemiddeld/licht testen precies vorm gaat geven. Deze indeling is dan leidend voor jouw testinspanning. Het voordeel van deze lichtgewicht aanpak is dat het minimale voorbereiding of consensus vereist. Het nadeel is dat je het team er niet bij betrekt en jouw aanpak misschien niet de beste is en dat het niet is afgestemd met de business en de inschattingen van de zwaarte per sprint kunnen verschillen.

Variant 2: Eenvoudig, als team

Liever bepaal je samen als team hoe diepgaand iets getest moet worden: bepaal dus eerst met je team en de Product Owner hoe je bepaalde systeemdelen getest wilt hebben, variërend naar diepgang. Vervolgens bepaal je als team bij de Planning Game welke stories hoe zwaar getest moeten worden. Mocht je nu tot de ontdekking komen dat je veel user stories hebt die zwaar getest moeten worden, dan kun je dit dus nog meenemen in de scopebepaling.

Variant 3:  Eendimensionale pra van Smartest

Om meer inhoudelijk te kunnen onderbouwen op welke gronden nu iets beoordeeld wordt, kan de eendimensionale pra van Smartest gehanteerd worden. Hierbij ga je uit van de eindstaat van de release: wat is de verwachte scope? Deze wordt opgedeeld in systeemdelen. Deze systeemdelen ga je aan elkaar relateren, opnieuw op basis van de inschattingen rondom foutkans en verwachte schade. Deze pra kun je bij elke iteratie kort herhalen, gericht op de scope voor de iteratie uiteraard. Meer hierover vind je op de website van smartest: http://www.smartest.nl/toolstemplates/risicoanalyse. Daar vind je ook een template in de vorm van een excel sheet.

Variant 4: Tweedimensionale pra van Smartest

Waar bij de eendimensionale pra de systeemdelen relatief worden gewogen, wordt bij de tweedimensionale pra ook nog gekeken naar de kwaliteitsattributen. Door deze ook in de beoordeling van de risico’s mee te nemen, ontstaat een duidelijke onderbouwing van de teststrategie. Met name voor grotere en complexere agile trajecten zal dit waardevol zijn.  Ook hier is een template beschikbaar voor op de website van Smartest.

Variant 5: BDTM volgens TMapNext

Uiteraard biedt ook de testmethode TMap een pra-variant: Business Driven Test Managament (BDTM). Dit is een wat formelere aanpak van het risicoinschattingsproces en het besteedt veel aandacht aan de rol en invulling van de stakeholders. Meer hierover op de site van TMap. Wel gaat het uit van het traditionele principe dat je zoveel mogelijk informatie vooraf moet hebben om een goede inschatting te kunnen maken. Er zit dus geen iteratieve cyclus in. Dat heeft Smartest ook niet uit zichzelf, maar dat proces is wat meer lichtgewicht en staat dat daarmee wat makkelijker toe.

In mijn agile projecten gebruik ik vaak variant 2 of 3, afhankelijk van de complexiteit en omvang van het project. Is het technologisch uitdagender dan pak ik variant 4.

We zijn benieuwd naar jullie reacties en ervaringen!

Over Anko Tijman

Managing Consultant on Agile & DevOps at Ordina. Connector. Listener. Thinker. Collaborator. Pianist. Dad. http://nl.linkedin.com/in/ankotijman
Dit bericht werd geplaatst in Agile ontwikkelen, Algemeen, Testen en getagged met , , , , , , , , , , , , , , , , , . Maak dit favoriet permalink.

4 reacties op Productrisicoanalyses in een agile project

  1. Hi Anko, Recent hadden we intern bij Valori een discussie over risicoanalyse binnen Agile projecten. We kwamen ook tot de conclusie dat je verschillende varianten hebt, maar daarnaast de risico analyse op verschillende momenten in het project terug komt

    1) Enerzijds zou je verwachten dat de indeling en priotering van de backlog voor deel gebaseerd is op de risico-analyse. Dit omdat het goed is om te kijken waar de moeilijkheden zitten (technisch) en waar het belang van de gebruikers zitten. Het kan goed zijn om de technische risico’s in vroege sprints af te dekken. Een beetje een POC gehalte. Dit kan niet altijd natuurlijk, maar als er een groot technisch risico zit, wil niet in je laatste sprint er achter komen dat het idee niet werkt. Je gooit dan veel werk weg. Anderzijds werkt het erg comfortverhogend als je in een vroegtijdig stadium die dingen kan laten zien, waar de gebruikers erg veel belang aan hechten. Deze punten zu je dus eerder in de backlog willen zetten. Mocht er refactoring uit voortvloeien, dan heb je nog genoeg sprints voor je om dit op te vangen.

    2) Testen in de sprint. Op basis van de risico analyse kun je teststories definiëren. Het loont dus om aan het begin van de sprint de bestaande risico analyse te valideren. Waarschijnlijk wil je met de de voor deze sprint belangrijke stakeholders een nieuwe risicoanalyse doen. In je teststory kun je dan in een korte cirkel laten zien hoe je met je testen aanhaakt bij de belangen van de stakeholders. Dit maakt de toegevoegde waarde van je activiteit inzichtelijk en zou geïntegreerd moeten zijn in de DOD

    3) Gebruikers Acceptatie testen: de gebruikers doen vaak een GAT buiten de sprint om. Vaak is de organisatie niet in handen van de Bouwmeester, maar van de acceptant. Wat gaat deze doen? Waar legt hij zijn accenten. Ik zou verwachten dat dit op basis van een risico inchatting gebeurd. Als de GAT elke sprint wordt gedaan valt dit samen met punt 2. Als de GAT pas aan het einde wordt uitgevoerd, zou dit kunnen aansluiten bij punt 1. Maar best kans dat er scope shift is geweest. We doen niet voor niets agile. Dus valideren is noodzakelijk.

    In alingment met jouw post:
    In stap 1 zou ik dus een Tweedimensionale pra van Smartest doen
    In stap 2 Eenvoudig, als team of Eendimensionale pra van Smartest
    In stap 3 past denk ik een Eenvoudig, als team, Eendimensionale pra van Smartest of Tweedimensionale pra van Smartest

  2. ankotijman zegt:

    Hi Derk Jan,

    Stap 1: agree
    Stap 2: waarom zou je aparte teststories invoeren?
    Stap 3: Voor mij is de klant onderdeel van het team. Het is juist de bedoeling dat Bouwmeester en Acceptant samenwerken en geen verschillende perspectieven hebben. Als je voor acceptatie een aparte pra gaat vastleggen, dan krijg je dus late feedback in het project en kan er dus niet done opgeleverd worden. Dat is niet agile😉

  3. Hi Anko,

    Stap 1: mooi. Stap 2: eh…Ik bedoel natuurlijk userstories. Je hebt gelijk. Stap 3: Een goed punt. Ik noemde in mijn comment ook dat je dit in feite niet doet “Als de GAT elke sprint wordt gedaan”.
    Ik heb echter de indruk dat de GAT ook vaak buiten de sprint valt. Ik heb bij een groot overheidsproject meegemaakt dat er zo’n 40 gebruikers (geen testers) uit verschillende vestigingen een GAT gingen uitvoeren. Deze test viel buiten de ontwikkeling die door de leverancier werd gedaan, en de testers zaten ook niet op de hoofdvestiging waar de code gemaakt werd. Ik ben het met je eens, dat je geen late feedback wilt, maar bovenstaande gebruikerstest wil je niet altijd in elke sprint doen.
    Heb jij ervaring met klant-leverancier situaties waarbij er uiteindelijk door de klant-organisatie een aparte GAT werd uitgevoerd? Werd daar niet een detail plan gemaakt, of detail instructies gegeven? Deze werden neem ik aan gebaseerd op de PRA waarop de bouw is gebaseerd.

  4. De doelstelling van een PRA is volgens mij lastig om te zetten in risico-analyses per sprint, wanneer je in relatieve termen blijft denken. Je wilt immers voor diverse systeemdelen een relatieve dekking in de tests terug zien. D.w.z. user stories die bv. in het verwerkinggedeelte van de applicatie zitten, wil je grondiger testen dan die in het rapportagegedeelte. Als je nu in een sprint werkt waarin alleen maar laag ingeschatte (in de pra) stories zitten en een rapportage-story, dan moet die laatste relatief het zwaarst getest worden. Maar niet zwaarder dan de andere rapportages in andere sprints.
    De relatieve inschattingen uit de pra moeten daarom, vooraf, worden omgezet in een aanduiding om (de test expert in) elk scrumteam te helpen tot passende tests te komen (zoiets als een testtechniek).

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s