Como incentivar a adoção do controle de versão

Recentemente, comecei a trabalhar em uma equipe onde não há controle de versão. A maioria dos membros da equipe não está acostumada a nenhum tipo de controle de versão. Eu tenho usado o mercurial em particular para acompanhar meu trabalho. Gostaria de incentivar outras pessoas a adotá-lo e, no mínimo, começar a versão do código à medida que desenvolvem alterações. Alguém pode me dar conselhos sobre como incentivar a adoção de um controle de versão distribuído, como mercurial. Qualquer conselho sobre como conquistar pessoas, incluindo gerentes, para o DVCS seria muito apreciado.

Você precisa defender o uso do controle de versão e primeiro tentar vendê-lo a seus colegas de trabalho e, se isso falhar, suba a cadeia para projetar liderança e superior.

Para colegas engenheiros de software, seu caso deve se concentrar em como economiza tempo e dores de cabeça a longo prazo. Encontre horários de seu próprio passado ou histórias publicadas (blogs, artigos em revistas, white papers) sobre como o uso do controle de versão facilita sua vida. Se você foi queimado por não ter controle de versão, torne-o pessoal. Se seus colegas desenvolvedores estiveram na mesma situação, eles devem ver a luz e como essas ferramentas podem ajudá-los.

Esta é a sua melhor aposta. Embora eu não consiga encontrar a (s) fonte (s) no momento, li (em alguns lugares) que as mudanças mais efetivas no processo vêm dos desenvolvedores, que precisam lidar com as mudanças. Se você conseguir envolver os desenvolvedores, conseguirá duas coisas. Primeiro, você já tem o apoio das pessoas que serão impactadas pela mudança do processo. Segundo, há um grupo de pessoas para convencer a gerência de que este é um esforço que vale a pena e que melhorará o produto e o projeto.

No entanto, se você não conseguir o apoio da equipe de desenvolvimento e ainda se sentir incrivelmente forte com a implantação do controle de versão, poderá passar para o gerenciamento. Mas torna-se mais arriscado se você for sozinho, já que você não precisa apenas se preocupar em vender a melhoria, mas também lidar com a reação dos seus colegas.

Para projetar, programar e gerenciar a organização, é preciso saber como a implantação do controle de versão pode economizar tempo e dinheiro da organização. As pessoas nesse nível se preocupam com quanto dinheiro o projeto está custando, onde fica comparado às estimativas e assim por diante. Procure white papers, livros, artigos e outros documentos e publicações profissionais que expliquem como a implantação do controle de versão economizou tempo e dinheiro para outras organizações a longo prazo. Você também pode introduzir uma perspectiva de qualidade aqui, se sua organização estiver interessada em qualidade de software.

Você mencionou especificamente que deseja usar um sistema de controle de versão distribuído. Não force isso na garganta da equipe ou organização. Apresente-os ao controle de versão e suas opções. Embora você pessoalmente prefira usar um DVCS (como Mercurial), ele pode não ser o melhor para sua equipe e organização. O uso de uma ferramenta que se encaixa incorretamente só piorará a situação através da debulha.

Além disso, esteja ciente dos riscos de apresentar o processo com atraso . Embora o uso do controle de versão seja uma prática recomendada comumente aceita, pode ser tarde demais para introduzi-lo efetivamente no projeto atual sem um grande risco para a conclusão do projeto. Em vez disso, eu recomendaria um foco na melhoria do status quo para projetos e equipes futuros.

Além disso, esta é uma abordagem geral que você pode seguir para executar qualquer melhoria de processo ou tecnologia.

A primeira pergunta é: o que eles fazem atualmente? Certamente, cada desenvolvedor não tem o código-fonte preso em sua própria caixa que ele muda à vontade. Depois de ter o processo que eles seguem atualmente, você pode sugerir algumas ferramentas que aprimoram esse processo - geralmente um SCM é ideal para ajudá-los com isso, em vez de fazê-los seguir um processo diferente.

O ponto principal aqui é que, se eles têm uma maneira pseudo-SCM de trabalhar, talvez armazenando a versão atual em um servidor em algum lugar, é necessário determinar se um DVCS ou CVS é ​​mais apropriado, não tente vendê-los Mercurial se SVN é um ajuste melhor.

A maneira mais rápida é convencer a gerência de que ela é necessária.

Faça alguns cálculos:

Custo do software de controle de versão - gratuito.
Custo do hardware para suportar o repositório - um servidor.
Custo da implementação do software - alguns dias para uma equipe pequena, aumentando para equipes maiores.

Custo da não implementação do controle de versão:

Na melhor das hipóteses - os dias perdidos devido a edições ausentes, substituindo as alterações uns dos outros etc., erros recorrentes e assim por diante.
Na pior das hipóteses, por mais muitos anos que sua equipe tenha gasto até agora.

Este último número é o pior cenário de você perder todo o seu trabalho devido a falha do servidor, etc. O custo de bugs recorrentes pode ser maior, pois pode levar à perda de clientes.

A equipe de desenvolvimento também deve entender esses custos e, considerando que a maioria dos softwares de controle de versão (se não todos) se integra perfeitamente aos IDEs atualmente, eles nem percebem que está lá na maioria das vezes.

A gerência geralmente se preocupa mais com a economia de dinheiro. Enfatize como o controle de versão pode beneficiar financeiramente a equipe e você receberá sua atenção imediatamente!

Há um aspecto que outras pessoas aqui não abordaram que eu acho que você tem a seu alcance - você está falando sobre controle de versão distribuído - por sua própria natureza, você pode introduzi-lo em uma prática de fato, um desenvolvedor de uma vez. Com um controle de versão mais exigente, como o que usamos no meu escritório (MS Visual SourceSafe), você teria dificuldade em ir até o cara do cubo em frente ao meu e vendê-lo individualmente pelos méritos de controle de versão. No entanto, com (qualquer) DVCS, você pode simplesmente dizer "ei, tente isso e veja se você gosta. Eu mostrarei as cordas e ficarei feliz em responder a quaisquer perguntas, orientá-lo, blá, blá blá ". Dessa forma, você não precisa de um "processo" do alto, pode criar um mandato de base, uma pessoa de cada vez.

Aproveitando a resposta de gbjbaanb.

O principal aqui é que você deve adaptar o processo de controle de versão a qualquer processo existente e mostrar como ele economiza o restante do esforço da equipe.

Pessoalmente, também sou a favor do Mercurial, mas não necessariamente o imporia a pessoas não acostumadas ao controle de versão, porque é um pouco mais difícil de entender do que um sistema de controle de versão de bloqueio baseado em servidor à moda antiga. Dito isto, se é realmente um site de greenfields, talvez seja melhor ir a porcos inteiros, pular as décadas de 80 e 90 e usar a Mercurial. Também examinaria algumas das coisas do ciclo de vida de software de terceiros criadas em torno do Mercurial - tenho certeza de que há uma, mas o nome 'me escapa;)

Suponho que você trabalha para uma empresa pequena e que é relativamente novo para a equipe, por isso pode ser uma venda difícil - especialmente se o resto da equipe estiver entrincheirado e tiver a confiança da gerência. Talvez seja melhor deixá-los encher mal alguma coisa e depois vir ao resgate. Isso não significa sabotagem, apenas espere o inevitável.