Você já ouviu a frase “duas cabeças pensam melhor do que uma”? O Pair Programming é um método parecido com essa frase. Nesse texto, você vai aprender mais como a metodologia funciona e como aplicá-la no seu processo de desenvolvimento, além de algumas dicas essenciais para aplicar na hora da execução.

História

Contexto histórico é sempre importante para sabermos por que algumas decisões foram tomadas e por que coisas foram criadas, né? Com o Pair Programming não é muito diferente.

Primeiro é bom ressaltar que o Pair Programming vem lá do XP(eXtreme Programming) criado por Kent Beck e só esses dois temas já dão dois novos ótimos textos, hehe (vem aí).

Na década de 90, período que o XP foi concebido, várias outras metodologias ágeis foram criadas também, por exemplo, o Scrum. Todas essas metodologias tinham como objetivo uma produção de software menos “cascateira” e mais focada em pessoas e no real valor que o software poderia entregar para os seus usuários. Outra coisa muito importante, era a aversão à mudança do sistema Cascata onde o planejamento deveria ser seguido a risca e mudanças nunca eram bem-vindas. As metodologias ágeis apareceram para mostrar para o mundo que mudanças são sempre bem-vindas, que elas devem acontecer e que devemos aprender com elas para cada vez sermos melhores.

Depois do contexto histórico, vamos falar sobre o nosso querido Pair Programming.

O Pair Programming é contra intuitivo

Quando falamos “coloca duas pessoas para trabalharem juntas que elas vão entregar mais”, nós já pensamos “ué, como é possivel duas pessoas fazendo UM trabalho podem estar entregando mais???”. É ai que tá a pegadinha, e junto vem um ditado popular: “Duas cabeças pensam melhor que uma”. 

Vou trazer um exemplo prático aqui sobre como duas pessoas trabalhando separadas entregam mais: Imagina que uma pia está cheia de pratos e você chama um amigo seu para lavar esses pratos o mais rápido possível. Nesse caso, faz todo sentido porque você está fazendo o trabalho acabar na metade do tempo (ou pelo menos imagina que isso vai acontecer). Mas beleza, você e seu amigo terminaram o trabalho que demoraria uma hora em 30 minutos. Ótimo né? Sim, para um trabalho mecânico e braçal.

Quando estamos falando de software estamos falando sobre trabalho do conhecimento e sobre criatividade e, na maioria das vezes, na hora de criar algo você não tem a certeza do que precisa ser feito, do como fazer e (poucas vezes) o porquê precisa fazer algo.

Nesse pensamento, e em vários outros, que o modelo Cascata pecou. Nesse modelo, tudo sempre estaria muito bem definido e sempre tudo seria dentro do planejado.

No que diz respeito ao trabalho do conhecimento, quando você tem colaboração, a chance de você resolver os problemas da forma mais eficaz é maior, porque “Duas cabeças pensam melhor que uma”. Então, o Pair Programming veio para ajudar as pessoas a pensarem juntas e colaborarem mais para que os problemas, que com o tempo estão se tornando cada vez mais complexos, fiquem mais simples de serem resolvidos. 

O Pair Programming também garante que você esteja sempre trocando conhecimento com a outra pessoa, se não estiver tem algo errado. E segundo a Pirâmide de Aprendizagem de William Glasser, você vai estar em um dos níveis mais altos de aprendizado, que é no terceiro nível da pirâmide, porque com Pair Programming você sempre deve estar ou conversando e debatendo ou reproduzindo… Com isso, você potencializa o seu aprendizado e o do seu par.

Beleza, então se cada vez os problemas são mais complexos, se eu colocar mais pessoas mais fácil você resolve eles? É… Quase isso, cuidado para não virar bagunça também e no fim nada ser resolvido. Você pode ir além do Pair e ir para o Mob Programming… Mas isso é um post para o futuro. Vou deixar um talk aqui, onde um cara muito incrível explica o quanto o Mob Programming pode ser mais produtivo.

