User Story Mapping tijdens Agile Meetup Breda: de Retrospective

Op 22 april hebben we met Agile Meetup Breda een online workshop gehouden met als thema “User Story Mapping”.

Initieel was het de bedoeling om de meetup in levende lijve te doen op een mooie locatie in Breda. De coronacrisis gooide echter helaas roet in het eten. Omdat we toch aan de slag wilden met het onderwerp en we ook erg benieuwd waren of we dit op afstand konden doen hebben we de meetup alsnog door laten gaan maar dan online.

Een overzicht van onze aanpak en de stappen die we hebben doorlopen kun je hier vinden.

De meetup was van 15:00u tot 17:00u. Met van 14:30u tot 15:00u digitale inloop. We hadden 15 deelnemers. Als digitale hulpmiddelen hebben me Microsoft Teams en Mural gebruikt.

Dit was voor ons de eerste keer dat we het op deze manier hebben gefaciliteerd. Heel veel ging goed, maar er viel zeker nog genoeg te verbeteren voor een volgende keer. Onderstaand de belangrijkste punten uit onze retrospective:

Wat ging goed

  • Overall hebben we in een korte tijd de belangrijkste aspecten van de techniek kunnen behandelen. Voor een volgende keer gaan we nog goed kijken of bepaalde onderdelen meer of minder of op een andere manier aan de orde moeten komen. Hiervoor gaan we ook beter vooraf luisteren naar de behoeften van de groep.
  • We hadden een zeer enthousiaste groep deelnemers. Voor zover we dat goed meekregen had iedereen er lol in en was het voor iedereen een interessante ervaring.
  • Naast centrale onderdelen hadden we ook twee breakout momenten, waarin een facilitator met een groepje van 3 tot 5 mensen in een aparte teamroom werkte aan het invullen van een gedeelte van de User Story Map. Dat was erg geslaagd. De sfeer was goed. Omdat je met een klein groepje bent wordt het gelijk wat intiemer en persoonlijker.
  • Richting het einde vielen er een aantal kwartjes, met name voor wat betreft waar User Story Mapping past in een flow met andere technieken. Bijvoorbeeld dat je begint met een product vision, dan maak je een User Story Map en vervolgens komen de User Stories hiervan als items op een Sprint Backlog terecht, al dan niet via een Product Backlog. Hierdoor kwam er meer beeld bij de context van een User Story Map.

Wat kan beter

  • Microsoft teams werkt in de huidige vorm niet goed genoeg. Ondanks vooraf gestuurde uitnodigingen met toegang tot onze Teams omgeving duurde het zeker 20 minuten voordat we van start konden omdat mensen toch tegen toegangsproblemen aanliepen. We hadden verschillende rooms aangemaakt voor de break-out onderdelen. Ook daarbij duurde het langer dan wenselijk voordat iedereen op de juiste plek zat. Een volgende keer gaan we gebruik maken van Zoom of een andere online tool.
  • Daarnaast willen we de volgende keer dat een persoon als moderator optreed voor wat betreft technische zaken en mensen die inlogproblemen hebben. Dat moet ook duidelijk zijn voor de genodigden. Nu waren er een aantal mensen bezig, o.a. de gene die het eerste gedeelte aan het uitleggen was, met mensen toegang te verlenen en troubleshooting.
  • We hadden vooraf een half uur inloop gepland voor het officiële gedeelte zou beginnen. Net als bij een fysieke meetup. We merkten echter dat nu bijna iedereen pas in de laatste minuut digitaal binnenkwam. De volgende week maken 20 tot 30 minuten inloop onderdeel van de officiële planning. Zijn we eerder klaar, dan is het mooi en gaan we van start, maar andere loop je gelijk al achter op de planning.
  • We hadden een vrij strakke planning, met het schakelen van gezamenlijke onderdelen naar break-out onderdelen verloren we tijd, waardoor de planning nog meer in het gedrang kwam. De volgende keer gaan we dus ruimer plannen.
  • De intro die we gaven m.b.t. User Story Mapping was te kort. Gedurende de meetup kwamen we er achter dat niet voor iedereen duidelijk wat nou precies het doel is en wanneer je het goed kunt gebruiken. De volgende keer gaan we hier vooraf langer bij stilstaan.
  • Ondanks dat User Story Mapping redelijk gangbaar is, merkten we toch dat er verschillende interpretaties zijn van de techniek. Ook als facilitators. Hier hadden we vooraf langer bij stil moeten staan. Voor een volgende keer gaan we bijvoorbeeld duidelijker bepalen of we gaan focussen op het maken van een back-bone of dat we meer aandacht gaan besteden aan het maken van slices en een development strategie. We hadden een redelijk complexe casus gekozen, met als onderwerp het Havenbedrijf in Rotterdam. Erg interessant, maar wellicht dat we voor een volgende een iets minder complexe casus kiezen.
  • Twee uur voor een meetup/workshop met een onderwerp als dit is erg kort. Om het onderwerp echt recht te doen en tijd te hebben om er zelf mee aan de slag te gaan, heb je al gauw 4 tot 6 uur nodig.

