Onlangs hadden we een discussie over de prioritering van user stories voor een nieuw project. Het idee van de Product Owner was om het proces stap voor stap op te bouwen, te starten bij het begin.
Dat lijkt logisch, maar ik dacht er persoonlijk anders over. In een eerder project hadden we ervaren dat je aan het eind van het proces tegen veel problemen aan kunt lopen door beslissingen die zijn genomen tijdens de bouw van de eerste stappen. Mijn voorstel was dus om eerst een eenvoudig voorbeeld van begin tot einde werkend te krijgen en daarna alle stappen uit te breiden voor de meer ingewikkelde varianten. Hieronder beschrijf ik mijn ervaring.
Stel, je staat aan het begin van een project en er moeten user stories worden gemaakt. Iemand heeft al een lijst gemaakt, maar die is voornamelijk technisch van aard: elke stap en component in het proces staan erin. Het bedrijf waar je werkt, gebruikt namelijk niet echt de user stories in het standaardformaat, dus in de vorm: “als <wie> wil ik <wat>, zodat < waarom>”. Daar kun je over discussiëren, maar dat is niet het punt dat ik hier wil maken. Een rijtje technisch georiënteerde “user stories” kan ertoe leiden dat elke stap in het proces compleet ontwikkeld wordt, maar dat het geheel in het proces uiteindelijk net niet het gewenste resultaat oplevert.
Een voorbeeld: in een project voor een supermarkt was er sprake van een “heenstroom” en een “retourstroom“ van goederen. Voor beide stromen moesten bestellingen, leveringen, voorraden en facturen gemaakt en verwerkt worden. Eerst werd de heenstroom werkend gemaakt en daarna de retourstroom. Helaas bleek de retourstroom erg moeilijk vanwege een aantal technische keuzes die tijdens de ontwikkeling van de heenstroom waren gemaakt. Hieruit bleek dat het dus handig kan zijn om eerst door het hele proces het “kleinst of eenvoudigst mogelijke goedpad” aan te tonen. En dan bedoel ik echt het hele proces, dus tot en met de laatste stap.
Deze tactiek hebben we toegepast voor een proces met een nieuw type bestellingen. Hiervoor moesten nieuwe schermen worden gemaakt, in SAP moesten transacties en batchjobs worden uitgebreid en het berichtenverkeer tussen SAP en het Warehouse Management Systeem (WMS) moest worden aangepast.
In het kort komt het proces neer op het volgende:
Er zijn twee stromen: van winkel naar DC en van DC naar winkel. Verder zijn er verschillende soorten artikelen. Een potje pindakaas bijvoorbeeld is het eenvoudigst, maar een stuk kaas dat op gewicht wordt afgerekend is al lastiger. En rechtstreeks leveren is makkelijker dan via een tussenstop/overlading. Een ijsje gaat weer via een andere tussenstop en moet nog steeds bevroren aankomen in de winkel. Variatie genoeg in alle stappen van het proces.
Dus is het handig om niet dezelfde fout te maken door eerst alleen de stroom “van winkel naar DC” te realiseren en testen, voor elk soort artikel en vrachtwagenroute, maar eerst aan te tonen dat het geheel gaat werken van begin tot einde voor een pot pindakaas die rechtsreeks naar een winkel gaat (zonder overladen).
De eenvoudigste variant dus, want als dat niet lukt, dan lukken de moeilijkere gevallen al helemaal niet.
De user stories worden dan, zonder het deel dat het <wie> en het <waarom> beschrijft:
Dat ziet er zo uit:
De user stories kunnen daarna uitgebreid worden met
We zitten nog midden in het project, maar het doel om de hele keten te laten werken voor de allersimpelste situatie heeft zijn vruchten afgeworpen. Vrij snel bleek dat de factuur, dus de laatste stap in het proces, niet kon worden aangemaakt door de gekozen oplossing voor het aanmaken van de bestelling. Als we de eerste stap in het proces voor alle soorten artikelen en winkels hadden gerealiseerd en getest, dan was veel werk voor niets geweest.
Bij een volgende project stel ik weer de vraag: wat is het allersimpelste werkende geheel? En laten we dat eerst werkend krijgen, van het begin tot het einde!
Simone Russchen, testconsultant bij Polteq