Kravutredning med spikes

25 03 2010

Första gången jag stötte på tekniken ”spike” var när vi i ett projekt stod inför ett teknikval med många osäkerhetsfaktorer. Vi gjorde helt enkelt ett antal time-boxade spikes på de olika alternativen för att skaffa oss kunskap och kunde ganska snabbt utesluta två av fyra alternativ. En ”spike” är att snabbt göra ett experiment på ett alternativ, och experimentet ska slängas bort. Det behöver inte vara funktionsdugligt eller leveransdugligt utan bara ett experiment. Målet är att efter ”spiken” fatta beslut om vi ska gå vidare med något och göra det ordentligt.

Nyligen använde vi samma metod ”spike” i ett fall av ett svårt krav som varken kravställarna/produktägaren eller utvecklarna hade en riktigt klar bild av. Vi bestämde att vi gör en utvecklingsspike för att prova ett förslag på design och för att skaffa oss kunskap. Timeboxade till 2 dagars programmering.

Under dessa 2 dagar utvecklades mycket snabbt några funktioner som provade systemdesignmodellen. I samband med det ställdes helt plötsligt, inte särskilt förvånande, rätt sorts frågor till kravaren, kunden, verksamhetsarkitekten, om begrepp, om interaktion, om regler mm och på bara 2 dagar hade hela teamet med kravare o testare fått en bra bild av vad vi egentligen vill ha. Valet kommer innebära ett ordentligt programmeringsjobb och en del refaktorisering som vi tar med oss i nästa sprint (iteration). Vi kastar experiment-koden och bygger ordentligt med en mycket högre känsla av att göra rätt.

Ungefär som att hastigt slänga upp en kuliss på en yta där man vill ha sitt hus, för att se hur det gör sig på platsen, hur rummen kan placeras, provar några snabba färger, för att sen riva ner och bygga som det ska.

Det kräver en enorm disciplin att faktiskt i princip kasta koden, och att INTE dema eller använda kulissen som någon slags fungerande mjukvara, men har man disciplinen så har vi fått en enorm kunskapsvinst på mycket kort tid som ger oss möjlighet att få bra feedback snabbt och designa rätt lösning med trygghet.

Det här är inte sista gången jag använder spikes som teknik för att förstå krav och behov.

Spikes skiljer sig stort från traditionell krav-prototyping som ofta sker i mock-up-verktyg för att t.ex pröva en interaktionsdesign. Inget illa om mock-ups och prototyp-skisser, men det är verkligen först vid programmering som vi verkligen ställer de rätta designfrågorna – och kostnadsfrågorna.

Advertisements

Åtgärder

Information

2 responses

31 03 2010
Erik Fors-Andrée

Hur förhåller sig en spike till ett proof-of-concept?

31 03 2010
Ulrika Park

Jag skulle säga att en spike är ett experiment, det ska kastas och kan bli vad som helst, ett test på en idé medan proof-of-concept är en kvittens, ”fungerar det som vi tänkt oss”. En spike behöver inte alls vara genomtänkt – det är ett fritt testskott.

En spike tycker jag är uttalat extremt kort medan proof-of-concept i min värld kan, men måste inte vara, något mer genomarbetad.

Spelar ingen roll vad man kallar det 🙂

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s




%d bloggare gillar detta: