Como convencer os programadores de cowboys a usar o controle de origem?

ATUALIZAÇÃO
Eu trabalho em uma pequena equipe de desenvolvedores, 4 caras. Todos eles usaram o controle de origem. A maioria deles não suporta o controle de origem e prefere não usá-lo. Eu acredito firmemente que o controle de fontes é uma parte necessária do desenvolvimento profissional. Vários problemas tornam muito difícil convencê-los a usar o controle de origem:

• A equipe não está acostumada a usar o TFS . Eu tive duas sessões de treinamento, mas só foram distribuídas 1 hora, o que é insuficiente.
• Os membros da equipe modificam diretamente o código no servidor. Isso mantém o código fora de sincronia. Exigindo comparação apenas para garantir que você esteja trabalhando com o código mais recente. Surgem problemas complexos de mesclagem
• As estimativas de tempo oferecidas pelos desenvolvedores excluem o tempo necessário para corrigir qualquer um desses problemas. Então, se eu disser não, levará 10 vezes mais ... Eu tenho que explicar constantemente esses problemas e me arriscar, porque agora a gerência pode me perceber como "lenta".
• Os arquivos físicos no servidor diferem de maneiras desconhecidas em mais de 100 arquivos. A fusão requer conhecimento do projeto em questão e, portanto, cooperação do desenvolvedor que não sou capaz de obter.
• Outros projetos estão ficando fora de sincronia. Os desenvolvedores continuam desconfiando do controle de origem e, portanto, agravam o problema ao não usar o controle de origem.
• Os desenvolvedores argumentam que o uso do controle de origem é um desperdício, porque a fusão é propensa a erros e difícil. Este é um ponto difícil de argumentar, porque quando o controle de origem está sendo tão mal usado e o controle de fonte é continuamente ignorado, ele é propenso a erros. Portanto, a evidência "fala por si" na opinião deles.
• Os desenvolvedores argumentam que a modificação direta do código do servidor, ignorando o TFS, economiza tempo. Isso também é difícil de argumentar. Porque a mesclagem necessária para sincronizar o código para começar é demorada. Multiplique isso pelos mais de 10 projetos que gerenciamos.
• Os arquivos permanentes geralmente são armazenados no mesmo diretório do projeto da web. Portanto, a publicação (publicação completa) apaga esses arquivos que não estão no controle de origem. Isso também gera desconfiança pelo controle da fonte. Porque "a publicação interrompe o projeto". A correção (remoção de arquivos armazenados das subpastas da solução) leva muito tempo e depuração, pois esses locais não são definidos no web.config e geralmente existem em vários pontos de código.

Então, a cultura persiste. Má prática gera mais má prática. Soluções ruins levam novos hacks a "consertar" problemas muito mais profundos e que consomem muito mais tempo. Servidores, o espaço no disco rígido é extremamente difícil de encontrar. No entanto, as expectativas dos usuários estão aumentando.

O que pode ser feito nessa situação?

Não é uma questão de treinamento, é uma questão de fatores humanos. Eles não querem e estão criando bloqueios de estradas. Lide com a dinâmica de grupo interrompida, qual é a causa raiz de sua objeção - geralmente o medo, é apenas o medo da mudança ou é mais sinistro.

Atualmente, nenhum desenvolvedor profissional, ou nos últimos 20 anos, resistiu ao controle de fontes. Uma vez, cerca de 30 ou 40 anos atrás, quando os computadores eram lentos, o controle de origem ainda mais lento e os programas consistiam em um arquivo de 500 linhas, era uma dor e havia razões válidas para não usá-lo. Essas objeções só podem vir do pior tipo de cowboy em que consigo pensar.

O sistema é forçado a dificultar suas vidas de alguma maneira? Descubra o que é e altere o sistema para invalidar a objeção. Repita até terminar.

Sugiro olhar para o GIT ou Mercurial. Você pode criar um repositório em cada árvore de código-fonte, eles nem perceberão e continuarão hackeando da maneira que fazem agora. Você pode acompanhar as alterações que eles invadiram na base de código, fazer confirmações, mesclá-las em outras árvores de origem, etc. Quando você reverte um de seus erros com um comando e salva a bunda deles, eles podem até agradecer (não conte com isso). Na pior das hipóteses, você fica bem na frente do chefe e, para um bônus, faz com que pareçam os cowboys que são.

A fusão levaria não apenas um grande conhecimento do projeto

Nesse caso, receio que você esteja no riacho proverbial sem remo. Se a mesclagem não for uma opção, nem a implementará, você estará dizendo que não poderá mais adicionar recursos que já possui em uma ramificação (termo usado livremente) a outra.

