Integratie Ketentest in het SAFe® model

De vorige keer vertelde ik over de organisatie van de ketentest via een virtueel team van test experts uit de Agile Release Train (ART), onder aansturing van de regisseur Ketenkwaliteit die als Product Owner (PO) vanuit het System Team opereert. In dit artikel beschrijf ik de volledige integratie van de Ketentest binnen het SAFe ® model. Omdat dit de kern van mijn blog is, beschrijf ik deze meer uitgebreid.

Way of working van het Ketentest team

“Het Ketentest Team” (verder te noemen: het System Team) werkt op een identieke wijze als de overige teams. De Ketentest is qua werkwijze daarmee volledig geïntegreerd in het SAFe ® model:

Bovenstaand, vereenvoudigd, schema geeft aan dat ik met het System Team hetzelfde voortbrengingsproces volg als de andere teams binnen de trein: 

Op het hoogste niveau worden de speerpunten van de Business/organisatie vertaald naar Epics. Epics kunnen vanwege dit hoge abstractieniveau vaak gedurende langere tijd open staan. Vanuit de Epics worden, door de leden van het Feature Team (Business Analisten – BA), Features. (FT) benoemd, die qua grootte binnen een Program Increment (PI) (vaak een kwartaal) moeten kunnen worden afgewerkt. Als Regisseur KetenKwaliteit ben ik lid van het Feature Team, waar de eerste identificatie van keten aspecten plaats vindt. Ik ontvang hier de benodigde achtergrondinformatie en review de FT’s vanuit de ketengedachte.

Define User story

De PO’s van de Teams (dus inclusief mijzelf vanuit het System Team) benoemen User Stories (US’s) voor deze FT’s om het eigen werk te organiseren, die qua grootte binnen een Sprint. moeten kunnen worden afgewerkt. De taken geven vervolgens de werkzaamheden voor de teamleden binnen een Sprint aan. Daarnaast kent ook het System Team de activiteiten Sprint planning, Review (demo), Retrospective en Refinement. Voor wat betreft de taken binnen een US voor de Ketentest, heb ik een stukje standaardisatie aangebracht, omdat dit in 90% van de gevallen altijd dezelfde activiteiten betreft. In de regel betreft dit dus steeds dezelfde set aan activiteiten wat de herkenbaarheid vergroot.

Een deel van de Keten regressietest is geautomatiseerd. Hier kom ik later nog op terug. Voor het organiseren van de werkzaamheden van de in het vorige artikel genoemde TA-expert, maak ik ook aparte US’s. Net als de US’s voor de ketentest omvatten deze eveneens een aantal standaard taken. In tegenstelling tot de taken bij de Ketentest, betreft het hier dus alleen taken voor de TA-expert. Het streven is om deze US’s ook vóór het releasemoment van de geraakte functionaliteit af te ronden. Indien dit een ongewenste vertraging oplevert (de Business Owner beslist), dan volgt de afronding na de release en wordt de regressietest op dit onderdeel tijdelijk handmatig uitgevoerd. 

Een belangrijke aanvulling vanuit de ketengedachte is nog dat de Feature owner, zijnde de PO die het grootste aandeel heeft in of belang heeft bij de realisatie van een FT, zowel inhoudelijk als procesmatig contact (voortgang) heeft met voor de trein externe teams/organisaties. Ten behoeve van transparantie registreert de FT owner voor deze teams US’s die worden gekoppeld aan het bovenliggende FT en wordt de voortgang hiervan in de PO Sync (wekelijks overleg tussen de PO’s en BO’s over afhankelijkheden en voortgang US’s en FT’s) besproken.

Hierna beschrijf ik nog enkele terugkerende activiteiten, deels gelijk en deels aanvullend op de standaard Agile (SAFe ®) werkzaamheden. 

Forecast

Voorafgaand aan de Program Increment (PI) planning geef ik, als PO van de keten aan de overige betrokken PO’s, onderbouwd door hoeveel tijd ik nodig denk te hebben in de komende PI van de testspecialisten uit hun teams. Het aantal uren blijft overigens beperkt, omdat de werkpakketjes ook klein zijn. Deze benodigde tijd is grofweg op te splitsen in drie onderdelen:

• Structurele uren voor zaken als refinement, voortgang en planning;
• Variabele uren voor periodiek terugkerende keten regressietesten (ten behoeve van handmatige uitvoer en beoordeling);
• Variabele uren voor testuitvoer van nieuwe features uit het voortbrengingsproces;

