Parear ou não Parear? Eis a questão — Parte I
Introdução
Comemoro um ano de Creditas escrevendo este post que é na verdade uma reflexão sobre o Pair Programming. Desde quando iniciei o processo para entrar para o time da Creditas sabia que o Pair Programming era uma técnica muito utilizada na empresa. Na teoria, os benefícios da prática estavam claros:
- Evita silos de conhecimento dentro da equipe
- Salto de qualidade no código
- Código mais revisado e melhor estruturado
Na prática, depois de algum tempo trabalhando com Pair Programming, notei que para mim, pessoalmente, os benefícios alcançados não justificavam o esgotamento físico e mental de estar todo o dia pareando com alguém. Notava que eu aprendia muito mais quando estava sozinha, no meu ritmo, analisando o código, pedindo ajudas pontuais para outras pessoas. Depois de algumas sessões de pair sentia que seguia no mesmo nível de desconhecimentos que tinha antes de começar a tarefa. Definitivamente, isso não era sustentável.
Então cheguei a duas hipóteses: ou estavam mentindo para mim sobre todos esses benefícios maravilhosos do Pair Programming, ou eu estava fazendo tudo errado. Comecei a investigar a hipótese mais provável: que eu não sabia muito bem como fazer Pair Programming.
Comecei pelo texto de Birgitta BöckelerNina Siessegger “On Pair Programming” (disponível em www.martinfowler.com) e o que segue aqui é uma série de conceitos e mindset necessários para que se tire proveito do Pair Programming.
De modo geral, como usar a técnica
A primeira coisa importante é que existem dois papéis envolvidos nas sessões de Pair Programming: o condutor e o navegador. Esse já era um ponto que não era seguido de acordo. Claro, seguindo ou não uma técnica específica, é natural que uma pessoa digite o código, enquanto a outra está acompanhando. Mas só isso não é suficiente. A definição de papéis tal qual existem tem um propósito claro e existem responsabilidades distintas para cada papel.
O condutor
O condutor é a pessoa que está escrevendo o código e deve estar preocupada em resolver um problema muito pontual. Ele está focado na construção do código e resolução da lógica envolvida naquele pequeno pedaço de código.
O navegador
Já o navegador, tem uma visão mais ampla do código. Ele deve estar atento aos efeitos que o código que está sendo escrito pode ter em outras partes do programa, possíveis melhorias etc.
Quem é quem
As duas pessoas da dupla têm que assumir os dois papéis durante uma sessão de Pairing. Isso parece ser uma peça chave para que a atividade produza os benefícios esperados. Então, os papéis têm que ser constantemente trocados durante o Pair Programming.
Algumas técnicas de Pairing
Mais do que uma metodologia, o Pair Programming me parece ser um conjunto de boas práticas que permite que duas pessoas executando uma atividade que envolve a programação gere mais benefícios do que uma só pessoa fazendo. Se tivermos bem claro o mindset e como alcançar os benefícios que isso pode nos proporcionar, é bem viável que cada equipe acabe adaptando a técnica de maneira que traga mais benefícios. Ou seja, existem algumas técnicas já definidas, mas nada impede que uma equipe defina sua própria.
A seguir, descrevo algumas técnicas existentes:
Ping pong
A primeira técnica é chamada Ping Pong. Ela é utilizada junto com Test Driven Development (TDD) e é recomendada quando está claro o trabalho que deve ser executado de maneira test-driven. O Ping é o desenvolvedor que vai escrever o teste que falha. No Pong o outro desenvolvedor tem que escrever o código para que o teste passe. E na sequência escrever o próximo teste que vai falhar. Nessa técnica também é possível fazer algum tipo de melhoria de código no Pong.
Strong-style Pairing
Outra técnica que pode ser utilizada é a Strong-style Pairing e ela é particularmente eficaz para transferências de conhecimento. Explicando brevemente, a regra para esta técnica é que se um conhecimento vai sair da cabeça de um desenvolvedor para um programa, isso deve ser feito através de mão de outro programador. Neste caso, o programador que detém mais conhecimento (técnico, de estrutura do projeto, de regras de negócio) é o navegador, enquanto o desenvolvedor menos experiente, deve ser o condutor.
O importante desta técnica é que o condutor confia plenamente no navegador e ele deve estar confortável com entendimento incompleto. Perguntas e desafios para a solução devem ser discutidas depois da sessão. Considerando que uma das pessoas é novata, isso pode fazer a atividade de parear muito mais eficaz.
Por outro lado, a técnica envolve micro gerenciamento e é muito útil como uma ferramenta de onboarding que permite aprender fazendo no lugar de aprender vendo. Ela é ótima para uma transferência inicial de conhecimento, mas não se deve usar sempre. O ideal é que seja possível trocar de funções em um curto período de tempo. O que também vai indicar que a técnica foi efetiva.
Em nosso contexto
No contexto da nossa equipe, por exemplo, penso que essa técnica poderia nos ajudar a passar os conhecimentos adquiridos durante os discoveries que fazemos. Como é sempre uma pessoa que fica responsável pelo trabalho inicial, é recorrente que essa mesma pessoa acabe fazendo a implementação e é comum um cenário em que o resto da equipe fica sem o contexto. Neste caso, poderíamos usar o Strong-style Pairing para fazer atividades geradas a partir de um discovery.
Na segunda parte deste artigo, vamos explorar o mindset do Pair Programming e conhecer o que devemos ter em mente para que a técnica dê resultados positivos.
Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa Tripulação! Você pode conferir nossas vagas aqui.