Se eu fosse você, reconsideraria minhas perspectivas de carreira ...

Às vezes, problemas do mundo real tornam impraticável o uso.

Falso.

Se a equipe não estiver acostumada a usar o controle de origem, poderão surgir problemas de treinamento

Isso não tem nada a ver com o controle do código-fonte e tudo a ver com o treinamento. O treinamento é fácil, barato, eficiente e realizado em questão de horas. Deixar de usar o controle do código-fonte é caro, arriscado, ineficiente e os problemas persistem para sempre .

Se um membro da equipe modificar diretamente o código no servidor, vários problemas poderão surgir.

Essa é a questão do treinamento. Novamente. Nada a ver com o controle do código fonte e tudo a ver com o treinamento.

Os desenvolvedores continuam desconfiando do controle de origem e, portanto, agravam o problema ao não usar o controle de origem

Eles precisam ser treinados em como usar o controle do código-fonte. Reduz custos, reduz riscos, simplifica as coisas e é mais eficiente. É um investimento único que paga dividendos a cada momento.

O que pode ser feito nesse tipo de situação?

Comece a treinar todos sobre como usar o controle do código-fonte.

Atualizar

Os desenvolvedores argumentam que modificar diretamente o controle de origem economiza tempo.

Como eles estão errados, é importante coletar dados para demonstrar com precisão o quão errado isso é.

Infelizmente, no entanto, a gerência parece recompensar uma resposta imediata que é cara a longo prazo.

A única maneira de superar esse sistema de recompensa é

A) Identifique que o custo de longo prazo é superior ao valor aparente de curto prazo.

B) Identifique as recompensas reais existentes que fazem com que a corrupção de curto prazo (ou seja, mudanças diretas) pareça mais valiosa do que o controle de código-fonte correto a longo prazo. Quem leva um tapinha na cabeça por fazer a coisa errada? Que tipo de tapinha na cabeça eles recebem? Quem dá? Para consertar as coisas, você deve nomear as que estão erradas e o (s) gerente (s) específico (s) que estão incentivando (as) as pessoas.

C) Recomende um sistema de recompensa revisado que valorize o valor a longo prazo em vez da resposta rápida a curto prazo. Diferentes tapinhas na cabeça por diferentes razões.

D) Treine as pessoas nas recompensas que encontrou por valor a longo prazo; valor claramente superior à resposta rápida de curto prazo.

Os desenvolvedores que se recusarem a usar o controle de fonte / versão devem ser demitidos, simples assim. Como você já apontou, os riscos e custos inerentes ao NÃO usá-lo superam qualquer custo adicional incorrido por muitas, muitas ordens de magnitude. Qualquer pessoa que tente argumentar contra isso simplesmente não deve se envolver no desenvolvimento de software e eu me recusaria a trabalhar com essas pessoas.

Resolvemos o problema primeiro, configurando um servidor de integração contínua para criar nosso controle de origem no dev. Segundo, bloqueie o acesso à pasta como somente leitura, para impedir que as pessoas contornem o controle de origem e modifiquem arquivos diretamente.

É uma PITA nos dias em que você não pode reproduzir o bug localmente, mas, além disso, é melhor poder trabalhar, fazer check-in e seguir em frente, sabendo que será empurrado para o dev automaticamente pelo servidor de CI.

Eu ouço sua dor. Entrei em alguns locais de trabalho para descobrir que o 'controle de origem' era uma pasta compartilhada em uma unidade de rede. O problema geralmente não é porque eles acreditam que a abordagem é superior a qualquer outra coisa, simplesmente funciona e eles nunca foram introduzidos em um fluxo de trabalho que integra com sucesso o controle de origem.

Com a estrutura da equipe de terra plana, você explicou que receber as alterações de cima para baixo pode não ser a melhor maneira de abordar a situação. Um método que vale a pena tentar é comprar diretamente de um ou dois dos outros desenvolvedores para permitir que o conceito ganhe impulso. Depois que você tiver um outro desenvolvedor a bordo, será muito mais fácil espalhá-lo para o restante da equipe. Apresente-os lentamente ao conceito, digamos, comece a trabalhar em um pequeno projeto paralelo, desenvolva-o e comece a trabalhar no Git ou até mesmo ramifique algo hospedado no GitHub .

