Estimativa & Risco
A estimativa dá expectativas realistas ao planejamento de produto. O trabalho em Rust esconde riscos em migrações, refatorações assíncronas, limites de FFI e CI em tempo de compilação - intervalos honestos, desconhecidos explícitos e orçamentos de spike superam promessas de ponto único.
Receita
Cartão de receita de referência rápida - pronto para copiar e colar.
## Cartão de Estimativa
**Tipo de trabalho:** feature | platform | migration
**T-shirt:** P / M / G / GG
**Intervalo (dias-dev):** 3-5 (50% de confiança) / 8 (90% se o spike falhar)
**Desconhecidos:** fase de migração sqlx, cobertura de teste do crate legado
**Spike:** 2 dias no máximo antes do compromisso da sprint
**Dependências:** revisão de segurança, janela do DBAQuando usar isso:
- Planejamento de sprint e datas de roadmap
- Solicitações de compromisso com o cliente
- Dependências entre equipes
- Migrações de Rust de alto risco
Exemplo de Trabalho
## Estimativa: Worker de exportação assíncrona (M)
**Conhecido:** Endpoint Axum + tipos serde (2d), helper de upload S3 existe (0.5d)
**Desconhecido:** Memória da biblioteca PDF com 500 documentos (spike 1d)
**Intervalo:** 5-8 dias-dev (50-90%)
**Riscos:**
- R1: OOM em lote grande → mitigação: stream + limite na especificação
- R2: Janela de migração do DBA escorrega → mitigação: fase 1 apenas de expansão
**Compromisso:** Sprint após o spike; não antes.// Exemplo de resultado de spike documentado no ticket
#[test]
fn spike_pdf_batch_memory_bounded() {
// protótipo: 500 PDFs pequenos ficam abaixo de 512MB no harness de teste
assert!(true);
}Mergulho Profundo
Calibração de T-Shirt (squad Rust)
| Tamanho | Escopo Típico |
|---|---|
| P | Rota Axum única, testes, sem migração |
| M | Feature + worker + observabilidade |
| G | Refatoração entre crates ou fase de expansão de migração |
| GG | Bump de edição, reescrita de FFI - dividir em programa |
Buffers
- Adicione 20-30% para rotatividade de revisão e flakes de CI em L+.
- Trabalho de migração: adicione dias explícitos de DBA e ensaio de rollback.
- Avaliação de novo crate: spike antes de incluir no compromisso da sprint.
Comunicação
Apresente intervalos ao PM: "5-8 dias, 50% de confiança; 12 se o spike mostrar problema de OOM." Atualize quando o aprendizado mudar - cedo, não na demonstração.
Armadilhas
- Número único para o slide do PM - Falsa precisão. Correção: Intervalo + confiança + lista de suposições.
- Estimar sem especificação - Erro de ordem de magnitude. Correção: Especificação ou spike primeiro para M+.
- Ignorar teste/rollout - "Concluído" na mesclagem. Correção: Inclua staging, flag, docs na estimativa.
- Sem reestimativa em creep de escopo - Correção: Solicitação de alteração aciona novo card.
- Otimismo em
unsafeFFI - Correção: Item de linha de revisão de segurança obrigatório.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Sem estimativas, métricas de fluxo | Equipe madura Kanban | Lançamento contratual com data fixa |
| Previsão de Monte Carlo | Muitas histórias semelhantes | Equipe pequena, poucos pontos de dados |
| Previsão de classe de referência | Tipo de migração repetida | Greenfield novo |
| #NoEstimates + SLO | Confiança forte | Pressão de prazo externo |
FAQs
Pontos de história vs dias?
Qualquer um funciona; equipes Rust frequentemente preferem dias-dev para clareza do PM em migrações.
Quem é o dono do registro de riscos?
O tech lead mantém; o PM revisa no planejamento.
Tempo limite do spike?
1-3 dias; critérios de saída binários no ticket.
Estimar CLI + API juntos?
Cards separados, a menos que um crate compartilhado domine o esforço.
Estimativas de ETL Polars?
Inclua sonda de volume de dados e spike de memória; frequentemente subestimado.
Buffer para CI de compilação?
Sim em mudanças de workspace L+; cite dados recentes de lead time.
Data fixa do cliente?
Reduza o escopo ou adicione pessoal; não comprima as fases de teste/migração silenciosamente.
Velocidade para nova equipe Rust?
Velocidade inicial menor por 2-3 sprints; calibre com dados de retro.
Documentar suposições de estimativa?
No comentário do ticket; link para spec e PRs de spike.
Retro de estimativa perdida?
Sem culpa: desconhecido errado, mudança de escopo ou carga de interrupção - ajuste o processo.
Relacionado
- Requisitos para Especificações Técnicas - entrada de escopo
- Comunicação com Stakeholders - más notícias cedo
- Spikes, PoCs & Adoção de Novos Crates - reduzir risco
- Fazendo o Processo Funcionar - normas de sprint
- Melhores Práticas de Colaboração de Produto - resumo
Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.