Histórias Spike

Afinal, o que é Spike?

Spike é uma definição proveniente do Extreme Programming. Na verdade Spike Solution. Uma Spike Solution é um programa ou um protótipo funcional para explorar potenciais soluções para um determinado problema.

Tenhas em mente que NUNCA uma Solução Spike deverá sofrer commit na trunk principal.

Qual sua importância?

Segundo o SAFe, estas são as razões para se criar histórias spike:

1. Estimar novas features;
2. Ajudar a entender se a história é viável de ser desenvolvida;
3. Familiarização com uma nova tecnologia, linguagem ou arquitetura;
4. Ganho em confiança numa técnica ou numa abordagem funcional, reduzindo os riscos e criação de histórias spike incertas, desenvolvendo pequenos programas, pesquisas ou testes que demonstrem algum aspecto sobre essa nova funcionalidade ou técnica.

Ainda segundo a SAFe, as Spikes são divididas em Técnica e Funcional.

Spike funcional – São utilizadas para analisar (no geral) o comportamento da solução e determinar:

• Como quebrar as atividades;
• Como organizar o trabalho;
• Risco e existência de complexidade;
• Como usar a compreensão, conhecimento, ou intuição para influenciar as decisões de implementação.

Spikes técnicas – São utilizadas para pesquisar abordagens para uma determinada solução. Por exemplo:

• Determinar uma decisão build-versus-buy;
• Testar a performance ou impacto de carregamento/lentidão no sistema no desenvolvimento de uma nova história de usuário;
• Testar uma nova tecnologia ou abordagem técnica;
• Obter confiança sobre o que será desenvolvido.

Acredito que na maioria dos casos, as histórias de usuário possuem os dois tipos de spikes. Veja o exemplo abaixo:

Como consumidor, Eu quero ver minha posição consolidada de forma rápida no passado, presente e com projeção dos meus diferentes tipos de produtos (Renda Fixa, Fundos de Investimento, Bovespa ou Tesouro Direto).

• Spike técnica para pesquisar o tempo necessário para atualizar as informações da posição consolidada, determinando assim a melhor forma de buscar as informações e mostrar em tela no menor tempo possível;
• Spike funcional construindo um protótipo para pegar feedback sobre a UI/UX da tela.

Quando utilizar uma História Spike?

Às vezes, o backlog do produto possui histórias complexas ou muito grandes. Ao mesmo tempo, deve-se escolher entre uma tecnologia/biblioteca já existente ou desenvolver uma nova. O time não consegue estimar a história, pois tem mais dúvidas do que certezas. Nestas horas a História Spike é bem vinda.

Na Ativa Investimentos utilizamos Histórias Spike para que o time aprendesse NodeJS e Angular5. O expertise do time era de .NET e precisávamos ter essa nova expertise pois a nova posição consolidada seria desenvolvida nestas duas linguagens.

Também utilizamos História Spike para melhorar a performance dos serviços que buscavam as informações de posição consolidada do cliente e preenchia as tabelas do banco de dados. Em dois dias testamos diversas soluções e tecnologias. Depois conseguimos desenvolver um novo serviço, baseado no que foi aprendido. O serviço está em produção e funcionando perfeitamente. Graças ao estudo da História Spike, a equipe conseguiu entender o problema, aprender, buscar uma solução e elaborar uma solução performática (fora da História Spike).

Quanto tempo deve durar uma Spike?

As Histórias Spike são como um evento Time-box. Precisamos definir o tempo e o que será feito durante este tempo. O que tenho visto por aí, são de no máximo 3 dias.

Mas por que definir uma Time-Box? Para que não haja desperdício de tempo com algo que nem se sabe se vai funcionar.

Considerações finais

• As Spikes devem ter sua utilização moderada. Conforme o conhecimento e experiência do time, menos Spikes serão utilizadas;
• Spikes no backlog do produto representam um risco. Elas são histórias não estimadas e possíveis histórias com ambiguidade – histórias que precisam de uma pesquisa para que se saiba o tempo que levará para desenvolver aquela atividade ou solução. Por estas razões, é uma boa prática atacar as histórias Spike no início do projeto, ainda na Sprint 0;
• Histórias Spike devem ser resolvidas o mais breve possível. Elas não devem permanecer por muito tempo no backlog do produto.