incerteza

Sobre spikes

Spiked_War_Club__85853.1333504552.1280.1280A minha motivação para esse post foi que essa semana um amigo veio me perguntar sobre o assunto. Portanto esse post é praticamente a transcrição do que expliquei naquele dia. Como tudo o mais nesse post, reflete a minha visão sobre assunto, que vai muito além do descrito pelos órgãos oficiais.

Spike são quase User Stories, exceto pelo fato de que não se sabe exatamente no que ela vai dar. Pense no spike como uma história sobre a qual você não pode se comprometer por não ter informações ou conhecimento sobre o assunto. Por exemplo, uma equipe de desenvolvimento de um ERP precisa ler informações de uma balança eletrônica para acrescentar esses dados em uma nota fiscal, ou mesmo controlar o quanto será transportado no caminhão. Enfim, esse time nunca lidou com algo semelhante, portanto precisa pesquisar, testar algumas possibilidades e enfim ter uma visão mais clara sobre o que precisa ser feito, até mesmo como.

Podem ser estimados? Eu acabei respondendo essa com outra pergunta, se não seria exatamente por que não sabemos toda a informação necessária para poder estimar e realizar determinada história que o criamos? Portanto, spike não deveria ter uma estimativa em story point ou que seja, mas sim, precisa ter é data pra acabar. Após esse timebox, de posse de mais informação sobre o assunto o time pode finalmente estimar com mais propriedade. Isso pode ser dias, horas, semanas, o quanto o PO e o Time acordarem que seja o adequado. Ao final desse prazo, o mesmo se encerra, atingindo algo tangível ou não. O objetivo pode ser uma prova de conceito, uma pesquisa, uma leitura de uma documentação, o que for.

O conceito básico é: não sabemos o que é, ou como fazer ou as duas coisas, por isso precisamos descobrir pra poder estimar corretamente. Pode acontecer (já vi isso), que no final do spike, parte da implementação já esteja feita, então o time só precisa estimar pra fazer o restante.

Por que limitamos um timebox para o Spike? Não poderíamos buscar até achar a solução? Infelizmente para todos nós, o orçamento nunca é infinito (quem me dera fosse). Portanto é importante estabelecer prazo muito bem definido, para que a busca pela solução não se transforme em uma cruzada pelo Santo Graal.

É importante ser cuidadoso e guiar o time para que, como já citei antes, não é por que descobrimos o martelo, tudo virou prego. Toda história tem um nível de incerteza inerente a ela e mesmo assim podemos dar uma estimativa aproximada. Se um história extrapola esse nível (que não está definido, vai do sentimento do time, de sua segurança), essa tem altas chances de se transformar em spike. Times menos maduros ou muito inexperientes tendem a usar spikes a revelia, como forma de se proteger ao invés de se comprometer com estimativas.

Qual a diferença entre realizar um spike e fazer uma análise? Spike pode envolver implementação, mas pode haver programação que não resulte em produto. Entenda como um tempo pra testar algo, uma idéia, ou buscar mais informações para formar essa idéia. Uma metáfora interessante é que estamos testando uma hipótese. A diferença entre spike e analise é que análise é algo prévio pra determinar o “o que” precisa ser feito. Spike tem muito mais relação com o time determinar “o como”, o que na verdade é o seu domíno.

Finalizando spikes não são coisas complexas ou ferramentas maravilhosas para a solução de um determinado problema. É apenas o time assumindo que não entende o suficiente de determinado assunto e indo buscar o máximo de informações antes de dar qualquer parecer.