BT

Programação em pares ganha cobertura na imprensa não-técnica

por Todd Charron , traduzido por Leonardo Campos em 19 Set 2012 |

A quantidade crescente de empresas praticando a programação em pares chamou a atenção do Wall Street Journal (WSJ) que publicou suas impressões - bastante negativas - sobre a prática, no artigo Programadores aprendem uma lição difícil sobre o compartilhamento.

A programação em pares está ganhando adeptos em empresas de tecnologia como o Facebook e o Square (a startup de pagamentos móveis). Os defensores da programação em pares falam de forma entusiasmada das suas vantagens, como a facilidade de os pares perceberem erros que seriam custosos se descobertos mais tarde e que há menos possibilidade de se gastar tempo navegando na internet.

Mas também apontaram problemas com a prática, comparando-a a um namoro.

A realidade pode parecer mais como um encontro às cegas fracassado e sem fim. Aborrecimentos entre os parceiros se acumulam rapidamente: desde a falta de higiene pessoal e educação básica, ao compartilhamento de apoios de pés.

Na Pivotal Labs, uma empresa de desenvolvimento de software comprada pela gigante EMC Corp em março, os 175 engenheiros trabalham em pares o dia todo, todos os dias. Alguns praticam algo conhecido como "pareamento promíscuo", mudando de parceiros diariamente.

A comparação com namoros continua:

Resolver problemas com um parceiro pode ser como resolver problemas com uma namorada ou esposa. "É como em qualquer relacionamento," diz Kite. "Se não se conversa sobre os problemas, o relacionamento não funciona."

O artigo conclui com a história do Drive Current e a experiência da empresa com programação em pares.

Após dois anos pedindo aos engenheiros da empresa que passassem três horas por dia pareando, decidiu-se abandonar a prática em setembro. "Não acredito serão sentidas muitas saudades", disse o diretor.

Vários desenvolvedores expressaram suas opiniões e experiências nos comentários. Anne Bennet declarou:

Tivemos um gerente que pensava em implantar a programação em pares, mas felizmente ele não trabalha mais conosco. Estou quase aposentada e consigo imaginar alguém revisando meu código, mas escrevendo ao mesmo tempo? Para mim, não.

Mike Edwards relata algumas experiências positivas trabalhando em pares.

A programação em pares é benéfica para quem precisa trabalhar com códigos legados que estejam há muito tempo negligenciados e fora de condições de conserto. Ter uma testemunha ajuda a tornar tudo mais tolerável.

Christopher Wong acredita que o sucesso do par depende das personalidades dos envolvidos.

A programação em pares me dá o sentimento de estar preso em uma reunião o dia todo, todos os dias. Pessoalmente acho desgastante, mas algumas pessoas podem se sentir energizadas com a técnica. É uma questão que depende da personalidade dos envolvidos, e deveria ser deixada à vontade apenas para quem a quisesse praticar.

Nem todos concordaram com a avaliação do Wall Street Journal. Roger Neel, co-fundador e CTO da Mavenlink entende que o artigo apresenta uma visão injusta da prática do pareamento. Na visão de Neel, o WSJ entendeu errado a programação em pares.

Decidimos utilizar Ruby on Rails há muito tempo, e começamos a procurar por uma empresa parceira no desenvolvimento. Encontramos a Pivotal Labs. Durante o levantamento do escopo do nosso projeto, conversamos sobre as práticas ágeis adotadas pela Pivotal, como desenvolvimento orientado a testes e o pareamento. Para nós, naquele ponto, o pareamento foi uma ótima maneira de nos treinar nas melhores práticas da Pivotal. Pouco imaginávamos que iríamos passar os próximos três anos trabalhando lá e que contrataríamos nossa própria equipe com base na competência na programação em pares.

Roger Neel levantou problemas quanto os exemplos que o WSJ escolheu.

Foi escolhido um exemplo de uma empresa cuja cultura não se adequava ao pareamento, e um exemplo de pessoa que também não gostava. E as outras empresas, as que gostam da prática?

Neel explica, ainda, os benefícios da programação em pares e aponta uma relação entre pareamento e Ioga; de como ambas foram consideradas esquisitas e o Ioga acabou se popularizando.

