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:
- Estimar novas features;
- Ajudar a entender se a história é viável de ser desenvolvida;
- Familiarizar com uma nova tecnologia, linguagem ou arquitetura;
- 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!