Arquitetura evolutiva em times ágeis

A pergunta mais comum em times ágeis: “devemos planejar a arquitetura antes de começar a codificar?” A resposta: sim, mas não como você pensa.

O problema do “Big Design Upfront”

Semanas de arquitetura antes do primeiro sprint resulta em:

Design para problemas que não existem
Complexidade desnecessária
Tempo desperdiçado quando requisitos mudam
Frustração do time que quer entregar valor

O problema do “Sem Design”

No outro extremo, times que codificam sem pensar em arquitetura resultam em:

Spaghetti code
Impossibilidade de escalar
Refatoração constante
Dívida técnica impagável

O meio-termo: Arquitetura Evolutiva

Sprint 0: Foundation leve

1-2 dias para definir:

Stack tecnológico — linguagem, framework, banco de dados
Estrutura de repositórios — monolith ou microserviços?
Convenções — padrão de código, branching, deploy
Arquitetura de alto nível — diagrama de 1 página

Não faça: Design detalhado de APIs, modelagem completa de banco, definição de todos os padrões.

Evolua com o produto

Sprint 1-3: Monolito simples
Sprint 4-8: Separação de módulos
Sprint 9+: Microserviços se necessário

Cada decisão de arquitetura é tomada quando há problema real, não antecipado.

Decisões de arquitetura no Planning

Quando estimar uma tarefa que envolve decisão técnica:

Discuta as opções — “Podemos fazer com Redis ou com cache em memória”
Vote na abordagem — o time decide, não só o tech lead
Estime a escolha — “Redis: 8 pontos. Cache local: 3 pontos.”
Documente a decisão — ADR (Architecture Decision Record) de 5 linhas

Architectural Decision Records (ADRs)

Formato simples:

Título: Usar Redis para cache de sessão
Status: Aceito
Contexto: Precisamos de cache compartilhado entre 3 servidores
Decisão: Redis em vez de cache em memória
Consequências: Infra adicional necessária, mas cache consistente

Mantenha ADRs no repositório, em /docs/decisions/.

Impacto nas estimativas

Decisões de arquitetura mudam estimativas:

“Migração de MySQL para PostgreSQL: 13 pontos. Mas nos dá full-text search nativo que economiza ~20 pontos no futuro.”

Compare custo agora vs. custo futuro.

Sinais de que a arquitetura precisa evoluir

Build demorando mais de 15 min
Feature nova demora 2× mais que antiga similar
Deploy de um módulo exige redeploy de tudo
Bug em módulo A quebra módulo B inesperadamente
Novos membros levam 4+ semanas para fazer primeiro deploy

Conclusão

Arquitetura ágil não é “sem arquitetura” — é “arquitetura quando necessário.” Comece simples, evolua quando doer, documente decisões. Over-engineering é tão ruim quanto arquitetura inexistente.