quarta-feira, 18 de maio de 2011

Xtreme Programming - On Demand

Olá pessoal, estou de volta e dessa vez vou falar sobre um dos temas mais polêmicos do Extreme Programming que é o Pair Programming.

O Pair Programming consiste em dois desenvolvedores atuando no mesmo problema no mesmo computador, sendo um o Piloto e o outro o Navegador. Semelhante ao que temos nas corridas de Rally :p .

Bom, o primeiro grande desafio da programação em par é convencer os nossos chefes de que não será improdutivo manter duas pessoas no mesmo computador full-time. O segundo desafio é a equipe, infelismente nem todos estão aptos a trabalhar com Pair Programming. Muitos, ao invés de serem navegadores, serão simplesmente passageiros, enquanto o piloto desenvolve o passageiro apenas contempla a paisagem e não presta atenção nem mesmo no caminho que está sendo tomado.

Pois bem, na minha opnião, não é necessário ter dois desenvolvedores juntos full-time nas tarefas do projeto, eu acredito mais no Pair Programming On Demand, ou seja, para tarefas mais específicas, desafios maiores, requisitos que possuem maior risco, complexidade. Até porque, pensem comigo, para que ter dois desenvolvedores na implementação de uma solução simples, getters and setters, binds, dao's, ou seja, tarefas rotineiras que já estão no sangue da equipe de desenvolvimento, nestes casos penso que Pair Programming não agrega muito.

Agora quando temos uma rotina complexa, onde temos um grande risco envolvido, ou uma refatoração mais delicada, aí sim, acho que é muito válido a aplicação do Pair Programming para que o problema, o desafio seja resolvido, por isso que digo que acredito mais no Pair Programming On Demand, ou seja, aquele que só é aplicado quando surge uma demanda específica que justifique duas cabeças pensando no problema.

Os defensores mais ferenhos da técnica podem dizer que assim não temos o código completamente compartilhado pela equipe, ou que não inibimos o XGH, ou que decisões podem ser tomadas por um único programador.

No caso das decisões de design, eu diria que o ideal não é nem envolver só dois desenvolvedores mas todos. Em nosso projeto o que tem acontecido é que quando detectamos algum ponto que pode ser melhorado ou quando nos deparamos com algum requisito que demandará a aplicação de algum pattern ou criação de alguma biblioteca nova, sentamos e discutimos.

Com isso, quando forem aplicar Extreme Programming, como tudo na vida, usem e abusem do bom-senso e preste atenção na composição da equipe, certifique-se que os são porcos e não galinhas, e para perceber isso basta observar o comportamento dos desenvolvedores quando não estão pilotando, ou seja, se ele fizer um papel de navegador, tem grandes chances de ser um porco, se fizer papel de passageiro, tem grandes chances de ser galinha.

É isso pessoal, não tenham medo nem vergonha de "parear" em suas equipes, sem dúvida nenhuma duas cabeças pensam melhor do que uma, mas tenhamos bom-senso, pares para get e set, factories, singleton, binds e outras atividades tão triviais do nosso dia-a-dia... na minha opnião não fazem sentido.

Um grande abraço.

2 comentários:

  1. Fala Ricardo,

    Também acredito bastante no pair programming "on demand", fico feliz em ver a minha equipe pareando sempre que há necessidade para se resolver algum problema ou pensae em design para um ponto da aplicação.

    Como gerente da equipe "filtro" essas práticas para a diretoria para evitar juízos errados de valor. Por incrível que pareça, com os argumentos certos, a diretoria aceita bem as novas técnicas desde que se possa provar os benefícios que serão obtidos.

    Abração,
    Vinicius

    ResponderExcluir
  2. Com certeza Vinicius, e você tocou em um ponto importante, a questão do juízo errado de valor. É sempre importante deixarmos claro qual o valor que determinada técnica traz para o projeto, para a equipe, para o processo etc... ao invés de simplesmente implementá-la.
    É fundamental deixarmos claro a motivação por traz da técnica.

    Abraço.

    ResponderExcluir