O que é Pair Programming?

A programação em par se tornou uma prática conhecida de Extreme Programming, associada ao trabalho de Kent Beck e outros participantes do movimento. Martin Fowler descreve a colaboração de duas pessoas no mesmo código e ressalta que o trabalho principal é compreender e decidir, não apenas digitar. Há formatos diferentes de pareamento; driver e navigator são papéis úteis, mas não uma regra imutável para toda sessão.

Pair Programming, ou programação em par, reúne duas pessoas para trabalhar no mesmo problema de programação em tempo real. Ambas participam das decisões, embora normalmente uma opere o teclado e a outra observe, questione, pesquise e pense nos próximos passos. A colaboração pode ocorrer na mesma estação ou por compartilhamento remoto. O objetivo não é duplicar digitação: programação envolve compreender o sistema, escolher uma abordagem, testar e revisar consequências.

Driver e navigator. O driver conduz a implementação imediata. O navigator mantém atenção ao problema maior, procura inconsistências e sugere caminhos. Esses nomes descrevem papéis momentâneos, não hierarquia. Se uma pessoa dita cada linha e a outra apenas obedece, o par perde a capacidade de pensar junto. Troque papéis e ajuste o modo de colaboração à experiência e à tarefa. Às vezes quem navega pesquisa documentação ou ajuda a formular um teste antes de escrever código.

Preparação. Comece com uma meta pequena e compartilhada: corrigir um defeito, acrescentar um teste ou compreender um módulo. Acorde o resultado esperado, critérios de qualidade, tempo disponível e quando parar para reavaliar. Um item vago faz o par discutir escopo enquanto deveria aprender sobre a solução. Ter ferramentas, acesso e ambiente funcionando evita transformar a sessão em espera passiva.

Ritmo. Trabalhe em passos curtos. Uma pessoa propõe uma mudança; ambas verificam o que o código e os testes mostram. Discussões difíceis podem pedir pausa para desenhar alternativas. Revisão contínua não significa interromper a cada caractere. O navigator pode deixar a ideia ganhar forma e então perguntar sobre um caso de borda. A troca de papéis deve manter atenção e transferência de entendimento, sem impor um cronômetro rígido a todo par.

Qualidade e feedback. O par pode notar um equívoco enquanto a decisão ainda é barata de mudar. TDD pode dar uma sequência de testes e implementação, mas não é requisito para parear. Integração frequente e código compartilhado permitem que outras pessoas aprendam depois. Pair Programming também não elimina necessidade de testes automatizados, revisão de segurança ou validação com usuários. Duas pessoas podem concordar com a mesma suposição errada.

Aprendizado. Um par com experiências diferentes pode espalhar conhecimento de domínio, arquitetura e ferramentas. A pessoa mais experiente precisa explicar raciocínio, não apenas assumir o teclado. A menos experiente precisa ter espaço para propor alternativas e experimentar. Parear durante onboarding pode reduzir dependência de um único especialista. Rotacionar parceiros ao longo do tempo ajuda a distribuir conhecimento, respeitando continuidade e confiança.

Trabalho remoto. Áudio claro, compartilhamento de tela, editor colaborativo e capacidade de controlar o ambiente diminuem fricção. Uma pessoa olhando uma transmissão sem conseguir participar não equivale a um par ativo. Combine pausas, turnos de fala e como pedir mudança de direção. Fadiga de tela e diferenças de conexão pedem sessões mais curtas ou adaptação. O resultado deve ser avaliado pela colaboração e pelo código, não pela presença simultânea em chamada.

Quando usar. Tarefas incertas, sensíveis, de aprendizado ou que atravessam partes pouco conhecidas do sistema podem se beneficiar de duas perspectivas. Uma investigação curta em par pode economizar retrabalho posterior. Trabalho repetitivo de baixo risco pode render melhor de outra forma, desde que o time mantenha qualidade e compartilhamento de conhecimento. A escolha é contextual, não uma prova de maturidade. Faça experimentos com tipos de tarefa e observe custo total, defeitos e compreensão compartilhada.

Conflitos produtivos. Discordar de uma solução é esperado. Explique critério, hipótese e risco em vez de defender preferência pessoal. Se a discussão se prolonga, execute um experimento reversível ou peça uma terceira opinião. Segurança psicológica importa: a pessoa deve poder dizer “não entendi” ou “acho que há um erro” sem punição. Uma sessão em que uma voz domina gera silêncio, mesmo quando duas pessoas estão presentes.

Custos e limites. A disponibilidade simultânea de duas pessoas custa capacidade aparente. Compare esse custo com retrabalho, filas de revisão, defeitos e tempo de aprendizagem; contar apenas linhas por pessoa é insuficiente. Pair Programming pode ser cansativo e nem todo dia pede pareamento contínuo. Use pausas e momentos individuais para pesquisa e reflexão. Cuidado para não exigir exposição constante de alguém que precisa de acomodação ou privacidade em uma tarefa.

Depois da sessão. Verifique testes, legibilidade e o que ficou pendente. Registre decisões de arquitetura ou dúvidas que o restante do time precisa conhecer. Se a sessão não avançou, investigue se faltava contexto, havia escopo grande ou a combinação de pessoas precisava de apoio. Uma retrospectiva curta transforma dificuldade de parear em melhoria de processo, em vez de concluir que a prática inteira falhou.

Exemplo hipotético: uma equipe mantém um serviço de cobrança com um defeito intermitente. Uma pessoa conhece as regras de cobrança e outra domina a observabilidade do sistema. Trabalhando separadas, cada uma consegue investigar apenas uma parte. Em par, reproduzem o problema, criam um teste para o caso e identificam uma condição de concorrência. O driver escreve o teste; o navigator verifica a regra e questiona como o serviço reage a nova tentativa. Depois trocam os papéis para implementar e revisar a correção.

Antes, a equipe estimava seis horas de investigação individual, mais uma fila de revisão de um dia. Nesta situação hipotética, duas pessoas trabalham juntas por três horas, concluem teste e correção e pedem uma revisão adicional por ser uma área crítica. São seis horas de esforço combinado, não três, e o resultado não prova que parear sempre economiza tempo. A diferença é que o conhecimento e as decisões surgem compartilhados e uma possível falha de regra foi detectada antes da publicação.

Após a entrega, a equipe observa por duas semanas se o erro reaparece e registra os cenários testados. Se a correção falhar, ambas conseguem retomar a investigação. O exemplo mostra por que comparar apenas tempo de teclado oculta espera, transferência de contexto e risco; não oferece um percentual universal de produtividade.

Curso K21 recomendado