Ga naar hoofdinhoud

Spike

Een Spike is een onderzoek dat getimeboxt is waarmee je gericht probeert een specifieke onzekerheid kleiner te maken.

"Put more simply, a spike is an activity a team performs to get smarter about something." - Mike Cohn (2024)

Op de backlog én projectbord​

Een spike onderzoek komt op de backlog te staan, net als een user story. Het is dus een *Product Backlog Item() (PBI) net als een user story, maar anders dan een user story kun je deze niet direct implementeren en integreren in je product, maar moet je wel onderzoek doen om de onzekerheid te verkleinen.

spike

Figuur 1: Spikes komen in je backlog én KanBan/Project planningsbord (bron: Morabia, 2023)

Bouwstenen van een Spike​

Elke spike bevat in ieder geval de onderstaande drie onderdelen:

Bouwstenen
  1. Onderzoeksvraag, of onderzoeksdoel
  2. Type onzekerheid die je wilt onderzoeken
  3. Timebox

Hieronder een uitleg van elk onderdeel.

Onderzoeksvraag, of onderzoeksdoel​

"... a research spike involves creating a list of questions that the research spike aims to answer." - Morabia, 2023

Probeer zo duidelijk en kort mogelijk de vraag of vragen te formuleren. Soms is het een beetje omslachtig om een vraag te verzinnen. Schrijf in dat geval zo duidelijk mogelijk het doel op.

Type onzekerheid​

Zoals eerder vermeld, onderscheiden we drie soorten onzekerheden in dit project. Geef bij elke Spike aan om welk onzekerheid het gaat.

1. Functionele onzekerheid​

  • Functionele eisen/wensen
  • Prioritisatie van functionele eisen/wensen
  • Quality Attributes

2. Technische onzekerheid​

  • Ontwerpkeuzes context- en containerniveau
  • Ontwerpkeuze op component-niveau
  • Ontwerpkeuzes op detailniveau
  • Patternbeschrijving (pattern language) van eigen ontwerpproblemen
  • Pakketselectie (taal/tool/framework technologie-selectie)
  • Pakketselectie voor testen
  • Beperkingen/mogelijkheden van technologie

3. Kennis onzekerheid​

  • Geschiktheid van technologie voor de opdracht (fit)
  • Als team/developer met technologie kunnen werken (taal-, framework- of toolconstraints uit bv. doelarchitectuur opdrachtgever)
  • Conceptuele kennis over domein/subdomein uit opdracht

Timebox​

In PExE moeten alle Spikes een start- en einddatum hebben. Dit tijd tussen start-en einddatum noemen we de timebox van een Spike. Zorg ervoor dat je niet langer dan drie dagen inplant voor een Spike.

Veel onderzoeken hebben geen duidelijk eindpunt waardoor de tijd die je besteedt aan een onderzoek makkelijk uit de hand kan lopen.

Om dit te voorkomen voegen we een timebox toe aan het onderzoek:

"Spike stories are frequently referred to as time-boxed studies since a defined time period is outlined for spikes." (Simplilearn, 2025)

Het idee van de timebox is dat dit je je dwingt om een expliciteit moment te kiezen waarop je de resultaten presenteert en met de groep (en eventueel andere stakeholders) bepaalt of het de moeite waard is om verder te gaan met het onderzoek, of dat je stopt en tevreden bent met de resultaten. Vergeet in beide gevallen niet het tussenresultaat respectievelijk eindresultaat kort te documenteren in de spike, en met wat meer detals te delen/of presenteren aan de rest van de groep en evt. opdrachtgever/projectbegeleider:

"[...] sometimes spikes need more time than has been allotted. In this case, team members need to report the outcome of their investigation to the rest of the team, even if they will need more time to finish the investigation." - Zhezherau, A. (2024)

Resultaat van Spike​

Voordat je een Spike kan afsluiten, neem je als groep een beslissingen over wat je gaat doen met het resulaat van de Spike. Zet deze beslissing als opmerking bij de taak zodra je via GitHub de Spike afsluit.

Plannen​

Elke iteratie maak je een planning waarin je alle Spikes opneemt. Plaats deze op het GitHub project board in de "Iteratie Planning tab".

In het begin van het project zijn de onderzoeksvragen, of -doelen in de Spikes waarschijnlijk vrij open en breed beschreven. Probeer in de loop van het project dit steeds concreter en specifieker te maken.

Zoals Cohn (2024) zijn artikel ook beëindigd:

" Just be cautious that you use [spikes] sparingly, and only in times of excess uncertainty."

Hm... 'times of excess uncertainty', bijvoorbeeld zoals tijdens de gehele elaboratie fase? 😊 Kortom: je zult veel spikes doen in PeXe. Hanteer als ideaalbeeld dat geen spikes meer nodig zijn in de Constructie fase. Dit wel uitgaande dat je met hetzelfde team met de opgebouwde kennis die constructie fase in gaat (los van dat je fase in dit project NIET gaat doen). Neem verder ook mee dat zoals Mike Cohn (2024) zegt:

"Teams need to be comfortable with uncertainty, with bringing work into their sprints or iterations with open issues remaining.

Dus dit laat ook mogelijkheid open dat spike onderzoeken in de Constructie fase plaatsvinden. Maar op hoofdlijnen moet wel je software architectuur en functionaliteit/user stories einde Elaboratie fase duidelijk zijn.

Bronnen