8 min leitura • Guide 815 of 877
Spikes de Descoberta Técnica
Spikes reduzem risco. O GitScrum ajuda equipes a planejar e rastrear spikes técnicas que respondem perguntas críticas antes de comprometer-se com implementação completa.
Entendendo Spikes
O Que São Spikes
DEFINIÇÃO DE SPIKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPIKE: │
│ ────── │
│ Investigação time-boxed para responder uma pergunta │
│ │
│ PROPÓSITO: │
│ ───────── │
│ • Reduzir incerteza técnica │
│ • Explorar tecnologia desconhecida │
│ • Avaliar viabilidade │
│ • Informar estimativas │
│ • Prototipar abordagens │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE vs STORY: │
│ │
│ STORY: │
│ "Implementar autenticação com OAuth" │
│ OUTPUT: Feature funcionando em produção │
│ │
│ SPIKE: │
│ "Investigar provedores OAuth para nossos requisitos" │
│ OUTPUT: Recomendação + abordagem + estimativa │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ QUANDO FAZER SPIKE: │
│ ────────────────── │
│ │
│ ✅ Use spike quando: │
│ • "Conseguimos fazer isso?" │
│ • "Qual abordagem é melhor?" │
│ • "Quanto tempo vai levar?" │
│ • "Quais são os riscos?" │
│ │
│ ❌ Não faça spike quando: │
│ • Resposta é pesquisável em 30 minutos │
│ • Você já sabe a abordagem │
│ • É só começar a construir │
│ │
│ REGRA: Spike quando incerteza está bloqueando progresso │
└─────────────────────────────────────────────────────────────┘
Tipos de Spikes
Categorias de Spike
TIPOS DE SPIKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPIKE DE VIABILIDADE: │
│ ───────────────────── │
│ "Conseguimos fazer isso?" │
│ │
│ EXEMPLO: │
│ "Podemos integrar com a API legada deles?" │
│ • Testar conectividade da API │
│ • Identificar limitações │
│ • Documentar bloqueios │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE DE ARQUITETURA: │
│ ───────────────────── │
│ "Como devemos estruturar isso?" │
│ │
│ EXEMPLO: │
│ "Desenhar a arquitetura de microserviços" │
│ • Fronteiras de serviços │
│ • Padrões de comunicação │
│ • Fluxo de dados │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE DE TECNOLOGIA: │
│ ────────────────────── │
│ "Qual tecnologia devemos usar?" │
│ │
│ EXEMPLO: │
│ "Avaliar GraphQL vs REST para nossa API mobile" │
│ • Comparar opções │
│ • Prototipar ambas │
│ • Recomendar com justificativa │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPIKE DE ESTIMATIVA: │
│ ──────────────────── │
│ "Quanto tempo isso vai levar?" │
│ │
│ EXEMPLO: │
│ "Estimar esforço para migração do sistema de pagamento" │
│ • Quebrar em componentes │
│ • Identificar incógnitas │
│ • Fornecer estimativa em range │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PROVA DE CONCEITO (POC): │
│ ──────────────────────── │
│ "Essa abordagem funciona?" │
│ │
│ EXEMPLO: │
│ "POC: Integração com serviço de pagamento" │
│ • Código funcionando (descartável) │
│ • Valida que abordagem é viável │
│ • Identifica armadilhas │
└─────────────────────────────────────────────────────────────┘
Executando Spikes
Time-boxing
TIME-BOX DE SPIKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DURAÇÕES TÍPICAS: │
│ ──────────────── │
│ │
│ Spike pequena: 0.5-1 dia │
│ • Perguntas focadas e específicas │
│ • "Qual biblioteca usar para X?" │
│ │
│ Spike média: 2-3 dias │
│ • Protótipo técnico │
│ • "Como a integração vai funcionar?" │
│ │
│ Spike grande: 3-5 dias │
│ • Avaliação de arquitetura │
│ • "Devemos usar microserviços?" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REGRAS DE TIME-BOX: │
│ ─────────────────── │
│ │
│ 1. Defina duração ANTES de começar │
│ 2. Quando tempo acabar, PARE │
│ 3. Tome decisão com informação disponível │
│ 4. "Não sei ainda" também é resposta válida │
│ 5. Nunca estenda sem justificativa clara │
│ │
│ POR QUÊ TIME-BOX: │
│ ───────────────── │
│ • Evita rabbit holes infinitos │
│ • Força decisões │
│ • Informação perfeita não existe │
│ • Feito é melhor que perfeito │
└─────────────────────────────────────────────────────────────┘
Output de Spike
ENTREGÁVEIS DA SPIKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DOCUMENTO DE SPIKE: │
│ │
│ # Spike: Avaliação de Provedores OAuth │
│ │
│ ## Pergunta │
│ Qual provedor OAuth devemos usar para autenticação? │
│ │
│ ## Contexto │
│ Precisamos de login social (Google, GitHub, Apple) │
│ Requisito de enterprise SSO no futuro │
│ Budget: até $500/mês para auth │
│ │
│ ## Opções Avaliadas │
│ │
│ | Opção | Prós | Contras | Custo | │
│ |-------|------|---------|-------| │
│ | Auth0 | Completo, fácil | Caro em escala | $$$ | │
│ | Clerk | Dev experience | Novo, menos maduro | $$ | │
│ | Custom| Controle total | Muito trabalho | Tempo | │
│ │
│ ## Recomendação │
│ Auth0 para lançamento, migrar para Clerk se custo subir │
│ │
│ ## Esforço Estimado │
│ 2-3 sprints para implementação completa │
│ │
│ ## Riscos Identificados │
│ • Lock-in do provedor │
│ • Custo em escala │
│ │
│ ## Próximos Passos │
│ • Criar stories para implementação │
│ • Solicitar trial enterprise do Auth0 │
└─────────────────────────────────────────────────────────────┘
Rastreando no GitScrum
Spike como Tarefa
SPIKE NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA DE SPIKE: │
│ │
│ Tipo: Spike │
│ Título: [SPIKE] Avaliar soluções de cache │
│ Time-box: 2 dias │
│ Assignee: Dev senior │
│ │
│ DESCRIÇÃO: │
│ ───────────── │
│ ## Pergunta │
│ Qual solução de cache devemos usar para API? │
│ │
│ ## Opções a Avaliar │
│ - Redis │
│ - Memcached │
│ - In-memory com Node │
│ │
│ ## Critérios │
│ - Performance │
│ - Complexidade operacional │
│ - Custo │
│ │
│ ## Entregável │
│ Documento de recomendação com justificativa │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CHECKLIST: │
│ ☐ Pesquisar opções │
│ ☐ Criar protótipo Redis │
│ ☐ Benchmark de performance │
│ ☐ Documentar trade-offs │
│ ☐ Recomendar solução │
│ ☐ Estimar esforço de implementação │
└─────────────────────────────────────────────────────────────┘
Métricas de Spike
| Métrica | O que Mede | Por Que Importa |
|---|---|---|
| % time-box respeitado | Disciplina | Evita scope creep |
| % spikes com decisão | Efetividade | Spikes devem resolver |
| Accuracy de estimativa | Qualidade | Spikes informam melhor |
| Re-spikes necessárias | Escopo ruim | Perguntas mal definidas |
Boas Práticas
O Que Fazer e Evitar
BOAS PRÁTICAS DE SPIKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✓ FAÇA: │
│ │
│ • Defina pergunta clara antes de começar │
│ • Time-box rigorosamente │
│ • Documente findings (mesmo negativos) │
│ • Inclua estimativa para trabalho real │
│ • Compartilhe conhecimento com equipe │
│ • Delete código de POC (é descartável) │
│ │
│ ✗ EVITE: │
│ │
│ • Spike sem pergunta clara │
│ • Estender indefinidamente │
│ • Transformar POC em produção │
│ • Não documentar resultado │
│ • Spike de coisas óbvias │
│ • Trabalhar sozinho sem compartilhar │
│ │
│ SINAIS DE SPIKE RUIM: │
│ ───────────────────── │
│ • "Ainda estou investigando..." (dia 5) │
│ • "Encontrei outras coisas interessantes..." │
│ • "Vou só implementar já que fiz o protótipo" │
│ • "Não consegui decidir" │
└─────────────────────────────────────────────────────────────┘