Desenvolvimento

Ξ Deixe um comentário

Histórias Spike

publicado por Bruno Amaral

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!

  •  
    4
    Shares
  • 4
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

PSM I, PACC, SFC, ISMF, SMAC, IPOF, STMAC, ITILv3 e MCTS. Possuo 19 anos de experiência em TI com background em desenvolvimento. Desde 2008 a liderar equipas de performance. Desde 2010 a trabalhar com Scrum, Kanban e XP. Desde 2017 a desempenhar papel de Scrum Master. Desde 2018 a escrever artigos sobre Scrum, Equipas de Performance e Metodologias Ágeis.

Bruno Amaral

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.