2. Documenteren Flashcards

1
Q

User story

A

Communicatie middel voor requirements.

Korte beschrijving van wat een gebruiker wil. Tegenovergesteld aan use cases zit dit meer op communicatieniveau dan specificatie.

Vertelt een verhaal tussen klant en analist. Moet makkelijk te verstaan zijn, zonder technisch jargon of voorkennis om formaat te begrijpen. Het doel is communicatie tussen IT en business.

Als een … wil ik … Zodat …
Bv: Als een bioscoopbezoeker wil ik mijn tickets laten sturen naar mijn gsm zodat ik niet hoef te wachten aan de kassa.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Waarom user stories

A
  • Makkelijk te verstaan: geen technisch jargon, geen voorkennis nodig.
  • Makkelijk te delen: communicatie tussen IT en business.
  • Lage inspanning: snel op te stellen, moet niet perfect zijn.
  • Makkelijk te plannen: stelt een werkitem voor.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

User story invest regel

A

Een goede user story is:
- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

User story: independent

A

User stories moeten los van elkaar staan. Er kan bv. geen user story zijn die verwacht dat een andere user story al gedaan is.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

User story: negotiable

A

User stories zijn geen contracten, ze beschrijven requirements zonder te specificeren.

Het is de start van een conversatie: de product owners bepalen de richting (verwachting; wat) en de developers bepalen hoe er te geraken (specificaties; hoe).

User stories kunnen wijzigen doorheen het project wanneer er meer kennis wordt vergaard. Sommige stories kunnen worden gesplit of zijn misschien onnodig.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

User story: valuable

A

User story moet een business waarde bevatten zoals bv. meer opbrengsten, lagere kosten, klanten aantrekken, efficienter worden, …

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

User story: small

A

User stories moeten zodanig klein zijn dat kan worden ingeschat hoeveel tijd er in moet geinvesteerd worden, en kan realizeerbaar zijn in korte tijd (1 iteratie bv.).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

User story niveaus

A

Er kunnen meerdere niveaus van stories bestaan om een verhaal te beschrijven:

  • Epics (globale activiteiten, bv. ‘taken uitvoeren’)
  • Stories (bv. ‘als lid wil ik een overzicht van taken’ of ‘als lid wil ik details zien van een taak’, …)
  • Tasks (bv. ‘GET request op basis van lid’, ‘taken Business Logic’, ‘overzicht taken view’, ‘test schrijven’, … )
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Epic

A

Groot stuk functionaliteit die business wil hebben en waarde oplevert. Wordt opgeleverd aan de hand van kleinere user stories, gespreid over meerdere iteraties.

Formaat van user stories moet niet gevolgd worden: mag (of moet) groot zijn.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Task

A

Onderverdeling van stories in uitvoerbare taken. Geschreven door het dev team voor het dev team en mag dus technisch zijn, hoeft geen directe business value te hebben, moet niet onafhankelijk zijn.

Input DevOps is belangrijk hierbij.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Customer journey

A

Ervaring van de klant van begin tot einde visualiseren. Inzicht krijgen in het gedrag van de klant.

Als doel om inzicht te krijgen in het gedrag van de klant.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Customer journey stappenplan

A
  • Creeren van persona’s
  • Identificeren van de verschillende fases, elk met hun doel en beschrijving van de activiteit
  • Identifieer contactpunten tussen klant en bedrijf
  • Beschrijf gevoel van de klant tijdens de actie
  • Identificeer belangrijkste acties
  • Vind ideeen voor verbetering / innovatie
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Story map

A

Visuele oefening om shared understanding te creeren. Business en IT zijn hierbij beide aanwezig.

Brengt in kaart een narrative flow van algemene taken. Dit wordt typisch afgeleid uit de costumer journey en vormt de ‘backbone’. Bv. een product zoeken, product in winkelmandje steken, checkout, …

Onder backbone komen user stories die in meer detail gaan. Bv. producten kunnen sorteren, …

Wanneer alle activiteiten ontdekt zijn, kunnen prioriteiten worden gezet: welke items voor een eerste release? Welke voor latere releases? Vormt de start van een product backlog.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Van customer journey naar story map

A
  1. Na maken van customer journey, beslis wat te investigeren: welke punten verbeteren? Welke pijnpunten weghalen? Welke innovaties maken?
  2. Identificeer kansen en bedreigingen.
  3. Zet een hypothese op.
  4. Identificeer de nodige mensen om het te verwezenlijken.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

MVP

A

Minimum viable product.

Beschrijft wat er nodig is om een ‘goed’ product te bekomen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

MoSCoW methode

A
  • Mo (Must have): essentiele elementen die onmogelijk kunnen ontbreken.
  • S (Should have): belangrijke elementen maar minder van essentieel belang.
  • Co (Could have):leuke extraatjes als er tijd en geld is, nice-to-haves.
  • W (Won’t have): elementen die geen waarde toevoegen.