Comece simples, apresente os conceitos lenta e separadamente do fluxo de trabalho do dia a dia. Os seres humanos são ótimos em aprender coisas e se adaptar às mudanças, especialmente quando essas mudanças lhes trazem benefícios diretos (pense na evolução). No entanto, quando apresentado com um monte de pequenas mudanças ao mesmo tempo, torna-se alienante. Depois que eles tiverem uma idéia de como o controle de origem funciona e as vantagens que ele oferece, tente integrá-lo em um de seu projeto interno (se você iniciar um novo projeto, será um momento terrível para apresentá-lo). Deixe que os outros projetos funcionem da maneira existente, se você preferir, isso será especialmente eficaz para destacar as vantagens do controle de código decente.

Se isso falhar, execute.

Você obviamente possui as habilidades técnicas para identificar e corrigir sua situação, seus problemas são humanos e relacionados ao processo.

As pessoas tendem a responder muito melhor ao exemplo do que à visão, então eu sugiro "consertar" você mesmo:

Pegue uma cópia da fonte mais recente, reestruture-a para que seja compatível com o controle de versão, crie um novo projeto com uma estrutura útil e voltada para o futuro (saiba como você vai lidar com as ramificações, onde você coloca dependências de terceiros etc.). Você provavelmente terá que fazer isso no seu próprio tempo.

Em seguida, arraste seus colegas de trabalho e gerenciamento para uma sala e mostre a eles como é o desenvolvimento de software no século XXI. Ilustre as falhas com seu sistema atual e mostre como elas são eliminadas com sua nova estrutura.

Você também terá que se estabelecer como o Guardião da Fonte - já que parece ser o único que se importa, cabe a você forçar as pessoas (com quaisquer meios técnicos ou psicológicos à sua disposição) a seguir o plano. Verifique se a única coisa que vai para o cliente é proveniente de uma máquina de construção fora do controle de origem. Humilhe as pessoas que quebram as regras e causam estragos. Suborná-los com rosquinhas ... o que funcionar.

Se tudo isso parece muito esforço, então (como já foi dito em quase todas as outras respostas) - arranje outro emprego. Eles não valem o seu tempo.

Etapa 1 - demitir gerente incompetente!

Se você não puder executar a etapa 1, tente fazer com que o gerente limite a implantação para produzir apenas scripts que são retirados do controle de origem. Se os desenvolvedores (que não devem ter direitos de produção no prod, consulte a etapa 1, se quiserem) desejam que suas coisas sejam implantadas, isso deve vir do controle de origem. Isso resolveu nosso problema de não usar o controle de origem bastante bem quando passamos a usá-lo para coisas de banco de dados e também para código C #.

Como alguém pode não querer versões diferentes de seus arquivos e a capacidade de ver as diferenças? Esqueça as ramificações e qualquer coisa complexa. Eles nem entendem o básico. Modificar diretamente um arquivo de produção sem fazer as alterações mais rudimentares em um ambiente de teste é insano. Trabalhei com algumas pessoas e, felizmente, nunca trabalhamos nos mesmos projetos.

Seus colegas de trabalho são burros demais para serem preguiçosos. Isso é uma perda de tempo. Tudo o que você pode esperar é treinar seu gerente. A gerência deve gostar do controle de origem porque gosta de todas as formas de controle. Faz com que se sintam importantes. Dane-se os outros; consertar o líder é sua única esperança, já que você não pode substituí-lo. Comece a trabalhar em rede com outros desenvolvedores competentes e tente fazer com que eles se juntem à sua equipe quando você tiver uma vaga ou faça com que eles o contratem na loja deles.

Este é um bom exemplo de um projeto em que práticas ruins foram usadas de maneira tão difundida que se torna praticamente impossível corrigi-las. Consertá-lo exigiria um congelamento, para que tudo possa ser limpo sem interrupção. Infelizmente, esses projetos geralmente são (por razões óbvias) muito problemáticos para serem congelados por vários meses; erros críticos devem ser corrigidos a cada dois dias.

Você pode ficar tentado a bifurcar o projeto para criar uma versão limpa enquanto a versão suja é tratada com essas correções diárias; mas o resultado mais provável é que, após vários meses, quando a versão "limpa" estiver concluída, ninguém poderá dizer quais correções e alterações foram incorporadas desde o fork (porque a mesma mentalidade que permite que as pessoas sigam essas práticas torna improvável que eles mantêm registros sobre as alterações que fazem). A versão limpa está desatualizada, a versão suja ainda meio que funciona, então o que acontece? A versão limpa é despejada, o que diz o contrário.

Além do óbvio Encontre um novo emprego, acho que a resposta é mais do que acima.

Primeiro, vá para o gerenciamento para integrá-los na mudança e no uso do controle de origem. Em seguida, faça o que precisa ser feito para manter as coisas funcionando, mesmo que isso signifique trabalhar diretamente no servidor. Inicie o processo de obter tudo no controle de origem.

