A questão é que, para se compreender a prática de verdade, é preciso primeiro acreditar nela.
O pensamento mais imediato, claro, é sempre imaginar que se gasta o dobro para realizar a mesma tarefa. Esse pensamento não está certo. Porque a programação é uma tarefa criativa e não respeita à lei "quanto mais gente, mais trabalho se realiza". Nesse caso, a qualidade do código produzido interfere muito na produtividade dos próximos passos. Então vale muito mais a pena "gastar" o dobro da atenção sobre cada parte dele.
Não é fácil argumentar sobre isso, nem é esse o meu propósito aqui. Quem já experimentou programação em par "na veia" vê isso com uma clareza impressionante. Mas pra quem está iniciando, acreditar nisso não é tão natural.
Quanto mais se acredita, melhor se pratica. Quanto melhor se pratica, mais se acredita. Mais um ciclo virtuoso que costuma estar presente em XP.
Aqui está um screencast muito interessante pela própria "inovação tecnológica" da idéia. Mais interessante ainda pela forma como consegue expor uma seção de programação em par tão de perto. Quase que se participa dela. Impressionante!
(Sugestão: assista em full-screen)
Cola: Real-Time Shared Editing from Mustafa K. Isik on Vimeo.
A programação em par, quando acontece fluida, assemelha-se muito a uma conversa, ou uma seção de design, onde se discute a modelagem do sistema com papel e lápis. Se a programação for guiada por testes ainda por cima, aí é que a coisa fica bonita!
Alguém se habilita pra gravar algumas seções com foco mais metodológico que tecnológico, usando TDD, BDD, etc.?
Eu acredito na programação em par, mas acredito que a eficiência desta técnica depende do sincronismo do par, e da habilidade de ceder a opinião alheia. Mas é isso, o mais difícil sempre será trabalhar em equipe.
ResponderExcluir