De PO’s geven een terugkoppeling op haalbaarheid en indien nodig wordt samen met de BO(‘s) gekeken naar prioriteitstelling op het moment dat er conflicten ontstaan en worden er keuzes gemaakt. De beschikbare tijd wordt vervolgens gebruikt in de sprint planning. Dit betreft het in het vorige artikel genoemde “meebewegen op de golf van de behoefte”.

Refinement en voortgang

Het virtuele team komt, afhankelijk van de hoeveelheid werk, één tot tweemaal per week een uur bij elkaar, voor refinement van de werkvoorraad en het doorspreken van de voortgang van de sprint activiteiten. Dit is inclusief het deel van TA van de Keten regressietest. Het virtuele team is hiervoor uitgebreid met een afvaardiging vanuit de acceptanten (gebruik & beheer). De benodigde inspanning van de acceptanten wordt hierdoor geoptimaliseerd en hun betrokkenheid vergroot. Hun acceptatiecriteria worden direct beschreven en georganiseerd. Tevens worden zij bijgepraat over de actuele stand van zaken. 

Binnen de refinement bespreek ik in dit gezelschap tevens welke testgevallen van toepassing zijn voor nieuwe FT’s met een ketenaspect, de mogelijke impact op de standaard regressie testset en de mogelijke uitbreiding op/aanpassing van het geautomatiseerde deel van de regressie testset. 

Sprint planning

Naast de refinement vindt een paar dagen voorafgaand aan een sprintwissel een sprintplanning plaats met alle teamleden van het virtuele team, dus inclusief de acceptanten. Hierbij wordt de geprioriteerde werkvoorraad besproken en gekeken naar een goede vulling van de eerstvolgende sprint, rekening houdend met de beschikbare tijd. Ook hier geldt weer dat dit inclusief het deel van de TA-expert is. Wanneer dit conflicteert met beoogde livegangen (we krijgen bijvoorbeeld niet alles gepland) bespreek ik dit eerst met de collega PO’s en wanneer we hier om legitieme redenen niet uit kunnen komen, bespreken we dit met de BO(‘s) waarna keuzes worden gemaakt. Mogelijk dat beoogde streefdata worden bijgesteld.

Sprint

Gedurende de Sprint werken de teamleden aan de afspraken zoals gemaakt tijdens de Sprint planning. Dit zijn in de regel testuitvoer activiteiten, omdat de testgevallen al zijn benoemd tijdens de refinement sessies en ik deze verder heb uitgewerkt in de registratie. De teamleden zoeken onderling de samenwerking op. Dit kan op de werkvloer, al dan niet bij elkaar, maar ook via Skype-/Teams-meetings danwel chatsessies. Bij grotere draaiboek-achtige trajecten organiseer ik Skype-/Teams-meetings waarbij we elkaar op de hoogte houden van de voortgang van de stappen en momenten dat we het stokje overgeven aan de volgende discipline. De acceptanten worden steeds geïnformeerd over de resultaten op de wijze waarop zij dat wenselijk achten. Op afroep zijn ontwikkelaars van betrokken teams beschikbaar voor afstemmomenten dan wel analyse activiteiten op momenten dat we mogelijke issues tegenkomen. De teams hebben een aantal uren per Sprint beschikbaar voor het oplossen van bevindingen. Dit om te voorkomen dat de testuitvoer stagneert en niet kan worden afgerond.

Praktisch gezien zijn de System teamleden een aantal uren per week beschikbaar en stemmen zij onderling de gezamenlijke momenten af, rekening houdend met de eigen team activiteiten. Wanneer er issues worden gevonden die niet snel kunnen worden opgelost, worden hier defects voor geregistreerd. Indien mogelijk worden deze direct aan het team gekoppeld dat hier werk aan heeft, anders vindt eerst een analyse plaats.  Afhankelijk van specifieke releasemomenten organiseer ik een wekelijks afstemmingsmoment of zelfs een dagstart, waarbinnen de ketenvoortgang en mogelijke impediments tijdens de testuitvoer worden besproken. Dit is met name het geval wanneer tevens afstemming nodig is met voor de ART externe teams (al dan niet binnen de eigen organisatie). In deze periode is het namelijk belangrijk om korte lijntjes te hanteren, in verband met de vele afhankelijkheden en verhoogde mate van complexiteit en daarmee risico’s. De review en de retro worden verder op een soortgelijke, maar kleinschaligere, wijze uitgevoerd als de overige teams binnen de ART.

Tot zover de integratie van de Ketentest in het SAFe ® model. Daarmee lijkt mijn blog klaar. Ware het niet dat ik nog iets heb gedaan met die Ketentest, met gevolgen voor Test automatisering. Interesse? Lees dan ook mijn volgende artikel of bekijk onze test services.