Critérios do Pair Programming - Metodologia XP (eXtreme Programming)

Olá, leitores!

Quem acompanha meus artigos, já sabe que sou um grande entusiasta em metodologias ágeis, entre elas, o XP (eXtreme Programming). Uma das práticas mais conhecidas dessa metodologia é o Pair Programming, ou Programação em Par, que consiste na alocação de duplas nas atividades de codificação. Porém, assim como as outras práticas ágeis, o Pair Programming não é uma bala de prata. Este artigo apresenta alguns critérios que devem ser levados em consideração ao empregar essa prática de forma apropriada.

Imagem via Shutterstock

Os critérios abaixo foram elaborados a partir da minha própria experiência com a metodologia, portanto, talvez eles não sejam aplicáveis à realidade de todas as empresas de desenvolvimento. Além disso, leitor, é possível que você não concorde com todos os pontos citados. Neste caso, sinta-se à vontade para deixar um comentário e declarar a sua opinião! Pontos de vista distintos nos fazem adquirir um maior conhecimento sobre estes conceitos.

Pois bem, Pair Programming, em geral, já me ajudou bastante. Eu citei essa prática no artigo sobre a Zona de Fluxo do programador como uma das formas de evitar a concentração demasiada em um determinado código. No entanto, da mesma forma que tive boas experiências com o Pair Programming, também identifiquei alguns pontos negativos, nos quais detalho os parâmetros abaixo.

1) Conversa paralela
Esse critério é óbvio. Muitas vezes, ao invés de devidamente trabalhar na codificação, os desenvolvedores se distraem e iniciam conversas paralelas, fora do contexto da atividade. Não digo que um momento de distração não deve existir (lembre-se da Zona de Fluxo!), mas há uma possibilidade do assunto se estender por vários minutos ou horas, principalmente se for de interesse mútuo. Ademais, quando isso ocorre, torna-se difícil de retomar a concentração no código, já que a mente se afasta do problema. A minha sugestão é deixar esse tipo de assunto para momentos mais convenientes, como, por exemplo, durante a compilação do sistema ou no intervalo para o café.

2) Nivelamento entre a dupla
Eu considero o Pair Programming como um mero análogo ao Buddy System – um procedimento no qual duas pessoas trabalham juntas e, geralmente, uma delas tem mais experiência e ensina o outro par, de forma que ele aprenda mais rápido. O objetivo do Pair Programming pode ser encaixado nesse método de repassar as regras de negócio para um colaborador novato, porém, se o objetivo for aumentar a produtividade e/ou evitar erros na implementação, alocar desenvolvedores com nivelamento técnico (ou de negócios) bastante diferente pode não ser uma boa ideia. Ao invés de se ajudarem, o par com menos experiência ficará desorientado, sentindo, talvez, um pouco de tédio. Em certas ocasiões, é possível que este par também interrompa o companheiro várias vezes para direcionar perguntas. Mais uma vez: não há nada de errado em esclarecer dúvidas no Pair Programming, desde que a finalidade seja nivelar o conhecimento, e não elevar explicitamente o rendimento da codificação.

3) Estrutura
Para que a ideia do Pair Programming seja eficiente, é necessário que haja estrutura para isso, em especial o local físico. Recomenda-se que a estação de trabalho forneça espaço para duas cadeiras sem estorvar outros desenvolvedores ou atrapalhar o trânsito de pessoas. Além disso, claro, os dois desenvolvedores devem ter plena visualização do monitor para acompanhar a codificação. Lembre-se de que o incômodo impede o raciocínio íntegro.

4) Conflitos de personalidade
Personality clashes, como são conhecidos em inglês, representam as caraterísticas pessoais que podem gerar conflitos no ambiente de trabalho. Dito isso, nem sempre um dos pares se sentirá “confortável” ao trabalhar com o outro. Cada um tem o seu método de analisar problemas e discutir soluções que, algumas vezes, não agrada outras pessoas. Embora seja natural, o ideal é evitar a formação de duplas que não se identificam, ou que já trazem algum histórico de conflito pessoal ou profissional. Por outro lado, um pequeno desalinhamento pode até ser benéfico, visto que ajuda um dos pares a ter uma postura diferente, caso ele tenha uma mentalidade receptiva.

Bom, pessoal, são recomendações básicas, mas essenciais para a prática do Pair Programming. Quanto às vantagens, são inúmeras. Entre as mais marcantes, evita equívocos de codificação (tanto de sintaxe quanto de convenções), amplia a capacidade semântica, impede impactos colaterais no software e ajuda a manter o foco amplo na regra de negócio. Dá-lhe Pair Programming!

Para fechar o artigo, deixo uma mensagem para bons entendedores: