Quest: Werk je schets uit tot user stories¶

Bij het profielpagina-project heb je geleerd om een papieren schets te maken voordat je gaat programmeren. Daarmee bepaalde je de structuur en het uiterlijk van je pagina. Voor dit project gaan we een stap verder: je gaat je idee niet alleen schetsen, maar ook vertalen naar user stories — kleine, concrete stukjes werk die je kunt plannen en opleveren.

Waarom user stories?

Als je begint met programmeren is het verleidelijk om meteen code te schrijven. Maar zonder een duidelijk plan loop je al snel vast: wat moet er precies werken? Wanneer ben je klaar? User stories helpen je om je project op te knippen in behapbare stukken die je stuk voor stuk kunt afwerken.

Stap 1: Schets je idee¶

Je hebt bij het vorige project geleerd hoe waardevol een schets is. Doe dat nu opnieuw voor je Programming 101 project:

Pak pen en papier (of een whiteboard) en teken hoe je animatie/game eruit moet gaan zien.
Teken meerdere “schermen” of situaties: hoe ziet het er bij de start uit? Wat gebeurt er bij interactie? Wat als het spel voorbij is?
Noteer bij elk onderdeel wat de gebruiker kan doen (klikken, toetsen indrukken, bewegen).

Denk als een gebruiker

Stel je voor dat iemand anders jouw animatie voor het eerst opent. Wat zien ze? Wat kunnen ze doen? Wat verwachten ze?

Stap 2: Van schets naar user stories¶

Kijk nu naar je schets en bedenk: wat moet er allemaal werken om dit resultaat te bereiken?

Schrijf voor elk onderdeel een user story in het format:

Als [gebruiker] wil ik [actie/doel] zodat [waarde/reden].

Bijvoorbeeld, stel je maakt een “Avoider”-game:

Als speler wil ik een cirkel op het scherm zien zodat ik weet waar mijn karakter is.
Als speler wil ik mijn cirkel met de pijltjestoetsen kunnen besturen zodat ik obstakels kan ontwijken.
Als speler wil ik dat er blokken van boven naar beneden vallen zodat er een uitdaging is.
Als speler wil ik een score zien die oploopt zodat ik weet hoe lang ik heb overleefd.
Als speler wil ik dat het spel stopt als een blok mijn cirkel raakt zodat er een duidelijk einde is.
Als speler wil ik het spel opnieuw kunnen starten zodat ik het nog een keer kan proberen.

Let op: het worden er snel veel!

Dat is precies de bedoeling. Een simpele schets levert al gauw 10 tot 20 user stories op. Dat klinkt misschien als veel, maar elke story is juist klein — en dat maakt ze behapbaar. Als je maar 3 of 4 stories hebt, zijn ze waarschijnlijk te groot en moet je ze opsplitsen.

Stap 3: Maak ze klein¶

Een veelgemaakte fout is dat user stories te groot zijn. Controleer elke story met deze vuistregel: kan ik dit in een paar uur bouwen en testen? Zo niet, splits de story op.

Bijvoorbeeld, deze story is te groot:

Als speler wil ik een compleet werkend spel zodat ik kan spelen.

Dit is eigenlijk je hele project in één zin. Splits het op in kleinere stappen:

Als speler wil ik een canvas zien met een achtergrondkleur zodat de game-omgeving zichtbaar is.
Als speler wil ik een karakter op het scherm zien zodat ik weet wat ik bestuur.
Als speler wil ik dat het karakter reageert op toetsenbordinput zodat ik het kan bewegen.
…

Gebruik het INVEST-principe om je stories te toetsen. Let vooral op de S (Small) en de I (Independent): elke story moet los van andere stories te bouwen én te testen zijn.

Strategieën om te splitsen

Workflowstap: zien → bewegen → botsen → scoren → resetten
Happy path eerst: eerst de basis laten werken, daarna randgevallen (wat als de speler buiten het scherm gaat?)
Interactie per input: eerst muis, dan toetsenbord
Visueel vs. logica: eerst iets tekenen, dan het gedrag toevoegen

Stap 4: Voeg acceptatiecriteria toe¶

Elke user story heeft acceptatiecriteria nodig — wanneer is de story echt klaar? Schrijf bij elke story minimaal 2 criteria.

Bijvoorbeeld bij “Als speler wil ik mijn cirkel met de pijltjestoetsen kunnen besturen”:

De cirkel beweegt naar links bij het indrukken van de linkerpijltjestoets.
De cirkel beweegt naar rechts bij het indrukken van de rechterpijltjestoets.
De cirkel kan niet buiten het canvas bewegen.

Stap 5: Orden en prioriteer¶

Je hebt nu een lijst met user stories. Zet ze in een logische volgorde:

Wat moet er eerst werken voordat andere dingen kunnen? (bijv. je hebt een canvas nodig voordat je er iets op kunt tekenen)
Wat is het belangrijkst voor een werkend eindresultaat?
Wat is nice-to-have als je tijd over hebt?

Begin met het skelet

Start met de stories die samen het minimale werkende resultaat opleveren. Als die af zijn heb je al iets om te laten zien — de rest is bonus.

Opleveren¶

Maak in je GitLab-repository een bestand USERSTORIES.md aan en zet hierin:

Je user stories in volgorde van prioriteit.
Bij elke story de acceptatiecriteria.
Markeer stories die je af hebt met een vinkje (- [x]).

Houd dit bestand bij tijdens het project: als je een story af hebt, vink je hem af. Zo heb je altijd overzicht over wat er nog moet gebeuren.

Peer feedback — Checklist¶

Vraag een medestudent om jouw user stories te reviewen. Loop samen de volgende checklist door:

Zijn er minimaal 10 user stories opgeschreven?
Zijn alle stories geschreven in het “Als … wil ik … zodat …” format?
Is elke story klein genoeg om in een paar uur te bouwen?
Heeft elke story minimaal 2 acceptatiecriteria?
Zijn de stories onafhankelijk van elkaar te bouwen?
Zijn de stories in een logische volgorde geplaatst?
Komt elke story terug in de schets (is er niets verzonnen dat niet op de schets staat)?
Zijn er geen stories die eigenlijk meerdere dingen tegelijk beschrijven?

Portfolio bewijs

Maak een screenshot van de ingevulde checklist als bewijs voor je portfolio. Noteer de naam van je medestudent en de datum bij het screenshot.