Ele precisa ser uma combinação sensata de todas as respostas até agora. No final, quando você está falando sobre um grupo de pessoas inteligentes (desenvolvedores), precisa dar a eles razões pelas quais o comportamento é importante e dar a eles controle suficiente sobre como esse comportamento é implementado, para que sejam investidos em fazê-lo da maneira certa. Os mandatos de cima geralmente são frouxos com pessoas inteligentes, porque se eles não concordaram que o problema é um problema, é provável que passem mais tempo trabalhando no cumprimento do mandato do que seguindo a regra.
Aqui estão algumas das minhas táticas:
Confirmando alterações:
Primeiro, a equipe precisa concordar sobre quando cometer e o que cometer. Absolutamente essencial é uma configuração de compilação que faça sentido, para que as pessoas não fiquem esperando apenas porque não sabem onde colocar alguma coisa. E um consenso sobre quando / com que frequência o check-in. "Não interrompa a construção" é uma boa regra óbvia, mas como isso é verificado e quem é informado sobre isso? Outra linha de base é "isso não será feito se não estiver registrado".
A maioria dos desenvolvedores que conheço tem o prazer de verificar o código IF:
- O processo de check-in é fácil
- O processo de sincronização é fácil (considerando as alterações de outros desenvolvedores)
- É fácil ver mudanças e mover-se entre versões
Uma coisa que notei recentemente foi que os check-ins se tornaram mais frequentes e menos dolorosos quando avançamos para uma nova ferramenta de CM. Nossa equipe é pioneira no Rational Team Concert, tendo usado anteriormente o Clearcase. Não pretendo anunciar ferramentas, mas a nova onda (para mim) de streaming de check-ins com muitas pequenas fusões rápidas torna muito mais atraente o check-in antecipado e frequente.
Permitir que os desenvolvedores sejam responsáveis por eliminar a dor de CM geralmente aumenta a quantidade de check-in no que acontece.
Aderindo à arquitetura - Não gravando problemas de modelo em vistas e controladores
Estou colocando isso no grupo geral de "faça a arquitetura corretamente". Eu concordo com quem disse que as avaliações pelos pares - a pressão dos colegas é ótima para isso. Uma das maneiras pelas quais geralmente vejo as pessoas participarem das melhores práticas nessa área é quando seus colegas lhes perguntam por que o fizeram da outra maneira (da maneira não tão correta). Geralmente, a pergunta "por que" levará as pessoas a perceber por si mesmas por que deveriam ter feito isso de maneira diferente. Quando as pessoas têm um motivo bem entendido para a melhor prática, é muito mais fácil aderir a ela.
Além disso, se houver alguma formalidade em vincular uma pessoa a uma decisão, será mais fácil atribuir bugs nessa área ... portanto, se uma pessoa for responsável por corrigir bugs em uma área com design defeituoso, a necessidade de corrigir algo antes eles podem passar para algo novo e emocionante pode ser um grande motivador.
Evite codificação
Eu começaria com padrões claros de codificação e a integração de uma revisão de padrão de codificação nas revisões por pares. A codificação embutida é uma daquelas coisas que podem ser facilmente uma caixa de seleção na agenda de revisão por pares.
Receio que esse tipo de coisa seja a única coisa em que eu vi que se tornou o papel do líder da equipe para impor a regra. Nas equipes que eu administro, geralmente não deixamos alguém seguir em frente até que eles corrigam os comentários de uma revisão por pares de seu código. E "sem código rígido" é um comentário frequente de revisão por pares.
Em geral
Com quase todas as melhores práticas, acho que você deve escolher suas batalhas. Nenhuma equipe se tornará absolutamente perfeita. Mas você pode ficar de olho em seus principais pontos problemáticos e começar a enfrentá-los em grupos. Eu acho que se torna o papel do líder realmente saber o que é um ponto problemático para a equipe versus uma peculiaridade irritante de um indivíduo em particular.
Se sua equipe está perdendo uma prática recomendada específica, acho que a primeira pergunta deve ser "quanto dano isso está causando?" se a resposta for "mínima", provavelmente não vale a pena. Algumas práticas recomendadas são mais relevantes para tipos específicos de sistemas - embora sejam boas no geral, podem não valer a pena a batalha por sistemas em que a prática não é uma ocorrência frequente ou é uma parte importante do sistema.
Se a resposta para "quanto damange?" é "MUITO !!!", então você pode começar a criar um caso para mostrar à equipe que toda essa dor e sofrimento poderiam ser removidos, fixando esse ponto de folga nas melhores práticas. A maioria das pessoas fica feliz em evitar a dor e o sofrimento e isso muda o diálogo de "faça isso porque eu lhe disse", para um "decidimos fazer isso porque é melhor".