“If we knew what it was we were doing, it would not be called research, would it?” – Albert Einstein
“Se você soubesse o que estamos fazendo, não chamaríamos de pesquisa”. Basicamente, esta é a definição de “Spike”.
Em métodos ágeis, principalmente SCRUM ou XP, uma Spike é uma user story com pouca ou nenhuma definição. Pense em algo que você precisa fazer ou desenvolver mas tem pouco ou nenhum conhecimento sobre isso. Sendo assim, como estimar o esforço, custo, tempo e outras estimativas, se você não tem experiência ou conhecimento no assunto?
Em Scrum, quebramos as User Stories em atividades. Precisamos fazer isso para gerar estimativas e planejar as sprints seguintes. Mas como fazer isso com uma User Story que ninguém da equipe do projeto possui conhecimento? Ela não pode ser simplesmente descartada por esta falta de conhecimento.
Nem sempre podemos contar com especialistas a todo instante nos fornecendo informações sobre tudo o que temos que realizar em projetos. Em alguns casos precisamos testar e pesquisar!
“O Projeto está indo bem”. Não estará se você finge que sabe algo e começa a fazê-lo mesmo assim.
Exemplo em TI: Você precisa estimar o desenvolvimento de 30 telas, parecidas. Nesta estimativa, você precisa fornecer o tempo/custo necessário para desenvolver todas estas telas. O problema é que o desenvolvimento será feito em uma linguagem ou plataforma que você não trabalhou antes. Como fazer isso?
Exemplo no Cotidiano: Você quer muito ter um aquário mas nunca cuidou de um antes. Seu sonho é ter um aquário enorme, de 700 litros, mas por não conhecer nada sobre isso, como fazer para ter certeza que escolherá o modelo certo?
Considerando que em ambos os casos não temos especialistas para nos dizer o que fazer, precisaremos pesquisar, precisamos realizar uma “prova de conceito“.
Entenda “Spike” como um evento “Time-box“, ou seja, um evento com tempo pré-definido e limitado. Este período precisa ser definido, bem como o que será feito nele. Ao realizar este evento, você terá uma definição mais clara do que e como realizar aquela atividade.
O exemplo em TI: No nosso exemplo, a Spike poderia ser o desenvolvimento de 4 telas, com o limite de 1 mês. Com base na dificuldade encontrada, o tempo encontrado, você terá melhor definição para estimar as telas restantes e até mesmo descobrir que precisará de menos ou mais telas!
O exemplo no cotidiano: Ao invés de sair comprando todos os itens de um aquário enorme, defina que você irá montar um menor, de 10 ou 20 litros e precisará pesquisar os equipamentos. Você pode descobrir que um filtro A é melhor que um filtro B, que uma ração não faz bem ao peixe X, entre outras descobertas. Poderá perceber que com sua rotina não conseguirá cuidar dos peixes nos horários ideais, chegando a conclusão que não pode ter um aquário grande, e sim um médio ou até mesmo pequeno.
O conceito básico de spike é: Não sabemos o que é, não sabemos como fazer e precisamos descobrir isso rapidamente e corretamente.
Porque a Spike é um time-box? Porque possui este limite de tempo? Simples, não podemos ficar apenas pesquisando ou buscando a solução perfeita (como por exemplo comprar o aquário enorme e ir descobrindo o que fazer com tentativa e erro). Isso gera custos e desperdícios desnecessários.
Qual a diferença de Spike para uma “Análise”? A Spike é uma forma de descobrir “como” fazer, e uma análise é mais voltada em descobrir “o que” fazer.
Entenda que Spike não é uma ferramenta mágica, não é um solucionador definitivo para todos os problemas. A Spike mostra que um time assumiu que não possui experiência em algo, mas quer realizá-la e não sabe como, porém ,precisa descobrir “como” e ver se a ideia é realmente viável e atingível.
Um projeto precisa ser “desejável, viável e realizável”. São 3 variáveis básicas onde se uma falhar, as demais falharão. E a Spike ajudará a unir estes 3 conceitos.
Além disso, a Spike é focada no conceito ágil de “falha rápida”. Se for pra falhar, que seja rapidamente, no início dos trabalhos, ao invés de aguardar um desenvolvimento quase completo.
“Nós vamos pedir as estimativas e tratá-las como se fossem limites de prazo”
Precisamos ser cuidadosos com estimativas e Spikes. Toda user story possui um grau de incerteza, isso faz parte do próprio conceito de desenvolvimento ágil. O time de desenvolvimento não pode usar spikes a vontade pra toda e qualquer user story, ao invés de se comprometer com estimativas, usando para isso Spikes como forma de proteção do time.
Apesar disso, toda a equipe precisa entender que uma “estimativa” não é um prazo fechado e definido. Precisam buscar a eficiência e eficácia, buscando a entrega antes do tempo estimado ao invés de trabalhar com todo o tempo disponível apenas por ter este tempo disponível.
Espero que tenha ajudado vocês a entenderem um pouco mais sobre Spikes!
Gostou, achou interessante ou tem dúvidas? Comente e compartilhe!
