Alai

Om vi visste vad vi gjorde skulle det inte kallas forskning.

-Albert Einstein

Spikes är en typ av utforskande Enabler Story i SAFe. De definierades ursprungligen inom Extreme Programming (XP) och representerar aktiviteter som forskning, design, undersökning, utforskning och prototyper. Deras syfte är att få den kunskap som krävs för att minska risken med ett tekniskt tillvägagångssätt, bättre förstå ett krav eller öka tillförlitligheten i en story-estimat.

Likt andra stories uppskattas spikes och demonstreras sedan i slutet av iterationen. De ger också ett överenskommet protokoll och arbetsflöde som Agile Release Trains (ARTs) använder för att hjälpa till att fastställa Epics lönsamhet.

Agile och Lean värderar fakta framför spekulationer. När agila team ställs inför en fråga, risk eller osäkerhet utför de små experiment innan de övergår till genomförande, i stället för att spekulera i resultatet eller hoppa fram till en lösning. Team kan använda spikes i en mängd olika situationer:

• Skatta nya funktioner och förmågor för att analysera det underförstådda beteendet, vilket ger insikt om tillvägagångssättet för att dela upp dem i mindre, kvantifierbara bitar
• Upprätta genomförbarhetsanalyser och andra aktiviteter som hjälper till att fastställa epikernas genomförbarhet
• Upprätta grundforskning för att bekanta sig med en ny teknik eller ett nytt område
• Göra sig säker på en teknisk eller funktionell strategi, minska risken och osäkerheten

Spikar innebär att man skapar ett litet program, en forskningsaktivitet eller ett test som visar någon aspekt av den nya funktionaliteten.

Tekniska och funktionella spikar

Spikar finns främst i två former: tekniska och funktionella.

Funktionella spikar – De används för att analysera övergripande lösningsbeteende och bestämma:

• Hur man bryter ner det
• Hur man organiserar arbetet
• Hur risk och komplexitet existerar
• Hur man använder insikterna för att påverka genomförandebesluten

Tekniska spikar – De används för att forska om olika tillvägagångssätt inom lösningsområdet. Till exempel:

• Bestämma ett beslut om att bygga eller köpa
• Utvärdera den potentiella prestandapåverkan eller belastningspåverkan av en ny användarhistoria
• Utvärdera specifika tekniska implementeringsstrategier
• Utveckla självförtroende om önskad lösningsväg

Vissa funktioner och användarhistorier kan kräva båda typerna av spikes. Här är ett exempel:

”Som konsument vill jag se min dagliga energiförbrukning i ett histogram så att jag snabbt kan förstå min tidigare, nuvarande och förväntade energiförbrukning.”

I det här fallet kan ett team skapa båda typerna av toppar:

• En teknisk spik för att undersöka hur lång tid det tar att uppdatera en kunddisplay till aktuell förbrukning, bestämma kommunikationskrav, bandbredd och om data ska skjutas eller dras
• En funktionell spik – Prototypa ett histogram i webbportalen och få användarfeedback om presentationsstorlek, stil och diagram

Riktlinjer för spikar

Då spikar inte direkt levererar användarnytta bör de användas sparsamt. Följande riktlinjer gäller:

Kvantifierbart, påvisbart och godtagbart

Likt andra stories placeras spikes i Team Backlog, uppskattas och dimensioneras så att de får plats i en iteration. Spike-resultaten skiljer sig från en story eftersom spikes vanligtvis producerar information snarare än arbetskod. De bör endast utveckla de data som krävs för att med säkerhet identifiera och dimensionera de stories som driver dem.

Resultatet av en spike är påvisbart, både för teamet och för eventuella andra intressenter, vilket ger synlighet åt forsknings- och arkitekturinsatserna och hjälper också till att bygga upp ett kollektivt ägarskap och ett delat ansvar för beslutsfattandet. Produktägaren accepterar spikes som har demonstrerats och som uppfyller dess acceptanskriterier.

Timing of Spikes

Då de representerar osäkerhet i en eller flera potentiella berättelser, är det ibland riskabelt att planera för både spike och de resulterande berättelserna i samma iteration. Men om det är litet och okomplicerat, och det är troligt att en snabb lösning kommer att hittas, kan det vara ganska effektivt att göra båda i samma iteration.

Utantaget, inte regeln

Varje användarberättelse har osäkerhet och risk; det ligger i den agila utvecklingens natur. Teamet upptäcker den rätta lösningen genom diskussion, samarbete, experimenterande och förhandling. Således innehåller varje user story i en mening spikrakaktiviteter för att identifiera de tekniska och funktionella riskerna. Målet för ett agilt team är att lära sig att hantera osäkerheten i varje iteration. Spikes är kritiska när det råder stor osäkerhet eller när det finns många okända.

Lär dig mer

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

Sista uppdateringen: 10 februari 2021