Userstory
Een userstory is een korte beschrijving (story) van wat een gebruiker (user) wil bereiken. Userstory's worden gebruikt bij de ontwikkeling van software of producten. Een userstory bestaat uit enkele zinnen in gewone spreektaal van de (computer)gebruiker, waarin staat wat de gebruiker doet of moet doen, als onderdeel van z'n werk. Userstory's worden gebruikt binnen agile software development als een manier om de requirements te beschrijven. Daarvoor gebruikt men vaak deze structuur: "Als [rol] wil ik [functie] om [doel te bereiken]."
Het geheel is weinig gedetailleerd en moet passen op een post-it. Het is de belangrijkste manier waarop de gebruiker invloed heeft op de functionaliteit van het te ontwikkelen systeem of product.
Userstory's kunnen ook door ontwikkelaars geschreven worden om niet-functionele eisen vast te leggen, bijvoorbeeld op het gebied van beveiliging, kwaliteit en performance,[1] maar de eerstverantwoordelijke voor de verzameling van de userstory's is de producteigenaar.
Voorbeelden[bewerken | brontekst bewerken]
- Start van de applicatie: "Als gebruiker wil ik na het starten van de applicatie het document zien waarin ik de vorige keer werkte, zodat ik meteen verder kan gaan waar ik gebleven was."
- Zoekfunctie in de applicatie: "Als gebruiker wil ik mijn klanten zowel op voornaam als op achternaam kunnen opzoeken, zodat ik klanten beter kan vinden."
- Stoppen van de applicatie: "Bij het sluiten van de applicatie wil ik de vraag krijgen of ik mijn werk wil opslaan, zodat wijzigingen niet onbedoeld worden verwijderd."
Gebruik[bewerken | brontekst bewerken]
Userstory's worden gebruikt bij diverse agile ontwikkelingsmethoden, zoals XP en Scrum. Userstory's bepalen wat er wordt gemaakt bij softwareprojecten. Door de gebruiker/producteigenaar/klant worden de userstory's op volgorde van belangrijkheid gesorteerd. Vervolgens worden ze in taken uitgesplitst en van meer exacte tijdsschattingen voorzien door de ontwikkelaars.
Voordelen[bewerken | brontekst bewerken]
XP en andere agile ontwikkelingsmethoden hebben een voorkeur voor face-to-face-communicatie en begrijpelijke documentatie die snel aangepast kan worden in plaats van zich op het probleem te concentreren.
Userstory's helpen hierbij:
- Ze zijn erg kort. Ze bevatten zaken die in een korte tijd gemaakt kunnen worden, eerder in dagen dan weken.
- Ze hebben weinig onderhoud nodig.
- Ze maken het mogelijk dat projecten in kleine onderdelen worden opgesplitst.
- Ze zijn erg geschikt voor projecten waar de eisen en wensen steeds wijzigen, of slecht begrepen worden.
- Ze maken het makkelijker om de tijd in te schatten die nodig is om het te maken.
- Om ze te schrijven is het nodig dat de gebruikers bij het systeem betrokken worden zodat de meest waardevolle zaken uit gebruikersoogpunt ook gerealiseerd worden.
Storymaps[bewerken | brontekst bewerken]
Een storymap[2] is de grafische weergave van de productbacklog. Bovenaan staan de grote userstory's; die worden soms "epics” genoemd. De story's worden gegroepeerd in de volgorde waarop je het systeem zou uitleggen aan een onbekende. Verticaal, onder de epics, staan de userstory's op hun kaartjes, in volgorde van belangrijkheid. De eerste horizontale rij is een zogenaamd "walking skeleton"[3], daaronder wordt het fijnmaziger.[4]
Op deze manier is het zelfs mogelijk om grote systemen te beschrijven zonder het overzicht te verliezen.
Zie ook[bewerken | brontekst bewerken]
Referenties[bewerken | brontekst bewerken]
Bronnen, noten en/of referenties
|