Programação em par: 1+1 = 3

Vi uma matéria no Imasters e gostaria de compartilhar com vcs.. .segue ela na integra..


1+1 = 3
Aloha! O cálculo parece ser uma piada mas, na prática, é o que tentarei explanar e pontuar aqui: programação em par rende e faz bem ao projeto, seja você uma equipe ágil ou não.

Programação em par (pair programming) é uma das práticas pregadas pela XP (eXtreme Programming) e metodologias ágeis em geral. Pra lá de polêmica (principalmente entre os gerentes de projeto e de "recursos"), a programação em par é o terror das empresas com poucas pessoas e/ou projetos com escopos malucos e sem vivência ágil, mas é exatamente aí que ela pode se tornar uma grande aliada do time, da empresa e dos projetos.

Como o próprio nome já diz, a programação em par descreve a prática de desenvolver software em par no mesmo computador: enquanto um programa, o outro fica de "papagaio de pirata", apontando erros, sugerindo coisas e pentelhando o amigo que está desenvolvendo. Elas se revezam no teclado de tempos em tempos e os objetivos disso são muitos.

Um segura, o outro bate

João e Joca prontos!

Na vida real isso seria uma covardia, mas, estrategicamente falando, o fato é que se você entra numa briga com um amigo (principalmente que já chega na voadora), tudo fica MUITO mais fácil: você intimida o inimigo, aumenta a auto-confiança e as chances de ganhar a batalha de forma muito mais rápida e efetivamente aumentam dramaticamente.

Em um projeto isso soa da mesma maneira: a troca de experiências, fundamentos e, principalmente, sinergia de aptidões e especialidades eleva o nível de programação. O programador menos experiente ganha experiência e macetes. O mais experiente refina seu conhecimento, encara novas possibilidades apresentadas pelo mais novo e lapida finamente conceitos, da forma mais didática possível.

Então, existem vários pontos e consequências muito positivas quando você, gestor, e você , desenvolvedor "super-homem" e "lobo solitário", programam em par:

a troca de conhecimentos fica transparente entre o par e o modo mais bacana de implementar aquela regra de negócio que "só o João é que sabia", e agora é sabida pelo Pedro, Joca e José;
a abdução pelo MSN/Talk/Twitter (ou as coisas que distraem) será bem menor devido à presença do par ao lado pensando "Coé! Vai trabalhar ou não *****?";
essa é pros gestores não ágeis: programação não é apenas digitação (trabalho mecanizado), e sim um trabalho de escolha (tentativas corretas ou erradas). E nisso duas pessoas se saem BEM melhor (seja a caminho do #epicwin ou #epicfail);
o vínculo pessoal aumenta entre os pares e, com isso, a confiança se fortalece, acabando ou diminuindo o "se fosse eu, teria saido melhor";
com a confiança aumentada, o par passa a se comprometer ainda mais com o resultado final de forma muito natural, afinal a pessoa não quer deixar seu novo amigo na mão (e nem a oportunidade de fofocar um pouco durante o pareamento);
as soluções encontradas tendem a ser melhores documentadas/implementadas;
psicologicamente, o par sempre vai querer mostrar "o seu melhor" para o outro;
quando o par não souber resolver nada, ele não vai conseguir passar O DIA INTEIRO abrindo e fechando a mesma tela enquanto pensa numa solução: o parceiro geralmente ou auxilia, ou, no mínimo, vira mais um na pesquisa pela solução correta;
as barreiras pessoais caem e as pseudo-picuinhas ou viram picuinhas de verdade ou viram uma grande piada entre o par (e com sorte o time) depois de algum tempo;
é uma das melhores formas que vi até hoje de fazer as pessoas entenderem o que é trabalhar em grupo;
e por aí vai!
Mas eu não tenho time, eu tenho recursos
Muitos amigos/parceiros de outras empresas sempre perguntam pra mim e o pro povo aqui da Giran como trabalhamos, porque eles mesmos já tentaram, tentam ou têm curiosidade de implementar metodologias ágeis em seus ambientes de trabalho. Geralmente o que me falam é que lá as pessoas são tratadas como recursos, e não como um time.

Num dado momento, as pessoas têm suas 8 horas/dia (hellllooow! aumenta isso aí, tio!) de trabalho e isso no M$ Project fica lindo: afinal, podemos colocar o Joca alocado 70% do seu dia numa tarefa e 10% em outra e mais 20% numa outra completamente distinta. Ou melhor: podemos fazer o João entregar em 2 dias e 4 horas aquele módulo de detecção de XSS NO SITE INTEIRO.

Parte do problema que tento passar pros meus amigos é que as pessoas da empresa não são engrenagens, mas sim pessoas, com seus problemas pessoais, limitações técnicas, dias ruins (que não rendem nada) e que nem deveriam ter começado. A partir do momento em que os recursos não são considerados como produtores de porcentagens em planilhas, mas sim pessoas que implementam escolhas e entregam produtos (resultado dessas esperadas BOAS escolhas), uma parte grande do problema se desfaz e o mundo fica até mais claro.

Mas, mesmo enquanto "recursos" (afinal, seu chefe não quer que os cronogramas os enxerguem de forma tão humana porque isso é perder dinheiro), ainda sim a programação em par se apresenta como uma ótima alternativa para driblar algumas limitações impostas pelo modelo manufatureiro (e antiquado) de produzir software:

você pode botar um recurso que está produzindo pouco para parear com outro mais "ativo" ou com mais moral da equipe interna: o recurso que está "patetando" vai se ligar rapidinho e começar "magicamente" a trabalhar mais, seja pela pressão do par, seja pelo poder de liderança que esse par vai ter sobre ele (às vezes o cara considera o amigo mais chefe do que você, que, em tese, deveria ter esse poder);
liderar é servir: essa dica acima é muito importante quando você desejar criar um líder natural de equipe, que faça as peças funcionarem sob alta temperatura sem ranger ou quebrar;
faça seus recursos parearem ao menos no início de um novo projeto: assim, o alicerce ficará bem conhecido e a tendência do João levantar uma parede de gesso onde o José deveria colocar o quadro ultra-pesado diminui bastante. "Mas você não me falou que tipo de parede era e eu achei que essa iria dar conta do recado? putz, você nem pra me dizer que o quadro era tão pesado né?" (sinto cheiro de re-trabalho...);
fazer par com aquele programador/designer/pessoa-difícil que todo mundo fala que faz tal coisa errada, mal-feita ou que poderia ser melhor vai ser uma maneira muito efetiva de fazê-lo começar a trabalhar direito a partir de então;
juntar dois recursos-difíceis assim pode ser uma ótima oportunidade de fazê-los melhorar em conjunto ou você matar dois coelhos com uma caixa d'água só;
Passos de bebê para a programação em par
Bacana, legal! Mas tem gente que vai se perguntar: "Putz! Mas como transformar 8 pessoas em 4 da noite pro dia?". Tem muita gente doida (acho que essa é a palavra) que acha que radicalizar da noite pro dia vai adiantar ou ajudar em algo. Em se falando de programação em par, então, isso fica ainda mais frenético. Na Giran mesmo, ainda adaptamos continuamente nossa forma de trabalho com SCRUM/XP com idéias vindas do time, de coisas que lemos por aí e que descobrimos durante o dia-a-dia de trabalho. A programação em par foi uma delas e que nos deixa hoje muito contentes em levar a cabo.

Então, gostaria de compartilhar algumas dicas que podem ajudar você a fazer seu time ou seus N recursos a trampar em par e trazer um retorno de produção bacana, num curto espaço de tempo, bem como você descobrir que isso NUNCA vai dar certo na estrutura da sua empresa (isso também em um curto espaço de tempo):

faça pares com um iniciante e um mais experiente, para que os conhecimentos trocados sejam mais efetivos;
num escopo de uma semana, faça as pessoas parearem ao menos uma vez por dia, por projeto;
se você trabalha com tarefas de um dia, faça as pessoas parearem em ao menos duas delas por semana;
um ótimo recurso para temporizar um pareamento é faze-lo em Pomodoros, que são boxes de tempo de 25 minutos (1 pomodoro = 25 min) em que as pessoas têm que manter o foco. Dois pomodoros são uma ótima pedida para começar um pareamento;
pareie pessoas com rendimento baixo com pessoas de rendimento maior (independentemente do nível técnico), para dar um choque de realidade neles.
Para começar isso, já deve dar um pouco de "trabalho" para você, gestor ou líder na equipe, implementar isso de uma forma bacana. Uma forma legal de ajudar nisso, e em vários outros pontos, é praticar reuniões rápidas matinais de 10 minutos em pé (prática conhecida na XP como Stand-up Meeting) para revisar o que foi feito no dia anterior: nesse ponto, você vai identificar até que ponto os pares não apenas trabalharam juntos, mas também fomentaram novas idéias e alternativas.

Por enquanto é só, pe-pe-pessoal! Boas programações em pares e lembrem-se: programar não é apenas digitar.
por:Léo Hackin é CEO, Consultor e arquiteto de aplicações web na Giran Soluções e Ensino, coordenador do grupo PHP-ES