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.

Oferta
Extreme Programming: Aprenda Como Encantar Seus Usuários Desenvolvendo Software com Agilidade e Alta Qualidade
  • Teles, Vinícius Manhães (Author)
  • 328 Pages - 10/06/2014 (Publication Date) - Novatec Editora (Publisher)

O que é programação e par?

Bernardo e Elmar por ImproveIt

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

Focus por Dani Ihtatho
Focus por Dani Ihtatho

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

Owen teaching Dad how to use the computer pro Jordan Brock
Owen teaching Dad how to use the computer por Jordan Brock

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

asians with swords! por miss karen
asians with swords! por miss karen

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) por Dustin Baxter
“Ping (Pong)” por Dustin Baxter

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:

  1. O Programador A escreve um novo teste e o deixa falhando.
  2. O Programador B implementa o código necessário para fazer o teste passar.
  3. O Programador B escreve o próximo teste.
  4. O Programador A implementa o código necessário para fazer o teste passar.
  5. O processo se repete.

Pausas

Pause por Vanderlin
“Pause” por Vanderlin

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!

Wrong Way por Emilie Eagan
Wrong Way por Emilie Eagan

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 […] .

Oferta
Implementando o Desenvolvimento Lean de Software: Do Conceito ao Dinheiro
  • Poppendieck, Mary (Author)
  • 280 Pages - 08/30/2010 (Publication Date) - Bookman (Publisher)

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