Busque em todas as páginas da documentação
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.
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:
## 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);
}| 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 |
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.
unsafe FFI - Correção: Item de linha de revisão de segurança obrigatório.| 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 |
Qualquer um funciona; equipes Rust frequentemente preferem dias-dev para clareza do PM em migrações.
O tech lead mantém; o PM revisa no planejamento.
1-3 dias; critérios de saída binários no ticket.
Cards separados, a menos que um crate compartilhado domine o esforço.
Inclua sonda de volume de dados e spike de memória; frequentemente subestimado.
Sim em mudanças de workspace L+; cite dados recentes de lead time.
Reduza o escopo ou adicione pessoal; não comprima as fases de teste/migração silenciosamente.
Velocidade inicial menor por 2-3 sprints; calibre com dados de retro.
No comentário do ticket; link para spec e PRs de spike.
Sem culpa: desconhecido errado, mudança de escopo ou carga de interrupção - ajuste o processo.
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+.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026