Per stimare o sviluppare una user story a volte è necessario documentarsi su aspetti tecnici che non padroneggiamo. Nel mondo agile questa pratica viene chiamata spike
Uno degli aspetti che si sottovalutano degli spike è che con il tempo costituiscono una knowledge base molto utile per lo sviluppatore. Un altro aspetto importante è che non vengono fatti esperimenti sul codice di produzione.
Personalmente gli spike li committo in un repository chiamato Spikes cercando di dare dei nomi significativi alle varie solution in modo da poterli ritrovare facilmente in seguito es: HowToCenterTextVerticallyWithWpf.sln. Inoltre cerco di scrivere, se possibile, tutto il codice in un unico metodo per ritrovarlo facilmente. Lo scopo dello spike non è codice object oriented o con un'architettura malleabile, ma semplicemente di rispondere ad una domanda tecnica ben precisa.
Gli svantaggi nello scrivere gli spike nel codice di produzione sono: difficoltà nel ritrovarli in futuro; qualità del codice compromessa in quanto non sapendo esattamente cosa fare si rischia di scrivere molto più codice del necessario.
Un altro utilizzo molto utile dello spike è quello di cercare diverse soluzioni per lo stesso problema in modo da scegliere la più semplice. In questo caso trovo utile decidere prima un timebox fisso (tipo mezza giornata) per non rischiare di perdere troppo tempo. A volte il timebox è meno importante perchè non si conosce alcuna soluzione al problema e quindi è necessario andare avanti finchè non si trova oppure si rinuncia alla feature.