O XP é uma metodologia de desenvolvimento Ágil, alguns consideram como framework, outros, assim como eu, consideram como filosofia. Não da dá pra aprender XP em um dia e no segundo dia sua equipe já será extremamente Ágil. Isso é mentira. Assim como programação, XP só se aprende com o tempo, treinando dia após dia.

O XP possui práticas e dentre elas a que eu acho mais vantajosa é a Programação em Par, que é a atividade onde dois programadores usam um computador e eles codificam juntos. Eu, quando comecei minha vida no desenvolvimento, não colocava muita fé nesse tipo de desenvolvimento. Cheguei a espalhar para outros programadores que duas pessoas em um computador não funcionava, e que seriam melhor um programador por computador.

Esse é o pensamento Taylor de desenvolvimento de software ainda presente em várias empresas no mundo onde duas pessoas, cada um fazendo o seu trabalho, são mais eficientes do que as duas em um único computador. Quem tem mais experiência com desenvolvimento de software sabe que isso é uma afirmação falsa. Pode sim duas pessoas em um computador ser melhor do que uma.

O fato é que duas pessoas se motivam para desenvolver. Como estão em par, ver email, olhar os twitts, ler feeds, não entra nesse tipo de desenvolvimento. Em par, as distrações são menores porquê quem está desenvolvendo está preocupado apenas no código, e fica um dando pilha para o outro.

O design da solução se torna melhor e mais consistente. Aquele velho ditado popular que diz que duas cabeças pensam melhor do que uma é verdade, dois programadores pensam melhor na solução do problema, discutem mais, avaliam mais os riscos, escrevem melhor os testes.

Na equipe você acaba com ilhas de conhecimento. Programação em par é uma prática que se faz em no máximo algumas horas, então você sempre estará trocando de par e assim estará compartilhando mais rápido o conhecimento do negócio entre a equipe.

Uma outra vantagem é o codigo compartilhado, a prática ajuda para que todos saibam o que está sendo feito em cada parte do código, assim faz com que acabe o “Dono do código”, já que toda a equipe fez parte do desenvolvimento.

Ainda assim, alguns programadores não gostam de fazer programação em par, nesses casos não se pode forçar a barra. Faça apenas com que eles saibam que valores eles estarão perdendo. Não o demita só porquê ele não faz programação em par, talvez ela realmente seja bom sozinho. Mas faça com que ele compartilhe o código, que ele não crie ilha de conhecimento e que se comunique ao máximo com a sua equipe.

Mesmo que sua empresa não adote uma metodologia, eu recomendo que você a adote no seu dia a dia . A curto prazo você pode ter a sensação de que não está evoluindo muito, mas a médio e longo prazo, você, sua equipe e sua empresa começarão a ter o retorno mais rápido e a satisfação no desenvolvimento será bem maior.