Dicas sobre Pair Programming

O Patrick Kua publicou em seu blog algumas dicas interessantes que ele usa quando está trabalhando em pares. Traduzo aqui o texto para vocês.

Entender o estilo de trabalho de cada um

Gosto de entender como a pessoa com quem estou pareando gosta de trabalhar e eu gosto de explicar a maneira como prefiro trabalhar. Entender as preferências de cada um ajuda a não criar conflitos quando o par precisa fazer algo diferente, Alguns gostam de desenhar diagramas, outros gostam de analisar código, etc. Torne as coisas implícitas em explícitas.

Relaxe e conte até 3

Eu digito rápido mas reconheço que preciso ser paciente em relação a coisas como, erros de digitação ou sintaxe quando estou trabalhando com alguém que não digita tão rápido quanto eu. Nada diz mais “Não confio em você” do que ficar constantemente chamando atenção sobre essas coisas quando seu parceiro ainda está traduzindo o design em código. Eu confio no meu parceiro para perceber esses problemas e espero um longo intervalo antes de aponta-los. Quando tenho o impulso de interromper, paro e conto até 3 para dar um espaço ao par. Claro, erros de digitação são chatos, mas são corrigidos facilmente e não são o fim do mundo.

Troque de posições constantemente

Trocar posições frequentemente ajuda a criar um senso de posse coletiva do código, no entanto fazer isso de forma excessiva pode quebrar o fluxo de trabalho. Quando começo a trabalhar em pares tento organizar o tempo de teclado, sugerindo os momentos apropriados para a troca (fim de um teste, fim de uma funcionalidade).

Assegure-se que o par entenda por que está pareando

Pair Programming traz vários benefícios, mas, as vezes, pode ser difícil entender por que estamos trabalhando em pares. Veja se o trabalho em par está trazendo benefícios como, entendimento compartilhado, revisão de código contínua, opções de design, etc. Sem entender porque estamos pareando, muitas pessoas não conseguem atingir os resultados esperados.

Reconhecer que PP não é a solução para tudo

Me incomoda quando ouço, “Preciso de um par para resolver isso”, sem descobrir qual o problema de fato. As vezes problemas são melhor resolvidos pela equipe, ou padrões precisam ser acordados com a equipe, não com apenas um parceiro. Por outro lado, não acredito que todas as tarefas precisam de duas pessoas, coisas como ler uma documentação, ou pesquisar na web a solução de uma dívida. Pode ser difícil perceber quando e quando não trabalhar em pares. Entender o por que pode ajudar.

O navegador deve ver  além da tarefa atual

O valor do navegador é pensar além do que está sendo codificado, o que vem a seguir. Quando estou no papel do navegador penso nas consequências da tarefa atual nas outras partes do sistema, considerando tarefas que podemos ter nos esquecido ou pensando em diferentes cenários de teste que ainda são necessários criar. Também penso se a tarefa que estamos fazendo é realmente válida para o contexto do sistema, se isso nos leva mais próximo do nosso objetivo e se essa é a melhor forma de fazer.

O texto original pode ser lido aqui.

Publicidade