Pair Programming: guia prático para times ágeis
Pair Programming (PP) é duas pessoas programando juntas em uma máquina. Parece desperdício de recursos — até você ver os resultados.
Os números do pair programming
Pesquisas mostram que PP:
- Aumenta 15-20% o tempo por tarefa (2 pessoas, 1 código)
- Reduz bugs em 15-50% em comparação com programação solo
- Acelera onboarding em semanas
- Melhora moral do time
O ROI é positivo quando o custo de bugs é alto.
Estilos de pair programming
Driver-Navigator (clássico)
- Driver: Digita o código
- Navigator: Pensa estrategicamente, revisa cada linha
- Troque papéis a cada 25-30 minutos
Ping-pong (TDD)
- Pessoa A escreve o teste
- Pessoa B faz o teste passar
- Pessoa A refatora
- Troquem
Strong-style
“A ideia entra pelo teclado de quem está digitando.” Ou seja: quem tem a ideia explica, mas o outro digita para garantir que entendeu.
Quando usar pair programming
Momentos ideais
- Código complexo — lógica de negócio complicada
- Onboarding — novo membro + veterano
- Debugging difícil — duas cabeças pensam melhor
- Design de API — decisões que afetam outros times
- Refatoração arriscada — módulo crítico
Quando NÃO precisa
- Tarefas simples — CRUD básico, correções de texto
- Trabalho exploratório — spike técnico solo é mais eficiente
- Sessão de estudo — aprendizado individual
- Quando o par está cansado — PP exige energia
Estimativa com Pair Programming
Dois desenvolvedores = um “par”
Um par produz aproximadamente 1.5x um desenvolvedor solo, não 2x.
“Essa tarefa leva 8 pontos para 1 dev. Com pair, o esforço é 8 pontos, mas 2 devs completam em ~5pts de tempo-cada.”
Quando estimar para pair
No Planning Poker, se o time decide que uma tarefa será feita em par:
- A estimativa de pontos não muda (complexidade é a mesma)
- Os devs alocados mudam (2 pessoas × menos tempo total)
- O capacity planning ajusta (2 devs usam 2 slots de capacidade)
Organização prática
Sessões
- Máximo 2 horas por sessão contínua
- Intervalos a cada 25-30 minutos (Pomodoro)
- Troca de pares — não PP sempre com a mesma pessoa
Ambiente
- Uma tela compartilhada — ou VS Code Live Share para remoto
- Teclado compartilhado — no presencial, 1 teclado + 1 mouse
- Ambiente configurado — ambos conseguem rodar e testar
Rotatividade
Um bom modelo: cada pessoa faz PP com cada colega pelo menos 1 vez por sprint.
Sinais de PP eficaz
- Ambos contribuem com ideias e código
- O driver não fica passivo
- O navigator não fica no celular
- Troca de papéis é natural e frequente
- Ambos saem sabendo mais do que entraram
Sinais de PP ineficaz
- Uma pessoa domina completamente
- Silêncio prolongado (ninguém está engajado)
- Sessão dura mais de 2 horas
- Um dos pares está visivelmente cansado ou desinteressado
- O código resultante é pior do que seria individualmente
Conclusão
Pair Programming não é desperdício de recursos — é investimento em qualidade e conhecimento compartilhado. Use estrategicamente em código complexo, onboarding e debugging. Estime a complexidade normalmente, mas ajuste a alocação de capacidade.