Prioriteren van het werk in een User Story Map

Wanneer we het werk (user stories) gaan inplannen in releases is het belangrijk dat we beginnen met de zaken die de grootste impact hebben, voor zowel de stakeholders als de implementatie (refactoring noodzaak voorkomen). Hiervoor moet helder worden wat met de verschillende begrippen uit het domein bedoeld wordt en welke consequenties de wensen van stakeholders hebben voor de realisatie van het systeem.

Maar wanneer een (probleem)domein groot genoeg is loop je tegen de ambiguïteit van onze taal aan, het is namelijk goed mogelijk dat je te maken hebt met verschillende betekenissen van hetzelfde begrip bij verschillende stakeholders. Verder kun je jezelf ook afvragen of je altijd alles “zelf” moet ontwikkelen, dat is namelijk lang niet altijd het meest efficiënt of wat de grootste business value oplevert.

Subdomein

Een begrip kan voor verschillende stakeholders iets anders betekenen en dat betekent dat een domein object op tegenstrijdige manieren gemodelleerd zou moeten worden, bijvoorbeeld een tomaat (zie figuur 1).

PlantUML broncode voor "Voorbeeld tomaat en subdomeinen"

@startuml
title Tomato in Different Domains

package "Botanical Classification" {
    [Tomato] --> [Fruit] : "Scientifically a"
}

package "Culinary Classification" {
    [Tomato] --> [Vegetable] : "Used as a"
}

package "Theatrical Feedback" {
    [Tomato] --> [Criticism] : "Thrown as"
}

@enduml

Natuurlijke taal beschrijving nog niet beschikbaar voor dit diagram type.

Figuur 1: Tomaat in verschillende subdomeinen

Hoe gaan we hiermee om in onze domein analyse? ⇒ inrichten van een bounded context (sub-domeinen opstellen)

Figuur 2: Jeff Patton: I'm glad we agree: Over gebruik van woorden en begrippen in een project

Figuur 3: Hoe maak je indeling van domein in subdomainen (Concepts; bron: Londontechleaders.com, Nick Tune 14/09/21

Figuur 4: Verschillende manier (Defining boundaries; bron: Londontechleaders.com, Nick Tune 14/09/21

Business value

Om te bepalen waar de grootste business value te vinden is in de geïnventariseerde user stories is het belangrijk om onderscheid te maken tussen dat gedeelte van het domein dat uniek is voor de business (core domain) en wat ondersteunend (supporting domain) of generiek (generic domain) is. Het belangrijkste onderscheid moet gemaakt worden tussen wat door het ontwikkelteam zelf gerealiseerd dient te worden (core domain) en waar bestaande oplossingen voor gezocht en geïntegreerd kunnen worden. Dat levert substantiëel andere taken op om de user stories te voltooien met bijbehorend verschil in benodigde inspanning, bij het plannen van releases willen we daar al rekening mee houden. Bovendien is de meerwaarde van een te ontwikkelen product met name te vinden in het core domein, omdat dit een voorsprong geeft ten opzichte van de concurrentie.

Figuur 5: Core domain en supporting/generic domain (Bron: speakerdeck.com. Michael Plöd, 4 mei 2020)

🗣 Core vs supporting of generic domain

Het verschil tussen een supporting domain en een generic domain is erg afhankelijk van wat de core business precies is en niet altijd even eenduidig. Daarom is het voor jullie op de toets met name van belang dat je onderscheid kunt maken tussen een core (sub)domain en een supporting/generic domain bij een casus beschrijving. (Het verschil tussen generic en supporting is meer subjectief en minder belangrijk)