Parte da metodologia do Extreme Programming, a programação em par é uma forma inovadora de trabalho. Conheça os prós e os contras de quem já experimentou

Por Aline Brandão

Você já ouviu falar em Programação em Par? Esta prática, parte da metodologia Extreme Programming, consiste em ter dois desenvolvedores trabalhando ao mesmo tempo num mesmo código e numa mesma estação de trabalho. Os dois se revezam no teclado: enquanto um (chamado de condutor) digita o código e usa o mouse, o outro (o navegador) acompanha o que está sendo produzido, conferindo erros, discutindo dúvidas e sugerindo soluções.

A idéia, a princípio, parece perda de tempo e dinheiro: qual a vantagem em ocupar dois profissionais num trabalho só? “A primeira impressão que se tem é que esse método gasta muito dinheiro; o que não deixa de ser verdade, porque você está pagando dois funcionários. Mas em alguns casos esse gasto inicial é compensado pela economia em custos indiretos – argumenta o Diretor de Desenvolvimento da ABC71, Júlio Bertolini.

Os defensores da programação em par costumam fazer uma analogia desta prática com a pilotagem. Hoje, com o nível de automação dos equipamentos de vôo, é perfeitamente possível que um piloto experiente consiga controlar sozinho um avião. No entanto, como seres humanos são passíveis de erro e os riscos envolvidos são muito altos, as companhias aéreas exigem a presença do co-piloto – um profissional igualmente experiente, que pode dividir a responsabilidade de observar os indicadores de vôo e assumir a pilotagem em caso de necessidade.

Erra-se menos

Um dos pontos principais da programação em par (pair programming, em inglês) é a diminuição da incidência de erros. No ano 2000, o Chaos Report do Standish Group concluiu que 72% dos projetos de desenvolvimento falham. O erro é uma tendência natural neste tipo de trabalho: depois de um tempo, o profissional simplesmente não enxerga mais o código problemático porque a vista já está “viciada”. Na programação em par, quem assume o papel de navegador não está concentrado numa determinada linha de código, mas no todo; logo, tem mais facilidade de encontrar aquela vírgula faltando.

“Nesse caso, a programação em par funciona como se fosse uma revisão simultânea, um double-check – diz o Gerente de Desenvolvimento da 3Elos Segurança de Informação, Luiz Marques.

A 3Elos não adota formalmente o XP (Extreme Programming), mas já utilizou a programação em par em casos de codificação mais complexa. Para Marques, além da menor incidência de erros, essa técnica também permite criar códigos mais bem pensados e designs mais cuidadosos. Entra em cena o famoso ditado: “duas cabeças pensam melhor do que uma”.

“Vejo com bons olhos principalmente a troca de experiências: quando um dos membros da dupla é mais experiente, o outro vai ter a oportunidade de aprender muito mais de uma forma prática – afirma.

A questão do perfil dos programadores gera algumas controvérsias. Júlio Bertolini discorda de Marques: para ele, a diferença de níveis é prejudicial. “O melhor é que o nível de experiência seja igual, para não correr o risco de um profissional levar o trabalho todo sozinho e o outro ficar apenas assistindo. Normalmente são profissionais mais experientes, que têm poder de absorção e análise maior – explica.

Para alguns autores, uma dupla formada por novatos não teria grande objetivo e seria até arriscada, pois sempre existe a possibilidade de induzir o outro ao erro em vez de corrigi-lo. Por outro lado, dois profissionais inexperientes têm em conjunto um conhecimento maior do que isolados e podem construir um aprendizado juntos. Além disso, a probabilidade de que os dois tenham conhecimentos diferentes é maior, o que estimula a troca de idéias. Segundo o Coordenador de Desenvolvimento do Instituto Infnet, Fábio Binder, existe um estudo do International Journal of Human Computer Studies demonstrando que uma dupla de novatos pode até render mais do que uma dupla de experts.

Independente da experiência, para a programação em par funcionar é essencial que os dois profissionais estejam capacitados a trabalhar em grupo. Características como receptividade, paciência, compreensão e humildade são fundamentais.

“O gerente da equipe precisa selecionar profissionais que tenham sinergia, do contrário pode haver incompatibilidade de gênios, disputas de ego e discussões que não levam a nada – lembra Marques.

Prós e contras

Engana-se quem pensa que a programação em par não é produtiva. Por vários fatores, o trabalho em dupla pode ser executado numa velocidade correspondente ou superior ao trabalho individual. Além da economia de tempo em depuração e revisão de erros, a troca de idéias gera uma busca por soluções mais simples.

Outro ponto de vantagem é a chamada “pressão do par”. Ao trabalharmos em grupo, nos sentimos menos confortáveis em fazer pausas longas. Quando a interrupção é realmente inevitável, um dos membros da dupla pode “assumir o comando” enquanto o outro resolve a situação. Mas esse ponto também pode se tornar uma desvantagem, segundo Luiz Marques.

“Há menos interrupções e pausas menos prolongadas, porque um está sempre ‘puxando’ o outro para o trabalho. Em compensação, se os dois começarem a bater papo sobre assuntos que não têm a ver com o código, não tem jeito – diz, rindo.

O processo de revisão simultânea também tem um outro efeito: a redução do estresse. Os profissionais se sentem mais seguros com o trabalho, pois o índice de erros é reduzido e, quando eles ocorrem, a responsabilidade é dividida. Novamente, um pró pode virar um contra – a dupla pode ficar confiante demais e deixar os erros passarem.

Promessa pro futuro

A programação em par ainda é uma novidade. A técnica foi discutida pela primeira vez em 1991, mas só começou a chamar atenção com o aumento da popularidade do Extreme Programming, em 2000. No Brasil, são poucos os que adotam formalmente este método de trabalho.

“Tem quem use informalmente, sem nem se dar conta. Em qualquer profissão, quando a gente tem uma dúvida, é natural discuti-la com alguém – diz Júlio Bertolini.

Como com toda novidade, existe um certo grau de preconceito contra o pair programming. Isso não quer dizer que a nova técnica esteja fadada ao esquecimento, como explica Luiz Marques.

“Tudo que é muito inovador encontra muita resistência e muita coisa demora a pegar. É como a programação orientada a objetos, por exemplo: essa metodologia é da década de 60, mas só agora virou realidade de mercado. E hoje todo mundo adota – conclui.

Matéria original
http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1200

Fonte: TI Master, dezembro 2006