O pareamento se trata de colaboração, escrita de código de melhor qualidade, aprendizado, além de ajudar a manter um ao outro sob controle. Com um pouco de prática, a colaboração e a troca de ideias acontece mais facilmente, mas nem todos conseguirão sair escrevendo código de primeira. Não se para de praticar Ioga porque ainda se tem pouca flexibilidade, da mesma forma que não se para de parear por causa da necessidade de se conversar muito ou pouco.

Neel também declara outros benefícios da programação em pares.

A programação em pares e a rotatividade diária contribui na redução da necessidade de muitas reuniões. Caso todos passem por boa parte do ciclo do produto, todos terão experiência com os caminhos paralelos do desenvolvimento do negócio e cada par será capaz de tomar suas próprias decisões sobre o dia de trabalho.

Embora reconheça que o pareamento não seja para todos, Roger Neele também compara a programação em pares a outra práticas comuns.

Um modelo tradicional para o desenvolvimento de software é trabalhar separadamente, com a revisão regular de código pelos pares e o coaching entre as pessoas. Isso pode funcionar bem em organizações extremamente disciplinadas, mas o que frequentemente acontece na realidade é que todo desenvolvedor precisa desenvolver dezesseis horas de código em um dia de oito, de forma que a última preocupação são os problemas alheios. Aliás, sem contexto e sem grande investimento de tempo, como se pode compreender um problema com o qual alguém vem trabalhando há dias? Revisões com tempo limitado levam a refatorações superficiais, sem grandes discussões ou melhorias.

Ao combinar técnicas de design ágil com comunicação e rotatividade constantes, a programação em pares é uma excelente maneira de chegar iterativamente a um consenso, ao invés de "jogar a toalha" e recomeçar depois de ter metade do desenvolvimento pronto.

Qual sua experiência com programação em pares? Caso seja um adepto, como apresentou a ideia para os pouco familiarizados com a prática? (Você pode verificar os resultados da nossa pesquisa sobre a adoção da programação em pares ou responder à pesquisa você mesmo.)

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Parear é comunicar by marco moura

Trabalho fazendo "pareamento promíscuo".. heheh ... em tempo integral há 15 meses .

Posso afirmar que melhora a qualidade do código, o foco do time e o conhecimento sobre o projeto onde há várias pessoas codando.

É mais desgastante fazer par tempo integral, e já trabalhei com pessoas que são mais produtivas sozinhas.

O melhor em parear é a comunicação entre o time e o review de código... o f**a é nego passar o dia codando com fone no ouvido e sem mostrar o código pra outros..

É contexto by marcel peixoto

Cada um tem sua realidade. Pessoalmente, acredito muito na qualidade do fonte quando se programa em par. Senti-se muito mais seguro para realizar mudanças em códigos fontes existentes e etc. Além disso, o ganho em foco é tremendo. Mas os extremos também é ruim, parear o dia inteiro pode ser demais, mas também programar o dia inteiro sem mostrar o que estás fazendo não é nada bom.

Não foi negativo.. by Guilherme Chapiewski

Não foi negativa a matéria... Com certeza também não foi positiva, mas o que eu vejo de positivo é que empresas verão que outras empresas como Facebook adotam essas práticas, fazendo com que elas ganhem notoriedade e se disseminem, o que é ótimo para o mercado na minha opinião :)

Re: Parear é comunicar by Carlos Dias

'codando'?

Re: Parear é comunicar by Fidelis Guimaraes

Para quem trabalha muitas hora por dia com a criação propriamente dita do Produto Final Carlos Dias, viver "codando ou codar" é um jargão que está compilado no proprio DNA. Trabalho com freelances usando pareamento de 15 minutos para cada um "codar", e pra mim é como ter um conselheiro no seu ombro sempre orientando a ideia de outra visão. Se vc está jogando, sempre alguem que está de fora acompanhando seu raciocinio poderá ter uma melhor visão do todo ou confirmar sua boa jogada.
Atualmente no meu trabalho apenas pareamos para decisões de arquiteturas, refatoramentos, mudanças criticas ou ajuste de uma melhoria de boa para ótima.
Sempre perguntamos:
-Esta será a melhor abordagem ou você conhece uma forma melhor de se fazer?
-Se você pegar meu codigo, consiguirá entender o meu raciocinio nesta regra de negócio?
-Existe algum ponto no sistema que já faça isto ou posso continuar criando esta solução?
-Alguem irá querer refatorar este código depois ou posso fazer isso agora mesmo?

Isso com certeza almenta a criticidade pessoal sobre o sua qualidade de desenvolvimento de soluções!

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

5 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT