Histórias Spike

Histórias Spike. Já ouviu falar deste termo? O que são? Qual sua relevância nas Sprints? Neste texto, terás informações valiosas sobre como trabalhar com estas histórias sem prejudicar as entregas de valor. Boa leitura!

Afinal, o que são histórias Spike?

Spike é uma definição proveniente do Extreme Programming que teve sua origem da Spike Solution que, por sua vez, é um programa ou um protótipo funcional para explorar potenciais soluções para um determinado problema.

Qual sua importância?

Segundo o SAFe, estas são as razões para criarmos histórias Spike:

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

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

Spike funcional – é utilizada 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écnica – é utilizada a fim de 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 desenvolver de uma nova história de usuário;
• Testar uma nova tecnologia ou abordagem técnica;
• Obter confiança sobre o que será desenvolvido.

Na maioria dos casos, as histórias de usuário possuem os dois tipos de Spikes. Veja o exemplo abaixo:

COMO um consumidor, EU QUERO ver a 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, Ibovespa ou Tesouro Direto) PARA acompanhar a evolução do meu patrimônio.

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

Quando utilizar uma história Spike?

Por vezes, o backlog do produto possui histórias complexas ou muito grandes (épicos). 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 faz-se bem vinda!

Na Ativa Investimentos utilizamos histórias Spike para que o time aprendesse NodeJS e Angular5, a desenvolver um protótipo de uma nova posição consolidada para o portal do cliente. O grupo possuía experiência em .NET e a equipa utilizou o protótipo para aprender as linguagens que já tinham sido adotadas por outra equipa em São Paulo. Também utilizamos histórias Spike para melhorar a performance dos serviços que obtêm as informações de posição consolidada do cliente. Ao final de dois dias, testamos diversas soluções e tecnologias e chegamos a um protótipo com um serviço mais performático.

Não se deve utilizar um protótipo criado durante a Spike como solução final de um produto ou solução. Com o aprendizado das duas histórias, o time teve conhecimento suficiente para desenvolver as duas melhorias propostas nas soluções já existentes (manutenção evolutiva).

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 com ele. Na minha experiência pessoal, a Time-Box deve ser de 3 dias, independente da duração da Sprint.

Podes estar a perguntar-te porque do uso de um limite de tempo? Por um bom motivo. Para que não haja desperdício de tempo com algo que nem se sabe se funcionará.

O time precisa do sentimento que aquela pesquisa está a levá-los para algum rumo.

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.

Até o próximo post!