Como disse no post anterior, práticas devem ser utilizadas para atingir os objetivos estabelecidos, seguindo os princípios desejados.

Você também deve ter em mente o contexto do projeto para saber qual prática vai ser mais ou menos eficiente em te ajudar a atingir os objetivos.

Desta forma fica difícil aceitar que existam best practices que são ótimas independente dos seus objetivos, princípios e contexto. Existem sim, boas práticas que devem ser selecionadas e adaptadas para a sua realidade.

Alguns exemplos:

Automatização de testes de aceitação - Esta é uma prática agile que vêem ganhando adeptos. Através de frameworks como o FitNesse é possível automatizar a validação de regras de negócios declaradas em planilhas ou wikis. Esta prática vai ao encontro de alguns princípios do Agile como satisfazer o cliente e manter a equipe motivada. O problema é que existem requisitos que podem ser facilmente descritos em uma planilha, outros não. Nestes casos você deverá buscar práticas alternativas que te ajudem a atingir estes princípios de forma mais eficiente.

Automatização de build - Esta prática diminui o trabalho mecânico, reduz o tempo de setup (um grande gerador de desperdício) e permite entregas mais rápidas. No entanto se for praticada sem automatização de testes e/ou um processo de teste contínuo perde muito seu valor. Tudo bem, eu posso a qualquer momento produzir um build rapidamente. Mas ele é bom? Foi testado? Então para que serve?

Perceberam que comentei somente práticas agile? Foi intencional porque não quero criticar a prática em sí, mas sim sua utilização sem consciência. Ou seja, qualquer prática, deve ser aplicada com um intuito e não porque está na lista de best practices de um livro ou porque está escrito em um processo escrito alguém que não tem a menor idéia de como é o seu projeto.

Como o Jeremy Miller colocou muito bem: seja seu próprio metodologista, porque Kent Beck, Ivar Jacobson ou a SEI não estão diretamente interessados no seu projeto. O seu é que está na reta!