← Voltar ao blog

Engenheiros de dados em times ágeis

data-science estimativas agile

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:

SprintAtividadeEstimativa
Sprint 1Explorar dados, feature engineering8 pontos (timeboxed)
Sprint 2Treinar modelos baseline8 pontos (timeboxed)
Sprint 3Se accuracy > 90%: productionize. Se não: pivot ou descarteDecisã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 tarefaEstimativaObservação
Limpeza de dados3-5 pontosSempre subestimado
Feature engineering5-8 pontosIterativo
Treinar modelo baseline3-5 pontosFrameworks ajudam
Otimizar hiperparâmetros5-8 pontosTimeboxed!
Deploy de modelo5-8 pontosDependência de MLOps
Análise exploratória3-5 pontosTimeboxed

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.