Het kleinst werkende geheel | Polteq, specialist in software testen
Delen Printen E-mail

Een praktijkverhaal van Simone Russchen

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.

User Stories

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.

Goedpad

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:

  • Een winkelmedewerker bestelt een artikel;
  • De bestelling gaat naar een distributiecentrum (DC), waar de goederen voor een bestelling worden verzameld en in een vrachtwagen worden geladen;
  • De vrachtwagen brengt de goederen naar de winkel;
  • De levering wordt verwerkt, de voorraadstanden worden op het juiste moment aangepast in het DC, op transport en in de winkel;
  • En er wordt een factuur gemaakt.

Als de eenvoudigste variant niet lukt, lukken de moeilijkere gevallen al helemaal niet

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:

  • bestelling aanvragen voor een winkel met rechtstreekse levering;
  • aanvraag omzetten in een bestelling;
  • bestelling/bericht sturen naar DC;
  • pindakaas verzamelen in DC;
  • bericht terugsturen naar SAP/ERP;
  • levering van pindakaas aan winkel verwerken;
  • voorraden van pindakaas bijwerken;
  • factuur maken voor de winkel.

Dat ziet er zo uit:


De user stories kunnen daarna uitgebreid worden met

  • pindakaas bestellen voor winkel type “belevering met tussenstop”;
  • stuk kaas bestellen;
  • ijsjes bestellen;

De hele keten moet eerst werken voor de allersimpelste situatie

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

Het kleinst werkende geheel - Simone Russchen

Meer informatie

Heeft u een vraag of wilt u een vrijblijvende afspraak maken? Laat hieronder uw gegevens achter, dan nemen wij zo snel mogelijk contact met u op. U kunt ons natuurlijk ook bellen:

+31 (0) 33 277 35 22 (Nederland)
+32 (0) 16 39 48 04 (België)

    Uw gegevens gebruiken wij alleen voor een correcte afhandeling van uw vraag. Lees voor meer informatie onze privacyverklaring.

    Hoe wij dat doen?
    Lees meer
    Focus
    Focus
    Vakmanschap
    Vakmanschap
    Kennisdeling
    Kennisdeling
    Persoonlijk
    Persoonlijk
    Lokaal
    Lokaal
    Oprecht
    Oprecht
    Plezier
    Plezier
    Meer
    Deze website is gerealiseerd door Webheads.

    Neem contact op!