Spike em métodos ágeis: Adquirindo conhecimento durante a Sprint

Para manter um time multidisciplinar, capaz de resolver problemas e propor soluções, é preciso aprender constantemente sobre assuntos diversos. E essa prática deve refletir na sua sprint e no seu produto.

O plano de desenvolvimento de um produto normalmente é composto por coisas que já sabemos e outras que ainda não, mas tentamos prever. Por isso, algumas vezes precisamos criar um item de backlog focado em explorar novas soluções e adquirir conhecimento para esclarecer o que não sabemos. No mundo dos métodos ágeis essa atividade é chamada de Spike.

O Spike tem o objetivo de obter conhecimento necessário para reduzir o risco de uma abordagem técnica inadequada e entender melhor os requisitos técnicos para aumentar a confiabilidade do time, e então desenvolver e estimar uma feature com assertividade. Assim você utiliza um tempo na sua sprint conhecendo sobre uma nova solução para decidir com mais segurança e poupar tempo e dinheiro com retrabalho no futuro.

Existem várias formas de conduzir um Spike e validar se uma nova solução é adequada ao seu produto e reduzir as suas dúvidas: fazer um protótipo, uma prova de conceito, um experimento, um estudo etc. Estas atividades vão servir para colher informações importantes para a tomada de decisão.

Quando fazer

Provavelmente você já escutou a seguinte frase: “Conheci essa nova ferramenta. Parece que resolve o problema X. Vamos experimentar?”. Bom, essa é uma ótima ocasião para criar um Spike.

Tomar uma decisão se é melhor usar a ferramenta A ou B, se deve desenvolver uma solução ou contratar/comprar uma, ou até mesmo se devemos começar a trabalhar com uma plataforma ou linguagem que o time nunca trabalhou antes. Essas são boas oportunidades para você ter um tempo na sua sprint focado no aprendizado.

Dessa forma o time ganha confiança técnica sobre qual é o melhor caminho para alcançar a solução desejada, reduzindo riscos e incertezas.

Como fazer um Spike

Deve ser tratado como um item de backlog. Ele deve ser criado, detalhado com o que se espera ao final daquele experimento, priorizado e alocado na sprint.

Veja um exemplo: o time tem que avaliar se devemos usar a arquitetura A ou B para sustentar a nova feature X. É proposto fazer um protótipo das duas arquiteturas e realizar testes de performance, testes de carga e alguns testes padrões. E ao final deve ser criado um documento descrevendo o experimento, os resultados obtidos e recomendações.

É importante que o Spike tenha um limite de duração pré-determinado, afinal em um time ágil e principalmente em um ambiente de Startup, você não tem tempo o suficiente para ficar pesquisando até encontrar a solução perfeita.

Listei algumas formas de como você pode controlar o tempo da sua atividade de aprendizado:

• Limite de tempo: Ela pode ter um tempo de X horas, um dia, uma semana, uma Sprint ou até mesmo até uma data específica.
• Limite de esforço: Você pode compará-la a outro item de backlog e reservar na sua contagem de pontos um valor de esforço dentro da sua sprint. Por exemplo: “A atividade deve ter o tempo equivalente a um item de backlog de esforço X”.
• Limite de budget: Se é uma tarefa que existem gastos para ser testada, ela pode ser limitada por budget, por exemplo: “Você poderá usar até 50$ em tal ferramenta”.
• Limite de possibilidades: Eu sei que sempre queremos ter acesso a todas as possibilidades para escolhermos a melhor, mas as vezes não temos tempo para isso. Então você pode limitar número de possibilidades para serem analisadas, exemplo: “Avaliar duas possibilidades de arquitetura para o mecanismo X”. E caso não sejam satisfatórias, você pode criar outro Spike para avaliar outras duas e assim por diante.

Entregável de um Spike

Esse é o momento de ensinar a equipe o que foi aprendido, independentemente de qual foi o experimento feito, seja um protótipo, uma prova de conceito ou um estudo. É importante que seja produzido um documento compartilhando informações relevantes como: detalhes sobre os testes feitos, evidências, os prós e contras, recomendações de qual ferramenta é melhor usar etc. Essas informações devem ser suficientes para a tomada de decisão sobre qual caminho seguir.

Mesmo que a solução ou a ferramenta não seja usada naquele momento — ou seja, você faz um experimento, mas os resultados não resolvem o seu problema — , o documento criado serve como histórico da decisão tomada e prevenção/defesa de discussões futuras. Ele responde perguntas como “Porque não usaram a ferramenta X?”, “Vocês já conhecem tal ferramenta?” ou “Porque vocês usam a solução A e não a B?”.

A cultura do Spike

Sempre que o time identificar uma oportunidade onde será mais útil fazer um Spike do que começar a desenvolver uma feature de imediato, deve pedir para priorizar um item de backlog focado no entendimento técnico daquela feature.

Por outro lado o Product Owner também deve reservar um tempo na sprint para o time adquirir conhecimento e dar recomendações para contribuir com stories que serão desenvolvidas na próxima sprint ou até mesmo em um futuro mais distante. O PO também pode se antecipar e sugerir que o time faça um Spike.

Ter uma prática de exploração registrada como atividade da sprint permite alinhar expectativas se uma tarefa está em pesquisa ou em desenvolvimento e ter um time mais capacitado para estimar as próximas stories. Isso dá previsibilidade de entrega da tarefa e do roadmap.

Ter um Spike ou não é uma decisão tomada pela equipe em conjunto e ela não pode atrapalhar os entregáveis da sprint, afinal você sempre deve ter um novo incremento no seu produto.

Estas são apenas algumas formas para manter o time em aprendizado e apto para tomar as melhores decisões sem prejudicar a sprint. Lembrando que cada time/empresa deve se adequar às suas necessidades.

Se você conhece outras opções compartilhe ou deixe nos comentários e auxilie a aprimorar as boas práticas em gestão ágil de produtos.