Mas como fazer um Pair Programming?

Bom, aqui vou explicar o que você precisa fazer em um Pair Programming com as pessoas que trabalham com você.

Duas pessoas, um computador (ou duas pessoas e dois computadores, pois pandemia)

Hoje em dia já existem algumas ferramentas que facilitam o Pair Programming remoto, como o Zoom e algumas extensões do Visual Studio Code.

Um piloto e um copiloto

Assim como nas corridas de rally, aqui você tem o Piloto (pessoa que apenas escreve o código), Copiloto (pessoa que fala o que precisa ser feito) e vocês vão precisa de um trabalho, bem definido, que precisa ser feito. Daí, vai ser uma História de Usuário que vocês vão desenvolver, um bug de produção que precisa ser corrigido, mas ele é muito complexo para uma cabeça só. A dica que eu dou aqui é que, antes de codar, tenham em mente qual o problema que vai ser resolvido para que vocês foquem 100% na criação da solução dele.

Dinâmica de revezamento

Para os iniciantes do Pair Programming é muito importante que exista um time box, onde cada um vai ser piloto e copiloto até vocês terem um certo ritmo e ir trocando conforme a música.

Recomendo começar usando a técnica Pomodoro, para cada pomodoro a cada 25 minutos o piloto e o copiloto trocam os papéis. Depois com a prática vocês podem ir aperfeiçoando e usando a forma que faz mais sentido para vocês.

É muito importante que exista essa troca de papéis para que a troca de conhecimento seja constante. Em duplas que alguém tem um perfil mais dominante, é importante que a dupla tenha apenas um copiloto.

Quem manda é o copiloto

Basicamente, o copiloto diz os passos a serem seguidos e o piloto executa… Isso é bem válido para o começo dos Pairs Programmings que vocês forem executar… Com o tempo, é ideal que existe uma troca de ideias entre o piloto e o copiloto porque o objetivo de tudo isso é a colaboração.

No começo vai ser difícil e vai parecer que vocês não estão andando ou só batendo cabeça, mas com a prática vem a perfeição e vocês vão ver que estão resolvendo cada vez mais e da melhor forma possível os problemas que vocês encontram.

Dicas

Agora que vocês vão botar a mão na massa e fazer Pair Programming, vou dar umas dicas para dar um boost na hora de executar ele:

• As pessoas menos experientes sempre começam como piloto;
• Sempre que tiver alguém aprendendo, faça o Pair Programming. Assim, facilita que a pessoa aprenda, que você confie nela dentro do time e que a pessoa confie no time e em você;
• Façam Coding DOJOs para praticar e para mostrar para o resto do time;
• Nos primeiros dias de Pair Programming usem pomodoro para criar ritmo e depois vão administrando conforme a necessidade;
• Nem tudo precisa ser feito em par. Vão ter problemas tão simples de serem resolvidos que não vai valer a penas fazer o par… Normalmente, isso vale para os problemas mais mecânicos, que você precisa pensar pouco ou quase nada para resolver;
• Usar TDD ajuda a guiar como o Pair Programming vai rodar e também a facilitar o entendimento do problema que precisa ser resolvido;
• Outra coisa, você não precisa só fazer o Pair Programming programando, você pode se juntar com outra pessoa, ou outras, para resolver os problemas. Pode confiar, na maioria das vezes a resolução do problema vai surgir de forma bem simples.
• E por último e não menos importante, vocês precisam se divertir. Diversão tem que fazer parte, vocês precisam curtir o que vão estar fazendo, tem que fazer piada e zoar o amiguinho, o momento precisar ser da hora.

E para finalizar, não podemos esquecer a clássica frase: “Duas cabeças pensam melhor que uma“. E se você quer aprender mais sobre desenvolvimento, não se esqueça de continuar olhando nosso blog.

Texto por Victor Costa.