Outra opção é garantir que o mais recente esteja no servidor (o que você precisa fazer independentemente) e iniciar um novo repositório completamente a partir do mais recente. Você vai perder a história, mas neste momento são batatas pequenas.

Parece pela sua descrição que há um ou mais problemas com a situação - a equipe de desenvolvimento está fora de controle ou uma solução de controle de origem ruim foi implementada. De qualquer forma, cabe à equipe de desenvolvimento usar alguma solução de controle de origem - a modificação direta do código-fonte no serviço de produção está implorando por problemas.

Pela minha experiência, o primeiro passo que deve ocorrer imediatamente é sincronizar o controle de origem com o servidor de produção. Essa etapa pode ser tão simples quanto tirar uma cópia do código de produção e fazer o check-in - o código do produto é provavelmente a base que sua equipe está desenvolvendo. Essa etapa pode precisar ser aumentada por uma mesclagem com o código que está flutuando no sistema de controle de origem existente. O código deve fluir do dev para a integração / controle de qualidade (ou ambos) e depois para o estágio ou estágio / produção.

Em seguida, o gerenciamento precisa determinar o uso do controle de origem. Simplesmente, se a construção não veio do sistema de controle de origem, o código não deve ser implantado na produção. O acesso à produção precisa ser limitado apenas à equipe de suporte, com acesso limitado ao dev para solucionar problemas de produção. Os desenvolvedores geralmente nunca devem fazer implantações quentes de código na produção - problemas de produção podem definitivamente acontecer, principalmente se os desenvolvedores estiverem sob pressão.

Definitivamente, o gerenciamento precisa lidar melhor com os problemas aqui - será quase impossível sustentar o desenvolvimento se o código for aplicado diretamente ao produto (e não entrar no controle de origem).

O verdadeiro problema não é que os codificadores cowboys não usem controle de versão. O verdadeiro problema é que eles já escolheram alguma maneira de fazer as coisas e você está tentando mudar o processo deles. O processo escolhido não inclui controle de versão. Todas as alterações no processo são difíceis, a menos que os próprios programadores percebam um problema. Se houver a sensação de que o sistema existente é bom o suficiente, tentar impor algum sistema diferente é inútil. Nós somos os borg, você será assimilado. Claro que eles estão tentando lutar para se tornar borg.

Para sua própria sanidade, sugiro configurar o Git ou outro DVCS em sua própria máquina para que você possa acompanhar as alterações. Importe frequentemente as alterações de seus colegas de trabalho para o seu repositório. Resolva os conflitos da melhor maneira possível. Isso o protegerá parcialmente da loucura de seus colegas de trabalho.

Você mencionou que o gerenciamento disse que os desenvolvedores devem usar o controle de origem. Se você quer ser mau, pode aplicar isso verificando as alterações no TFS e publicando periodicamente o repositório, eliminando assim as alterações que não estão no TFS. (Se você também estiver mantendo seu próprio DVCS, mantenha os dois sincronizados.) Sua justificativa para isso é que você está seguindo ordens da gerência. Se seus colegas de trabalho se cansarem de substituir suas alterações, convide-os a usar o TFS. E mantenha as mudanças que ainda não foram registradas. Continue até que seus colegas cedam ou sejam demitidos.

Bloqueie qualquer servidor que não seja o seu desenvolvimento. Use um gerenciador de configuração. Faça builds identificáveis ​​regulares (contra tags). Identifique todos os conjuntos de alterações (ou seja, 1 conjunto de alterações por bug). Também colocamos uma tag em cada build. Tenha um sistema do tipo QA entre o desenvolvedor e a produção (no mínimo). Constrói no sistema de controle de qualidade usando a tag de construção correta. Dê-lhes pesar por "quebrar a construção".

Nunca me deparei com uma situação em que não pudesse recriar / corrigir um problema (que só aparece na produção). Sim, passei horas tentando recriar o problema em um sistema de desenvolvimento (além disso, quando você descobrir, poderá adicioná-lo ao seu teste de regressão).

Fizemos um projeto com um monte de empreiteiros de cowboys que fizeram todas essas coisas ruins. Passei quatro semanas limpando depois e depois coloquei as práticas acima. O projeto não teve problemas com nenhuma dessas coisas desde então.

Citar:

A equipe não está acostumada a usar o TFS

O TFS acaba sendo o Microsoft Team Foundation Server.

Meu primeiro instinto diz: "esta é a versão mais recente do Microsoft Visual SourceSafe"

Eu estaria do seu lado, colegas de trabalho e seria realmente contra isso.