Questões frequentes sobre a programação em pares

A programação em pares é uma técnica de desenvolvimento ágil onde duas pessoas programadoras trabalham juntas no mesmo posto de trabalho, ou seja desenvolvendo o mesmo código.
Uma das pessoas a chamada de driver é a responsável por escrever o código e a outra pessoa a chamada de observadora ou navegadora revisa as linhas de código que vão sendo escritas. Fazendo um paralelo com os famosos Ralis onde uma pessoa é a motorista responsável por dirigir o carro, enquanto a outra pessoa fica como navegadora, responsável por olhar o mapa e definir a estratégia a ser tomada.

Mas para que colocar duas pessoas para escrever o mesmo código se eu posso ter elas trabalhando separadamente e gerando o dobro de código?

A programação em pares de geral aumenta a quantidade de horas requeridas para entregar um código quando comparamos duas pessoas desenvolvedoras trabalhando sozinhas em seus próprios postos de trabalhos. Alguns experimentos feitos dizem que esse aumento no tempo para entregar o código pode variar entre 15% e até 100%, todavia o código produzido contém cerca de 15% menos defeitos e muitas vezes o custo de se arrumar esses defeitos em produção é maior do que o custo de se ter duas pessoas programando em par.

Na minha experiência como consultor de desenvolvimento, os projetos eram entregues com um código mais manutenível e com mais qualidade se comparado aos outros anos em que trabalhei sozinho. Mais manutenível pois quando se somado as experiências de duas pessoas desenvolvedoras, e o olhar da pessoa que esta como navegadora foi possível fazer refactors mais constantes e ter um código mais limpo. Com mais qualidade, pois conseguíamos fazer a junção de outras técnicas como o ping-pong (descrito logo mais) junto com o desenvolvimento guiado por testes (mais conhecido como TDD).

Devo programar em par 100% do tempo ?

A resposta é: Depende.

Programar 100% do tempo vai depender muito do contexto do projeto e da tarefa a ser feita. Pois o processo de programação em pares muitas vezes se torna cansativo depois de algumas horas (aí que entram algumas técnicas descritas logo mais), e algumas tarefas mais simples e que a equipe já tenha o contexto talvez possam ser desenvolvidas sozinhas.

Com que frequência devo trocar o par em que trabalho dentro do meu time ?

A resposta novamente é: Depende.

Depende pois equipes distintas tem contextos distintos, em uma equipe em que trabalhei criávamos histórias pequenas e dividíamos algumas quando acreditávamos que estavam muito grandes, isso fazia com que tivéssemos trocas de pares após o termino de uma história. Em alguns momentos do projeto fazíamos rotações de pares com mais frequência (como a cada 3 dias) para ter um compartilhamento de contexto de negócio e do código entre o time.

Uma ferramenta que pode ser utilizada para manter o registro das rotações de pares é a matriz de pareamento, onde são anotados quem fez par com quem e quantas vezes essas pessoas já fizeram pares. Dessa forma diminuímos as preferências de pareamentos de pessoas dentro da equipe e conseguimos que todos façam pares com todos.

Que técnicas devo utilizar para a troca entre funções de driver e navegadora ?

A técnica de pomodoro consiste em definir um cronometro com um intervalo de tempo, por exemplo, se define 25 minutos onde uma pessoa trabalharia como driver e após esses 25 minutos se toma uma pausa de 5 minutos para descansar e quando retornarem a pessoa que antes era a driver passa a ser a navegadora e assim continuaria até 4 tempos de 25 minutos onde logo após se toma um intervalo maior de por exemplo 15 minutos.

Podemos utilizar o TDD junto com uma técnica chamada de ping-pong que consiste em uma pessoa começando como driver escrevendo um teste e fazendo ele falhar, logo após a pessoa que estava como navegadora se torna a driver e faz o teste passar e escreve outro teste que falhe invertendo novamente o par, e assim por diante.

Minha visão sobre a programação em pares

No meu ponto de vista, a programação em pares traz muito mais benefícios do que malefícios, como a troca de contexto entre o time, a troca de experiência entre pessoas desenvolvedoras com mais experiências com as com menos experiência, além de que se uma pessoa desenvolvedora fica doente, sai do projeto, ou até mesmo decide sair da empresa, algumas pessoas vão ter contexto do que estava sendo desenvolvido. É importante porém utilizar algumas técnicas mencionadas acima para que a programação em pares não se torne uma tarefa cansativa.

E você, utiliza a programação em pares em sua equipe ? Tem um ponto de vista diferente ? Comente logo abaixo :)