Alai

Hvis vi vidste, hvad vi lavede, ville det ikke blive kaldt forskning.

-Albert Einstein

Spikes er en form for udforskning Enabler Story i SAFe. De blev oprindeligt defineret i Extreme Programming (XP) og repræsenterer aktiviteter som f.eks. forskning, design, undersøgelse, udforskning og prototyping. Deres formål er at opnå den viden, der er nødvendig for at reducere risikoen ved en teknisk tilgang, bedre forstå et krav eller øge pålideligheden af et historiestimat.

Lige andre historier estimeres spikes og demonstreres derefter ved slutningen af iterationen. De giver også en aftalt protokol og arbejdsgang, som Agile Release Trains (ARTs) bruger til at hjælpe med at bestemme levedygtigheden af Epics.

Agile og Lean værdsætter fakta frem for spekulationer. Når Agile Teams står over for et spørgsmål, en risiko eller usikkerhed, udfører de små eksperimenter, før de går over til implementering, i stedet for at spekulere i resultatet eller springe til en løsning. Teams kan bruge spikes i en række forskellige situationer:

• Vurdere nye funktioner og kapaciteter for at analysere den implicitte adfærd, hvilket giver indsigt i tilgangen til at opdele dem i mindre, kvantificerbare dele
• Udføre gennemførlighedsanalyser og andre aktiviteter, der hjælper med at bestemme levedygtigheden af epics
• Udføre grundforskning for at gøre dem bekendt med en ny teknologi eller et nyt domæne
• Gøre tillid til en teknisk eller funktionel tilgang, reducere risiko og usikkerhed

Spikes indebærer at skabe et lille program, en forskningsaktivitet eller en test, der demonstrerer et eller andet aspekt af ny funktionalitet.

Tekniske og funktionelle spikes

Spikes findes primært i to former: tekniske og funktionelle.

Funktionelle spikes – De bruges til at analysere den overordnede løsningsadfærd og bestemme:

• Hvordan det skal nedbrydes
• Hvordan arbejdet skal organiseres
• Hvor risiko og kompleksitet findes
• Hvordan indsigt kan bruges til at påvirke implementeringsbeslutninger

Tekniske spikes – De bruges til at undersøge forskellige tilgange inden for løsningsdomænet. For eksempel:

• Bestemme en build-versus-buy-beslutning
• Evaluere den potentielle ydeevne eller belastningspåvirkning af en ny brugerhistorie
• Evaluere specifikke tekniske implementeringstilgange
• Udvikle tillid til den ønskede løsningsvej

Nogle funktioner og brugerhistorier kan kræve begge typer af spikes. Her er et eksempel:

“Som forbruger ønsker jeg at se mit daglige energiforbrug i et histogram, så jeg hurtigt kan forstå mit tidligere, nuværende og forventede energiforbrug.”

I dette tilfælde kan et team måske oprette begge typer spikes:

• En teknisk spike for at undersøge, hvor lang tid det tager at opdatere et kundedisplay til det aktuelle forbrug, bestemme kommunikationskrav, båndbredde og om dataene skal pushes eller trækkes
• En funktionel spike – Prototype et histogram i webportalen og få noget brugerfeedback om præsentationsstørrelse, stil og diagrammer

Retningslinjer for spikes

Da spikes ikke direkte leverer brugerværdi, skal du bruge dem sparsomt. Følgende retningslinjer gælder:

Kvantificerbare, påviselige og acceptable

Som andre historier sættes spikes i Team Backlog, estimeres og dimensioneres til at passe ind i en iteration. Spike-resultater adskiller sig fra en historie, fordi spikes typisk producerer information snarere end arbejdskode. De bør kun udvikle de nødvendige data til at identificere og dimensionere de historier, der driver den, med sikkerhed.

Outputet af en spike er påviseligt, både for teamet og for eventuelle andre interessenter, hvilket giver synlighed til forsknings- og arkitekturindsatsen og hjælper også med at opbygge kollektivt ejerskab og delt ansvar for beslutningstagning. Product Owner accepterer spikes, der er blevet demonstreret og opfylder sine acceptkriterier.

Timing af spikes

Da de repræsenterer usikkerhed i en eller flere potentielle historier, er det nogle gange risikabelt at planlægge både spike og de resulterende historier i den samme iteration. Men hvis det er lille og ligetil, og der sandsynligvis vil blive fundet en hurtig løsning, kan det være ganske effektivt at gøre begge dele i samme iteration.

Udtagelsen, ikke reglen

Alle brugerhistorier har usikkerhed og risiko; det er Agil udviklings natur. Holdet opdager den rigtige løsning gennem diskussion, samarbejde, eksperimenter og forhandling. Derfor indeholder hver brugerhistorie i en vis forstand spike-lignende aktiviteter til at identificere de tekniske og funktionelle risici. Målet for et agilt team er at lære, hvordan man håndterer usikkerhed i hver iteration. Spikes er kritiske, når der er stor usikkerhed, eller når der er mange ubekendte.

Lær mere

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

Sidste opdatering: 10. februar 2021