Concordo com o Bruno Pereira no que diz respeito a ter tempo para fazer isso, mas se sobrar um tempinho na Sprint é uma ótima opção, ou até mesmo tirar uma história de vez em quando para a mesma em vez do próprio PP.

Muito bom o post, parabéns! (:

Seu coração, digo, artigo foi citado no Nungo: http://nungo.com.br/programacao/pair-programming-vs-code-review/ #…

Os defensores de TDD pregam a escrita dos testes unitários antes da implementação das funcionalidades de negócio. Teoricamente isso traz mais qualidade ao software.

Eu discordo desta alegação. Eu já desenvolvi muito software customizado, e milhares de testes unitários. Eu me sinto bastante seguro quanto à qualidade dos meus testes unitários, e quanto à cobertura dos mesmos sobre o código que desenvolvo.

Já tentei algumas vezes escrever os testes unitários no começo, mas simplesmente prefiro a abordagem de escrever os testes posteriormente, preferencialmente acompanhando o desenvolvimento das funcionalidades de negócio. Não vou dizer que estou certo ou errado, considero isso uma questão de gosto pessoal, e de avaliar o que te traz melhores resultados. Provavelmente muitos adeptos de TDD têm ganhos de qualidade ao usar essa abordagem, mas não vejo isso como um dogma a ser seguido.

Por outro lado, a questão do code review me parece muito subestimada. Eu acho o code review muito valioso quando você está trabalhando com coisas não tão triviais. Entretanto, revisões de código tomam um bom tempo, então não dá para fazer isso o tempo todo.

Quando eu ainda estava na Globo.com nós usamos uma abordagem que me agradou bastante. Tínhamos tarefas de desenvolvimento de funcionalidades e tarefas de testes unitários. Quando adotamos a regra de um desenvolvedor escrever os testes unitários de funcionalidades implementadas por outro desenvolvedor, com certeza ganhamos em qualidade. Este tempo dedicado à escrita dos testes unitários era aproveitado como revisão de código. O refactoring do código começava mais cedo e antecipávamos muitos problemas que possivelmente não seriam percebidos rapidamente pelo desenvolvedor original.

Pois bem, no final das contas a minha opinião é semelhante à sua. Devemos conhecer o que nos traz bons resultados e então aplicar essas idéias/práticas. O cliente final não quer saber das siglas que você aplicou no seu desenvolvimento, e nem quer saber detalhes das suas metodologias. Ele quer ser bem servido e ter qualidade. Cabe a nós julgar o que melhor funciona conosco e então fazer uso destes recursos.

[]s