Alai

Als we wisten wat we aan het doen waren, zou het geen onderzoek heten.

-Albert Einstein

Spikes zijn een type exploratie Enabler Story in SAFe. Oorspronkelijk gedefinieerd in Extreme Programming (XP), vertegenwoordigen zij activiteiten zoals onderzoek, ontwerp, onderzoek, exploratie, en prototyping. Hun doel is om de kennis te vergaren die nodig is om het risico van een technische aanpak te verminderen, een vereiste beter te begrijpen, of de betrouwbaarheid van een story-schatting te verhogen.

Zoals andere stories, worden spikes geschat en vervolgens gedemonstreerd aan het einde van de Iteratie. Zij verstrekken ook een overeengekomen protocol en een werkstroom die Agile Release Trains (ARTs) gebruiken om de levensvatbaarheid van Epics te helpen bepalen.

Agile en Lean waarderen feiten boven speculatie. Wanneer geconfronteerd met een vraag, risico, of onzekerheid, voeren Agile Teams kleine experimenten uit alvorens over te gaan tot implementatie, in plaats van te speculeren over de uitkomst of over te springen naar een Oplossing. Teams kunnen spikes in een verscheidenheid van situaties gebruiken:

• Opstellen van nieuwe Features en Capabilities om het impliciete gedrag te analyseren, inzicht verschaffend over de aanpak om ze op te splitsen in kleinere, kwantificeerbare stukken
• Haalbaarheidsanalyse uitvoeren en andere activiteiten die helpen de levensvatbaarheid van epics te bepalen
• Basisonderzoek uitvoeren om hen vertrouwd te maken met een nieuwe technologie of domein
• Het vertrouwen winnen in een technische of functionele aanpak, het verminderen van risico en onzekerheid

Spikes impliceren het creëren van een klein programma, onderzoeksactiviteit, of test die één of ander aspect van nieuwe functionaliteit demonstreert.

Technische en Functionele Spikes

Spikes komen hoofdzakelijk in twee vormen voor: technisch en functioneel.

Functionele spikes – Zij worden gebruikt om het algemene gedrag van de oplossing te analyseren en te bepalen:

• Hoe het op te splitsen
• Hoe het werk te organiseren
• Waar risico en complexiteit bestaan
• Hoe inzichten te gebruiken om implementatiebeslissingen te beïnvloeden

Technische spikes – Zij worden gebruikt om verschillende benaderingen in het oplossingsdomein te onderzoeken. Bijvoorbeeld:

• Bepaal een build-versus-buy beslissing
• Evalueer de potentiële prestatie- of belastingseffecten van een nieuwe user story
• Evalueer specifieke technische implementatiebenaderingen
• Ontwikkel vertrouwen over het gewenste oplossingspad

Sommige features en user stories kunnen beide soorten spikes vereisen. Hier is een voorbeeld:

“Als consument wil ik mijn dagelijkse energieverbruik in een histogram zien, zodat ik snel inzicht krijg in mijn vroegere, huidige en verwachte energieverbruik.”

In dit geval zou een team beide soorten pieken kunnen creëren:

• Een technische spike om te onderzoeken hoe lang het duurt om een klantdisplay bij te werken naar het huidige verbruik, het bepalen van communicatievereisten, bandbreedte, en of de gegevens moeten worden gepusht of gepulld
• Een functionele spike – Prototype een histogram in het webportaal en krijg wat feedback van de gebruiker over presentatiegrootte, stijl, en grafiek

Richtlijnen voor spikes

Omdat spikes niet direct gebruikerswaarde leveren, gebruik ze spaarzaam. De volgende richtlijnen zijn van toepassing.

Kwantificeerbaar, Aantoonbaar en Acceptabel

Zoals andere stories, worden spikes in de Team Backlog gezet, geschat, en gedimensioneerd om in een iteratie te passen. Spike resultaten zijn anders dan een story omdat spikes typisch informatie produceren in plaats van werkende code. Ze moeten alleen de nodige gegevens ontwikkelen om met vertrouwen de stories te identificeren en de grootte ervan te bepalen.

De output van een spike is aantoonbaar, zowel voor het team als voor eventuele andere belanghebbenden, wat zichtbaarheid geeft aan de onderzoeks- en architectuurinspanningen, en ook helpt bij het opbouwen van collectief eigenaarschap en gedeelde verantwoordelijkheid voor de besluitvorming. De Product Owner accepteert spikes die zijn gedemonstreerd en voldoen aan zijn acceptatiecriteria.

Timing van Spikes

Omdat ze onzekerheid vertegenwoordigen in een of meer potentiële verhalen, is het plannen van zowel de spike als de resulterende verhalen in dezelfde iteratie soms riskant. Echter, als het klein en eenvoudig, en een snelle oplossing is waarschijnlijk te vinden, dan kan het heel efficiënt om beide te doen in dezelfde iteratie.

De uitzondering, niet de regel

Elke user story heeft onzekerheid en risico; dat is de aard van Agile ontwikkeling. Het team ontdekt de juiste oplossing door discussie, samenwerking, experimenten en onderhandeling. Dus, in zekere zin, elke user story bevat spike-achtige activiteiten om de technische en functionele risico’s te identificeren. Het doel van een Agile team is om te leren hoe om te gaan met onzekerheid in elke iteratie. Spikes zijn kritisch wanneer er grote onzekerheid bestaat, of er zijn veel onbekenden.

Learn More

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Laatste update: 10 februari 2021