Já faz algum tempo que a programação em par se tornou uma realidade do meu dia-a-dia, confesso que nos meus primeiros contatos com Extreme Programming (XP) essa era a prática que eu menos gostava, mas depois, ao me envolver mais com práticas ágeis comecei a perceber seus benefícios e inclusive passei a propagar a idéia, porém agora, senti um mais de perto como realmente funciona e gostaria de compartilhar um pouco do que venho aprendendo.
O que é programação e par?
A programação em par é uma técnica que sugere que todo e qualquer código produzido em um projeto de desenvolvimento de software seja implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado [1]. A Pessoa quem está com teclado em mãos é chamada de condutor e a outra de navegador.
Por que programar em par?
“Unir-se é um bom começo, manter a união é um progresso, e trabalhar em conjunto é a vitória.”
(Henry Ford)
Foco no trabalho
Temos o mundo inteiro de informação e recursos ao alcance de alguns cliques. A internet, o correio eletrônico, o feed reader, somos tentados o tempo todo a nos distrair, e perder o foco do nosso objetivo principal: escrever código.
A programação em par nos ajuda a manter o foco, afinal de contas, temos alguém sentado ao lado interessando em ver o problema resolvido, assim, com certeza, mesmo que tentados iremos evitar fazer outra coisa senão concentrar nossas energias em resolver o problema em questão.
Isso não quer dizer que seja proibido consultar algo na internet, ou ler e-mails, na Bluesoft, por exemplo, sempre temos algumas máquinas disponíveis para esse tipo de coisa, porém, garanto que a freqüência desse tipo de atividade é bem menor quando se trabalha em par, e não são somente as distrações que são reduzidas, segundo Laurie Williams [3], as pessoas são menos interrompidas por outras quando trabalhando em par do que quando trabalhando sozinhas.
Ensinar e Aprender
“Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende.“
(Leonardo da Vinci)
Todos nós somos diferentes, pensamos de forma diferente e sabemos coisas diferentes, programando em par essas diferenças podem se complementar de forma positiva trazendo mais qualidade ao trabalho e muito aprendizado a ambos os envolvidos, não somente conhecimentos técnicos, mas também muito conhecimento sobre o domínio de negócio são trocados todo o tempo.
Exterminando ilhas de conhecimento
“uhmmm…, esse problema é só com fulano mesmo, ele quem desenvolveu e sempre deu manutenção nisso, nem adianta tentar porque ninguém mais vai conseguir resolver isso “.
Quem nunca ouviu algo assim? Eu já, e muitas vezes. É comum, especialmente em contextos em que não são aplicadas metodologias ágeis, existirem ilhas de conhecimento, essas ilhas são representam o conhecimento retido por pessoas que não o com outras, muitas vezes por falta de oportunidade, outras por pensar que dessa forma se tornaram insubistituiveis, bobagem.
Ilhas de conhecimento podem se tornar um grande problema, porque a manutenção do software fica extremamente dependente da pessoa que retêm o conhecimento, e essa pessoa pode a qualquer momento sair da empresa, ficar de férias, estar viajando, etc… Mas e quando ocorrer um problema crítico e a pessoa não estiver presente? O grande problema é que tudo fica dependendo da ilha.
A programação em par estimula a troca de conhecimento, faz com que todo a equipe compartilhe o código e saiba um pouco de tudo o que foi desenvolvido, tornando assim, a toda a equipe capacitada a resolver qualquer problema a qualquer momento, se um membro da equipe estiver ausente, provavelmente não haverá poblemas por isso.
Mais disciplina = Mais qualidade = Menos bugs
A programação em par aumenta a qualidade do software sem impactar de forma significativa no prazo [2]. Apesar de ser contra senso que duas pessoas trabalhando em um único computador podem produzir mais valor do que trabalhando separadamente, sem dúvida é fácil de acreditar que irão entregar um trabalho de muito mais qualidade, e essa qualidade adicional, por si só, trará grandes ganhos mais tarde.
Laurie Williams da universidade de Utah em Salt Lake City comprovou que a programação é em média apenas 15% mais lenta do que a programação individual, porém, produz 15% menos bugs [5]. Considerando que testar e debugar é na maioria da vezes muito mais custoso do que a programação inicial, esse é um resultado no mínimo significativo.
Segundo Vinícus Teles, “a pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências.
O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela. Ao fazer isso, ele acaba tendo uma visão complementar que freqüentemente revela problemas que o condutor não percebe com a mesma rapidez” [1], dessa forma, o código está sendo revisado o todo o tempo, sem contar que programar em par evita que caiamos na tentação de não escrever testes unitários ou deixar refactorings de lado [4].
Dicas
Ping-pong programming (P3)
Ping-pong Programming [12]é um técnica que une programação em par e test driven development tornando o a programação em par mais divertida [13], dinâmica e interativa, consiste nos seguintes passos:
- O Programador A escreve um novo teste e o deixa falhando.
- O Programador B implementa o código necessário para fazer o teste passar.
- O Programador B escreve o próximo teste.
- O Programador A implementa o código necessário para fazer o teste passar.
- O processo se repete.
Pausas
Pare! Tome um café. Coma alguma coisa. Converse com outras pessoas além do seu par [7]. Tudo isso será bom para que descanse um pouco, se distraia e se prepare para voltar mais disposto e dar continuidade na tarefa.
Cuidado com discussões longas
Estabeleça um time-box para discussões. É comum que dois programadores discordem ao tentar decidir as melhores formas de implementar algo, quando isso acontecer, procure ouvir as razões da outra pessoa e apresentar suas argumentações, tentem chegar a um meio termo, se isso não for possível chame uma terceira pessoa para dar uma opinião.
Não resista em ceder quando perceber que outro pode estar certo, lembre-se você está aprendendo e ensinando o tempo todo, não há problema algum em estar errado de vez em quando.
Não se engane!
Mito: Sem Programação em Par, não há Agilidade
Martin Fowler uma das personalidades mais respeitadas no mundo do desenvolvimento de software escreveu um artigo em 2006 levantando alguns dos principais enganos sobre programação em par. Fowler esclarece em seu artigo que “não é necessário programar em par para estar praticando um processo ágil” [11], nem mesmo para se pode dizer que para aplicar Extreme Programming você é obrigado a programar em par, o máximo que se pode dizer é que alguém aprender XP, deve tentar programar em par e ver se funciona em seu caso em particular [11]. A programação em par não é nem mesmo citada no manifesto ágil, porém, é uma prática altamente recomendada para que se alcance os principios ágeis.
Mito: A Produtividade cairá pela metade
Um outro engano muito comum é pensar que a produtividade dos desenvolvedores cairá pela metade, como discutimos anteriormente, na maioria dos casos essa afirmação será falsa.
Mito: Tenho certeza de que não vou gostar de programar em par
Segundo Fowler, muitas pessoas surpreendem-se e começam a gostar de programar em par depois de tentar, por isso, experimente antes de dizer de não gosta!
Conclusão
Concluo com a citação de Mary e Tom Poppendieck no livro “Implementing Lean Software Development”:
Programação em Par não é para todos, nem para todas as situações, porém, a programação em par cria sinergia: Duas pessoas vão frequentemente entregar um código mais integrado, testado e sem defeitos, trabalhando juntas […]. A Programação em par é uma das melhores formas de se atingir os benefícios de revisões de código […] .
Referências
[1] Improvit – Programação em Par
[2] Extreme Programming Rules – Pair Programming
[3] Williams, Laurie (2003). Pair Programming Illuminated, Addison-Wesley
[4] Beck, Kent (2000). Extreme Programming Explained, Addison-Wesley
[5] Cunningham & Cunningham – PairProgramming
[6] Mark Needham – Pair Programming: What works for me
[7] Brian Guthrie – The Way I Pair
[8] thekua.com@work – How I like to pair
[9] InfoQ – Pair Programming Debate
[10] InfoQ – Common misconceptions about paired programming
[11] Martin Fowler – Pair Programming Misconceptions
[12] Pair Programming Ping Pong Pattern
[13] Ping Pong Pairing: Even More Fun!
[14] Poppendieck, Tom and Mary (2007). Implementing Lean Software Development, Addison-Wesley
Ensinar e Aprender…
É a verdade absoluta do resultado da programacao em Par.
Não tenha medo que o outro análise o seu código ou brinque com você a respeito de erros..
Pois na prática ele está te ensinando, e você também na prática ira ensinar muito ele, ou algum novo programador que um dia chegará na equipe..
A melhor coisa pra isso, e ser parceiro, e deixar o ego do lado de fora, na realidade jogar o ego na lixeira do windows ou do linux..
Abs,
Marcos
Andre,
ótimo post.
Complementando o assunto, aqui tem um outro post bem interessante tbm sobre programacao em pares.
http://www.thekua.com/atwork/2008/12/how-i-like-to-pair/
Um abraco,
Francisco
Perfeito!
Código revisado, transmissão de conhecimento, troca de experiências, evitar ilhas de conhecimento. Tudo isso é bom para a empresa.
A Simplicidade também é muito beneficiada pela Programação em Par, pois o desenvolvedor pode decidir por uma solução que se torne muito complexa futuramente e ninguém poderá dar manutenção. Em par, é comum a solução mais simples ser adotada, pois são duas pessoas pensando no mesmo problema.
Em par, escrevemos código para o navegador entender. E se não estiver claro para ele, é uma dica que devemos melhorar o código.
Qualquer pessoa pode programar, mas escrever código para os outros lerem, só bons conseguem fazer.
P3 é muito divertido!
O Vinícius Teles fez a seguinte metáfora em um desses eventos:
Escrever código é como carregar um sofá em uma mudança. É mais fácil carregar o sofá em dois do que sozinho.
Parabéns André.
Deu uma visão muito bem resumida do assunto (pelo menos do que nós conhecemos sobre ele).
Apesar das diferentes opiniões na empresa, com certeza vamos chegar num equilíbrio entre o que fazer em par e o que não fazer.
Abraço
Gostei do post, mas como critica construtiva, acho que você pode enriquecer mais o artigo colocando situações de você vivenciou, percebeu e como aconteceram.
Por exemplo, na primeira programação em par que tentei fazer na empresa que participo, por não saber exatamente como fazer, acabamos fazendo “programação paralela”, acho assim que, seria muito interessante e um diferencial ainda mais edificante se você pudesse escrever estorias ou historias sobre como e o que fazer na programação em par.
Abraço,
Claudio Capistrano
Excelente post! Acho que depois de ler disso não tem porque alguém não querer pelo menos experimentar pair programming.
Ola Andre,
Muito bom! Me surpreendi com o artigo e aumentei a minha lista pessoal de vantagens do pair programming com as suas observações…
Interessante a dica do ping-pong, não conhecia!
[]s,
Rodrigo de Toledo
Parabèns pelo post andre, com certeza o ping-pong em programação em par é uma otíma solução para o co-piloto se sentir mais utíl, e havendo revezamento os dois estão interagindo e revisando.
Abraço
well
Muito bom o post
Olá André,
Excelente! Realmente percebemos que o trabalho em equipe sempre resulta em produtos melhores. Aparentemente, achamos que o tempo de desenvolvimento em pares é maior. Isso cai por terra quando fazemos de forma organizada e, principalmente, quando passamos para a fase da evolução do código.
Individualmente já percebemos que o trabalho resultante não foi tão bom na primeira iteração de uma evolução do código-fonte. Já na programação em pares percebemos que existe uma maturidade maior no resultado dos códigos.
Gostei da sua abordagem…. Valeu!!
Marco Hisatomi
Muito Obrigados à todos.
@Capistrano, grato pela sugestão, vou procurar abordar isso tudo melhor nos próximos posts.
Andre, cada vez mais voce esta se superando na sua maneira de compartilhar os seus aprendizados. Continue esta sua caminhada de sucesso.
Fala Andre!
Muito bom seu post, voce conseguiu transmitir os principais aspectos sobre pair programming em um post curto, que eh excelente e facil de ler. Parabens!
Btw, another interesting post:
http://dahliabock.wordpress.com/2008/12/09/be-a-good-pair/
Muito bom o post, bem claro e resumido.
Para completar vou colocar como foi nossa experiência:
O André e eu começamos a trabalhar em par durante duas semanas. No começo foi complicado, pois cada um tem maneiras diferentes de pensar e trabalhar. Com o passar dos dias, mesmo um não aguentando mais ver a cara do outro =), começamos a perceber que havíamos compartilhado experiências e conhecimentos que o outro não tinha, e além disso, tínhamos mais confiança em nosso código.
Nos últimos dias descobrimos o “ping pong pairing”. Nos serviu muito bem, pois naquele momento desenvolvíamos uma classe com vários cálculos e funções que necessitavam de vários testes, que foram desenvolvidos com uma velocidade bem maior da qual estávamos trabalhando antes.
Foi muito válido.
Na minha opinião é importante programar em par devido a todos os motivos citados no post, mas não em todas as situações. Em tarefas mais simples, poderíamos moderar quando fazer ou não a programação em par.
Em tarefas mais complexas ou no desenvolvimento de novos módulos e funcionalidades, que exigem conhecimentos de tecnologias atuais, reconheço que é mais proveitoso a programação em par, para partilha do conhecimento e a revisão do código tornando-o mais claro de se entender e a prova de bugs com os testes.
Acho que é isso.
Abraço
Bacana!
Gostei muito! Foi bem exclarecedor!
Oi! Apesar de não ser programadora, levo os principios do agil para a prática do design de sistemas. Inclusive experimentando a pratica do trabalho em par para design de interface por exemplo, prototipação rápida em papel, etc. Observamos os mesmos benefícios de forma analoga:
– compartilhar a mesma visão e conhecimento
– um tem uma visão mais estreita do problema enquanto o outro percebe um todo
– o problema é resolvido de forma mais rápida
– estimula o trabalho mais organizado
A Laurie Williams é de fato a pessoa que mais pesquisou sobre programação em pares. Na página dela (http://collaboration.csc.ncsu.edu/laurie/publications.html) existem vários artigos, vale a pena dar uma vasculhada.
André,
Excelente compilação sobre programação em par! Parabéns!
Excelente André!
Duas pessoas trabalhando juntas num mesmo computador, compartilhando código, idéias e soluções é muito mais produtivo e dinâmico, visto que para chegarem em soluções é sempre necessário uma boa discussão, e discussão sempre resulta no domínio do conteúdo e na resolução do problema!