De volgende keer dat we aan de slag gaan met User Story Mapping is op 27 mei, met Agile Meetup Rotterdam.

Beter testen als resultaat van onze retrospective

Een nieuwe klus, altijd leuk. We waren een maand op weg en hielden een retrospective. Een van de vragen die ik onszelf voorlegde was:

Met stip op 1? Beter testen!

Iets meer achtergrond: we hadden een product onder handen dat al meer dan 10 jaar bij ontwikkeling was. Diverse ontwikkelaars hadden hier hun leven aan gewijd. Alle wijzigingen van de afgelopen 10 jaar waren geworden tot een ondoorgrondelijk geheel. Dit betekende dat elke wijziging, hoe klein ook, relatief veel inspanning vergde en ook nog eens een groot risico op regressie met zich mee bracht.

Blog Gertjan Kruiger | Test automation | Selenium
Een stuk beter zo. Toch? 🙂

En wat gingen wij doen? De site in zijn geheel herbouwen. Nee, niet een nieuw product ernaast, beta-testen met klanten en dan een big-bang, hoera we zijn klaar, nee. Wij hadden besloten de site stukje voor stukje te vervangen. Feitelijk draaiden we twee websites, waarbij de nieuwe de oude ‘opat’. Of zoals de Product Owner zei:

We zitten in een oud vliegtuig, dat praktisch uit elkaar valt. En wij mogen de motoren gaan vervangen. In de lucht.

Zij mogen het doen op de grond. Ook best handig.

We wilden natuurlijk niet dat we tijdens ons werk aan de tweede motor de eerste motor per ongeluk kapot maakten. Bij elke release wilden we er zeker van zijn dat de delen van de site die we al hadden vervangen, nog goed functioneerden.

En dat betekende regressie testen. Vaak regressie testen. En tests die je herhaalt, wil je niet handmatig (blijven) doen. Die automatiseer je. En zeg je testautomatisering en websites, dan zeg je: Selenium.

Natuurlijk kon ik lekker in Java mijn eigen tests opzetten, maar dat duurde nog geen dag of twee voordat ik in de gaten had dat dit niet ging werken:

  • De Selenium Webdriver ondersteunt het Page Object Model, maar je moet nog altijd handmatig uitzoeken hoe je je objecten identificeert.
  • De Selenium Webdriver ondersteunt zelf geen rapportage. Deze moest ik zelf maken of leunen op een test framework.
  • Het schrijven van test cases was één ding, maar onderhouden van de testcases werd als snel moeilijker

Ontmoet Katalon:

Katalon

 

Identificeren van objecten gaat eenvoudig met de Spy Web tool. En opstellen en onderhouden van testcases kan via de GUI, of de scripting view. De scripting is gebaseerd op Groovy –  een soort van Java, maar dan net wat anders. Rapporten zijn inzichtelijk op diverse niveau’s.

Inmiddels zijn we heel wat maanden verder. Ik heb ervaren dat het schrijven van testcases minstens zo nuttig is als het telkens kunnen uitvoeren ervan. En Katalon blijft een prima tool!

Overgenomen van https://www.ontdeksels.nl met toestemming van de auteur