Engenheiros de dados em times ágeis
Times de dados (Data Science, ML, Analytics) enfrentam um desafio único: não sabem se o modelo vai funcionar antes de tentar. Como usar práticas ágeis nesse contexto?
O problema fundamental
“Construir uma API REST” → sabemos que é possível, o caminho é claro. “Treinar um modelo que detecte fraude” → não sabemos se é possível com os dados que temos.
Essa incerteza de viabilidade torna estimativas tradicionais problemáticas.
Adaptando estimativas
Use spikes para tudo
Em dados, quase tudo é um spike inicialmente:
| Sprint | Atividade | Estimativa |
|---|---|---|
| Sprint 1 | Explorar dados, feature engineering | 8 pontos (timeboxed) |
| Sprint 2 | Treinar modelos baseline | 8 pontos (timeboxed) |
| Sprint 3 | Se accuracy > 90%: productionize. Se não: pivot ou descarte | Decisão go/no-go |
Estimativa por esforço, não por resultado
“Vamos gastar 13 pontos explorando 3 abordagens. O resultado pode ser um modelo em produção, um relatório de viabilidade negativa, ou insights dos dados.”
O valor está no aprendizado, não apenas no modelo.
Métricas de sucesso diferentes
Para features: funciona ou não funciona. Para ML: qual é a métrica mínima aceitável?
Defina antes: “Se precision > 85% e recall > 70%, vamos para produção. Se não, investigamos o gap.”
Workflow adaptado
Kanban para data science
Sprint fixo funciona menos para data science que Kanban:
[Explorar dados] → [Feature engineering] → [Treinar] → [Avaliar] → [Deploy] → [Monitorar]
WIP limits: máximo 2 experimentos em paralelo por cientista.
Sprints mais longos
Se usar Scrum, considere sprints de 3 semanas:
- Semana 1: Exploração
- Semana 2: Desenvolvimento
- Semana 3: Avaliação e documentação
Estimativa de projetos de dados
| Tipo de tarefa | Estimativa | Observação |
|---|---|---|
| Limpeza de dados | 3-5 pontos | Sempre subestimado |
| Feature engineering | 5-8 pontos | Iterativo |
| Treinar modelo baseline | 3-5 pontos | Frameworks ajudam |
| Otimizar hiperparâmetros | 5-8 pontos | Timeboxed! |
| Deploy de modelo | 5-8 pontos | Dependência de MLOps |
| Análise exploratória | 3-5 pontos | Timeboxed |
Regra de ouro: timebox exploratória
“Se não achou insights em 5 pontos (≈3 dias), mude de abordagem ou aceite que os dados não respondem a essa pergunta.”
Conclusão
Times de dados precisam de mais flexibilidade nas estimativas e mais tolerância para experimentos “falhados”. O valor não está apenas no resultado, mas no aprendizado. Timebox exploratórias, defina critérios de sucesso e trate spikes como entregas legítimas.