É muito interessante notar a reação das pessoas quando tentamos introduzir a idéia da programação em par. A primeira reação, normalmente é:
Porque devo colocar duas pessoas para fazer o trabalho de uma?
Este argumento, em primeira vista válido, não passa de uma avaliação superficial do que realmente ocorre em um processo de desenvolvimento. A maioria das pessoas acredita que o processo de desenvolvimento seja, em sua essência, escrever código. Mas, não é. Na verdade, escrever código é a menor parcela neste processo. A maior atividade neste processo é pensar.
Quem já tem alguma vivência no mundo do desenvolvimento, sabe que quando colocamos a mão no código, já temos algo em mente que precisa ser implementado. Não estou me referindo a UML, análise antes de implementar ou waterfall. Antes de escrever qualquer linha de código você deve (ou deveria) saber porque está escrevendo aquilo, isto é, quais são seus objetivos. Antes de escrever essa primeira linha, você já tem uma idéia da lógica que será usada.
Nesse ponto, é possível provar a importância da programção em par, pois é onde temos o maior risco de decisões ruins e inserir erros. Estes erros irão custar tempo de desenvolvimento no futuro. E tempo é dinheiro.
O grande valor da programação em par está na possibilidade de pequenas correções de curso, e eliminação de erros logo assim que eles aparecem. Esses erros podem ser sutis e um overlook do par pode impedir que sigam adiante possibilitando, dessa forma, a correção prematura, permitindo a empresa economizar muito dinheiro com esforço em manutenções futuras.
O quanto é esse muito?
Quando estamos lidando com dinheiro, precisamos quantificar com precisão o que está envolvido. E, Dave Nicolette, fez isso de forma brilhante neste artigo, baseado em sua experiência. No artigo, ele mostra com números, a realidade de uma empresa que adota a programação em pares no seu dia-a-dia.
Sites relacionados:
InfoQ
Fala Celso! tudo beleza ? pois é rapaz esse tema é muito bom e aqui onde estamos utilizando esta prática de sempre trabalhar em pares (duplas). Inicialmente estranhei esta forma de se trabalhar pois achei que tendo um observador me deixaria pressionado, tenso e não renderia, mas, estou gostando muito desta forma de se organizar a equipe em duplas. Interagimos em tempo real e isto ajuda muito na troca de experiências, no compartilhamento de pensamentos sobre uma solução/arquitetura/forma de implementar já que no geral um sempre irá criticar o outro sempre se defender até chegar num senso comum de como deve ser feito (de forma construtiva claro -- Se fosse apenas um, cognitivamente, aconteceria de implementar a primeira solução). Além disto, como tudo está passando pelo crivo do "observador" com o tempo vamos nos sentindo mais confiantes no que fazemos. Um outro ponto bem legal é a redução de bugs e erros de arquitetura no projeto pois o "condutor" tem uma visão limitada enquanto implementa enquanto o "observador" consegue ter uma visão macro das coisas, e desta forma, atua como um navegador avisando o condutor dos possiveis "futuros" problemas. Em suma estou gostando de trabalhar em par e rende muito mais o trabalho. Muito bom a metrificação feita por Dave Nicolette.
ResponderExcluirTem um site muito legal sobre o programação em par: http://improveit.com.br/xp/praticas/programacao_par
Abraços!
Muito legal você estar vivendo esta experiência na prática. Acho que a maior questão nessa prática é o amadurecimento psicológico. Evitando guerras idiotas de vaidade, naturalmente produziremos discussões férteis, conseguindo caminhar para um denominador comum. Na nossa área, vemos muitos egos inflados e pessoas que odeiam estar erradas. É esse ódio que começa a gerar discussões infrutíferas, não levando o projeto a parte alguma.
ResponderExcluirMuito interessante o artigo.
Abraços.
Parabéns pelo post Celso, me ajudou bastante nas pesquisas ;)
ResponderExcluirAbraço.