Conhecendo as dificuldades e as vantagens dessa prática XP
Nos últimos anos, o mercado de TI tem conhecido gradativamente, as vantagens de aderir às práticas da metodologia de desenvolvimento de software, Extreme programming (XP). Já existem muitos projetos sendo feitos sob a ótica ágil de XP e proporcionalmente a isso, as comunidades que debatem e incentivam seu uso vem crescendo cada vez mais no Brasil e no mundo.
Mas como XP defende conceitos e idéias ágeis, sua adoção também tem mostrado algumas lacunas na compreensão de algumas práticas propostas. Uma das práticas mais polêmicas é a de Pair Programming (Programação em Par) e nesse artigo, vou tentar mostrar de maneira clara e objetiva como implementá-la e como vencer seus principais obstáculos.
Conceito básico de Pair Programming
O conceito básico que envolve a prática de programação em par é o seguinte: compartilhar a codificação de uma classe, de um método ou de um trecho de código paralelamente entre 2(dois) programadores, onde, ambos trabalham ao mesmo tempo e no mesmo computador, mas claro que invertendo periodicamente entre os papéis do piloto e do co-piloto, ou seja, enquanto um dos programadores está codificando, o outro acompanha seu trabalho, observando se os padrões de projeto estão sendo seguidos, se a declaração das variáveis e métodos estão seguindo a mesma nomenclatura padrão, se sintaxe utilizada está correta, se método que está sendo implementado não pode ser simplificado, inclusive, já observando as possibilidades de refatoração no mesmo, se as regras de negócios estão de acordo com os casos de usos ou com os cartões, se os testes unitários ou de integração estão sendo seguidos a risca e de maneira geral, os programadores trabalham em par para compartilhar conhecimentos para melhor implementar as estórias definidas nos cartões.
Observe que ao contrário do que se pensa, o co-piloto, nem sempre deve ser o menos capacitado da dupla, pois devido a seu papel de quase “supervisão”, é importante que o mesmo possua uma grande capacidade e conhecimento sobre um projeto de software e suas minúcias. Mas a prática de alocar um programador forte com um fraco, também tem gerado bons resultados em muitos projetos, pois dessa forma em curto prazo, é possível pelo menos nivelar os conhecimentos técnicos sobre a linguagem usada no projeto, abordaremos a seguir, mas detalhadamente as vantagens da programação em par.
Práticas associadas, a grande vantagem
Uma grande vantagem da programação em par é o fato de a mesma favorecer o uso de outras práticas XP, como por exemplo: rodízio de pessoas, código coletivo, ritmo sustentável e padrões de projeto, pois basta lembrar dos conceitos dessas práticas, vejamos.
Rodízio de pessoas: uma vez que consiga dividir sua equipe em duplas, torna-se então possível fazermos periódicas trocas de pares, visando com que todos os membros compartilhem o conhecimento agregado no código produzido, favorecendo dessa forma à prática de propriedade coletiva do código, ou seja, nem uma classe ou método está somente sob a guarda de um único programador e todos possuem a mesma visão de todo o projeto.
Esse movimento de pessoas permite também ao coordenador da equipe, criar escalas de trabalho mais sustentáveis e não sobrecarregar ninguém com uma grade pesada de trabalho, favorecendo com isso a prática de ritmo sustentável.
Observe na figura abaixo, um modelo ideal para aplicação da prática de programação em par:
É importante observar que, devemos sempre que possível, deixar os programadores à vontade para determinarem, em que momento deverão fazer as inversão de papéis e de pares, onde cada dupla deverá ter a sensibilidade para notar esse momento. É comum que os pares se invertam, por exemplo, por motivo de cansaço, seja de codificar ou acompanhar a codificação.
Outras vantagens:
Em projetos que usam a prática de programação em par existem também vantagens com relação à qualidade do código produzido, pois é observado que:
- Há um aumento significativo na atenção depositada na codificação do software;
- O rigor é maior no objetivo de seguir os padrões definidos para aquele projeto;
- Dedicação do trabalho mental do momento, para o que está sendo executado em, dupla, pois dessa forma anula-se, à vontade de checar e-mails, acessar o ICQ, o MSN, atender telefonemas não produtivos, reuniões não produtivas e outras atividades na Internet que são fatores críticos de desvio de atenção.
- A quantidade de erros de sintaxe diminui;
- A necessidade de refatoração diminui;
- Os erros dos testes unitários também diminuem;
- Os programadores somam conhecimento para produzir códigos mais criativos e eficazes.
- text
- text
- text
Observe que a palavra chave é “ATENÇÃO”, pois, com o seu aumento na codificação, a velocidade de implementação dos cartões também é reduzida, principalmente pela quase inexistência de retrabalho, e dessa forma começamos a ver em nossos projetos a aplicação real do termo “metodologia ágil”.
Dificuldades e Obstáculos
Infelizmente, o uso de pair programming não é somente um “mar de rosas”, pois como mencionei no início do artigo, existem muitas lacunas em sua compressão e falhas na forma de adoção da prática, de modo que, os maiores relatos de problemas no seu uso são:
- Um aumento do custo de um projeto: Pelo fato de alocar dois programadores que normalmente são remunerados pelo cálculo de homem/hora, na codificação de uma interação que poderia ser executado por penas um programador.
- Facilidade em fugir da prática: É comum durante o projeto, ocorrerem casos que favoreçam a quebra de pair programming, como por exemplo: faltas, atividades extras(como configurações de servidores, cvs, banco etc), trabalhos solos além do expediente de trabalho.
- Dificuldades culturais em compartilhar conhecimento: São os famosos programadores “pano preto”, que por medo de perder sua zona de conforto que muitas vezes, possuem por normalmente serem os únicos que dominam determinado conhecimento acerca do projeto, não conseguem interagir de forma dinâmica e positiva com seus companheiros de trabalho.
- Grande vínculo com a cultura de desvio de atenção: Como falei anteriormente, isso às vezes está tão enraizado em nossa cultura, que é um verdadeiro “parto” tirar esses maus costumes, e isso, às vezes é algo que não acontece em curto prazo, o que sempre traz problemas para o início dos projetos que usam pair programming.
De uma maneira geral, esses problemas estão muito ligados à natureza individualista e senso de sobrevivência de nós seres humanos. Mas isso não necessariamente configura-se como um problema, pois se observarmos bem a fundo o segredo do sucesso da prática de pair programming, iremos ver que pelo fato de que, não gostamos de comprometermos nossa individualidade, sempre procuramos abreviar ao máximo o tempo em que fazemos algo junto de outras de pessoas, com isso:
- Damos mais atenção ao que estamos fazendo;
- Evitamos errar para que nossa imagem não fique comprometida perante o colega;
- Queremos de certa forma demonstrar nossa superioridade técnica em face ao de nossos colegas. Por isso, muitas vezes demonstramos nossas qualidades quando estamos sendo analisados pelos nossos colegas;
- E por fim, queremos sempre que necessário, acertarmos o que estamos fazendo logo na primeira vez, para evitar a necessidade de retrabalho, sobrando assim um tempinho para fazermos coisas dedicadas a nossa individualidade como ler e-mail, acessar MSN etc.
A Solução básica
Para terminar esse texto, afirmo a você que a prática de programação em par, quando bem aplicada, torna o desenvolvimento mais divertido, dinâmico e mais ágil, e gostaria de lembrar que a maioria dos casos de insucesso no uso de pair programming está associada ao não uso de outras práticas sugeridas por XP, principalmente pelas que são diretamente associadas à programação em par, como rodízio de pessoas, propriedade coletiva do código, padrões de projetos, e ritmo sustentável.
E isso é algo a ser olhado com muito carinho quando se tenta instanciar as práticas XP de forma modular, apesar de que devido a flexibilidade e dinamismo da metodologia, é importante sempre analisar quais práticas estão associadas entre si, pois caso você esqueça de usar alguma prática que seria fundamental para o sucesso de outra, as chances de fracassos como: atrasos, falta de aderência ao escopo, elevação do custo do projeto, aumentam muito.
Considerações finais
Termino esse artigo, convidando você a sentir-se tentado, a usar as práticas de Extreme Programming, e nos ajudar a divulgar, e evoluir seu uso. Espero sinceramente ter colaborado de maneira clara, não somente para a compreenssão do assunto, mas que esse artigo possa estimular uma profunda reflexão sobre o uso de extreme programming em projetos de desenvolvimento de software.
