Mijn naam is Jan Santegoets. Ik ben Regisseur Ketenkwaliteit en in mijn vorige artikel heb ik de structuur van de Ketentest en de rol die Test Automatisering (TA) hierin speelt beschreven. Helaas komen we inmiddels aan bij het laatste deel van mijn blog. Hierin wil ik benadrukken dat inzicht erg belangrijk is en beschrijf ik de wijze waarop je dat kunt bereiken. Door slimme keuzes kun je een aantal vliegen in één klap slaan.
Transparantie in Kwaliteit
Het laatste deel overstijgt de Ketentest. Het heeft te maken met ketenkwaliteit in de brede zin van het woord. De keten van samenwerkende teams, werkwijzen en wijze van vast- en verslaglegging. Het gaat namelijk over een werkwijze die transparantie biedt ten aanzien van kwaliteit binnen een Agile Release Train (ART), op basis waarvan tijdig onderbouwde en gewogen besluiten kunnen worden genomen door de owners.
Ik heb deze werkwijze geïmplementeerd in mijn tijd als Testmanager voor een ART en ook uitgerold naar een aantal andere ART’s, waarbinnen de volgende facetten een plek krijgen:
- Volledige transparantie in kwaliteit;
- Uniformiteit binnen ART ten aanzien van kwaliteit;
- Requirement Based Werken (RBW);
- Bi-directionele traceerbaarheid conform CMMi-level 3;
- Gecontroleerde livegangen.
Hoe bereik je dit?
- De basis wordt gelegd door de eerder beschreven werkwijze binnen SAFe ®, waarbinnen de Business behoefte wordt vertaald naar Epics, Features en User Stories.
- User Stories worden vervolgens gekoppeld aan een releasemoment.
- Te definiëren testcases worden gekoppeld aan User Stories.
- Indien tijdens de testuitvoer defects worden gevonden, worden deze in principe aan een testcase gekoppeld of indien dit niet mogelijk is rechtstreeks aan een release moment.
Het sleutelwoord binnen bovenstaande beschrijving is “release moment”. Een aantal onderdelen is logisch gezien al aan elkaar gekoppeld: US’s horen bij FT’s en FT’s horen bij een Epic. Dit geldt bijvoorbeeld ook voor Testcases die bij een US’s horen. Door nu deze zaken te koppelen aan release momenten, kun je op enig moment bepalen wanneer onderdelen, met welke kwaliteit in gebruik zijn genomen, en tevens andersom welke kwaliteit een release moment heeft en welke Business behoefte daaraan ten grondslag ligt: Bi-directionele traceerbaarheid. Automatisch werk je op deze manier op een Requirement Based wijze en ontstaat er volledige transparantie over de kwaliteit op enig moment. Door deze werkwijze met de teams overeen te komen, creëer je daarnaast een uniforme werkwijze rondom de kwaliteit van de op te leveren producten door de ART.
Dashboards
Omdat deze onderdelen in enig systeem worden geregistreerd en de meeste pakketten die hiervoor gebruikt worden tevens rapportage mogelijkheden bieden, kun je dit nog uitbreiden met dashboards per release moment, waarbij je de voortgang en kwaliteit op een grafische wijze inzichtelijk maakt. Vaak kun je binnen deze dashboards ook nog doorklikken naar de onderliggende niveaus zodat je detailinformatie kunt inzien. Deze dashboards kun je vervolgens weer gebruiken in Business Readiness Rapportages (BRR) ten behoeve van Release management. Een belangrijk voordeel van deze werkwijze is dat livegangen geen verrassingen meer geven maar op een gecontroleerde wijze plaats vinden.
In het kader van 'geen verrassingen' nog een kleine aanvulling: Wanneer gevonden defects (nog) niet worden opgelost vóór een release moment kun je deze markeren als zogenaamde “Known defects”. Doordat deze zijn gekoppeld aan het oplosteam of bijvoorbeeld aan de applicatie waar deze betrekking op heeft, kan deze indirect ook worden gekoppeld aan een release moment. In mijn situatie krijgt deze een einddatum in de periode naar een volgend release moment en is deze in de tijd daaraan “te relateren”. Een apart dashboard geeft hier inzicht in. Deze informatie wordt overgenomen in de BRR en kan worden gebruikt in de communicatie naar de beheerders en gebruikers rondom het releasemoment of tijdens instructie/opleiding bij grotere implementaties. Indien gewenst kunnen deze op de backlog met lagere prioriteit worden gezet, voor mogelijke toekomstige doorontwikkeling.
Optimaal integreren
Mijn blog is (helaas) af! De afgelopen jaren heb ik veel ervaring opgedaan over Ketentesten binnen SAFe ® en heb ik hier met veel enthousiasme en plezier aan gewerkt. Ik hoop dat ik via mijn blog een goed beeld heb kunnen geven bij hoe je Ketenkwaliteit binnen het SAFe ® model volledig en optimaal kunt integreren. Je hoeft hier geen moeite voor te doen. Het wijkt namelijk niet af van de andere activiteiten en wordt hierdoor herkenbaar en tevens voorspelbaar! Het krijgt daardoor ook automatisch de relevante prioriteit binnen het proces om Business waarde te creëren. Daarbinnen kun je slim gebruik maken van de beschikbare kennis en kunde van de eigen ART en waar nodig buiten je ART, met de eerdergenoemde voordelen. Advies bij dit alles is om KLEIN te beginnen en het SIMPEL te houden.
Heb je dit in place, dan kun je je vervolgens binnen je ART beter richten op de gebieden waar de grootste risico’s op de “Time to Market” liggen, zoals testomgevingen, testdata en externe partijen. Daarnaast kun je denken aan het uitbreiden van de werkwijze richting de Solution train, of treinen in andere domeinen.
Binnen deze oplossing is het verder wel belangrijk dat je het gedachtengoed van Agile nastreeft en niet te veel in hybride achtige oplossingen denkt. Dat vergt echter wel een andere denkwijze, lef, doorzettingsvermogen en vooral vertrouwen in de collega’s die het werk daadwerkelijk uitvoeren. Mijn advies is om zo min mogelijk waterval binnen Agile te gebruiken. Des te groter wordt de opbrengst!
Meer informatie
Dank voor jullie interesse en reacties en bel of mail mij gerust om samen rustig over deze oplossing te praten en ervaringen te delen, of bekijk direct onze Test Services.
