Comment encourager l'adoption du contrôle de version

J'ai récemment commencé à travailler dans une équipe où il n'y a pas de contrôle de version. La plupart des membres de l'équipe ne sont habitués à aucun type de contrôle de version. J'utilise mercurial en privé pour suivre mon travail. Je voudrais encourager les autres à l'adopter et à tout le moins commencer à versionner leur code à mesure qu'ils développent des changements. Quelqu'un peut-il me donner des conseils sur la façon d'encourager l'adoption d'un contrôle de version distribué tel que mercurial. Tout conseil sur la façon de gagner des personnes, y compris des managers, au DVCS serait très apprécié.

Vous devez plaider en faveur de l'utilisation du contrôle de version et essayer d'abord de le vendre à vos collègues, et si cela échoue, remontez la chaîne pour diriger le projet et plus.

Pour les collègues ingénieurs logiciels, votre cas doit être axé sur la façon dont il permet d'économiser du temps et des maux de tête à long terme. Trouvez des moments de votre propre passé ou des articles publiés (blogs, articles dans des magazines, livres blancs) sur la façon dont l'utilisation du contrôle de version vous simplifie la vie. Si vous avez été brûlé en n'ayant pas de contrôle de version, personnalisez-le. Si vos collègues développeurs ont été dans la même situation, ils devraient voir la lumière et comment ces outils peuvent les aider.

C'est votre meilleur pari. Bien que je ne trouve pas la ou les sources pour le moment, j'ai lu (à quelques endroits) que les changements les plus efficaces à effectuer proviennent des développeurs, qui doivent gérer les changements. Si vous pouvez faire participer les développeurs, vous réalisez deux choses. Premièrement, vous avez déjà l'adhésion des personnes qui seront affectées par le changement de processus. Deuxièmement, il y a un groupe de personnes pour convaincre la direction que c'est un effort valable et qu'il améliorera le produit et le projet.

Cependant, si vous ne pouvez pas obtenir le support de l'équipe de développement et que vous vous sentez toujours extrêmement convaincu du déploiement du contrôle de version, vous pouvez passer à la gestion. Mais cela devient plus risqué si vous partez en solo, car vous devez non seulement vous soucier de vendre l'amélioration, mais également faire face aux contrecoups de vos collègues.

Pour la gestion de projet, de programme et d'organisation, il faut voir comment le déploiement du contrôle de version peut faire gagner du temps et de l'argent à l'organisation. Les gens à ce niveau se soucient du montant que coûte le projet, de sa position par rapport aux estimations, etc. Recherchez des livres blancs, des livres, des articles et d'autres documents et publications professionnels qui expliquent comment le déploiement du contrôle de version a fait gagner du temps et de l'argent à d'autres organisations à long terme. Vous pouvez également introduire une perspective de qualité ici, si votre organisation est intéressée par la qualité des logiciels.

Vous avez spécifiquement mentionné que vous souhaitez utiliser un système de contrôle de version distribué. Ne forcez pas cela dans la gorge de l'équipe ou de l'organisation. Présentez-leur le contrôle de version et leurs options. Bien que vous préfériez personnellement utiliser un DVCS (comme Mercurial), il pourrait ne pas être le mieux adapté à votre équipe et à votre organisation. L'utilisation d'un outil qui ne convient pas ne fera qu'empirer les choses grâce à la raclée.

Soyez également conscient des risques d'introduire le processus tardivement . Bien que l'utilisation du contrôle de version soit une bonne pratique communément acceptée, il pourrait être trop tard pour l'introduire efficacement dans le projet en cours sans risque énorme pour l'achèvement du projet. Au lieu de cela, je recommanderais de mettre l'accent sur l'amélioration du statu quo pour les futurs projets et équipes.

Il s'agit également d'une approche générale que vous pouvez suivre pour effectuer des améliorations de processus ou de technologie.

La première question est: que font-ils actuellement? Certes, chaque développeur n'a pas le code source coincé dans sa propre boîte qu'il modifie à volonté. Une fois que vous avez le processus qu'ils suivent actuellement, vous pouvez suggérer des outils qui améliorent ce processus - généralement un SCM est idéal pour les aider, plutôt que de leur faire suivre un processus différent.

Le point principal ici est, s'ils ont une façon de travailler pseudo-SCM, peut-être de stocker la version actuelle sur un serveur quelque part, alors vous devez déterminer si un DVCS ou un CVS est plus approprié, n'essayez pas de les vendre Mercurial si SVN est un meilleur ajustement.

Le moyen le plus rapide est de convaincre la direction que cela est nécessaire.

Faites quelques calculs:

Coût du logiciel de contrôle de version - gratuit.
Coût du matériel pour prendre en charge le référentiel - un serveur.
Coût de mise en œuvre du logiciel - quelques jours-homme pour une petite équipe, en hausse pour les grandes équipes.

Coût de la non mise en œuvre du contrôle de version:

Meilleur cas - jours perdus en raison de modifications manquantes, d'écrasements mutuels, etc., de bogues récurrents, etc.
Le pire des cas - quelle que soit la durée des années d'efforts consacrés à votre équipe jusqu'à présent.

Ce dernier chiffre est le pire des cas où vous perdez tout votre travail en raison d'une panne de serveur, etc., mais même les meilleurs scénarios devraient leur expliquer pourquoi cela est nécessaire. Le coût des bogues récurrents pourrait être plus élevé car cela pourrait entraîner la perte de clients.

L'équipe de développement doit également comprendre ces coûts et étant donné que la plupart (sinon la totalité) des logiciels de contrôle de version s'intègrent parfaitement aux IDE de nos jours, ils ne remarqueront même pas qu'il est là la plupart du temps.

La direction se soucie généralement plus d'économiser de l'argent. Insistez sur la façon dont le contrôle de version peut bénéficier financièrement à l'équipe et vous obtiendrez leur attention immédiatement!

Il y a un aspect que d'autres personnes ici n'ont pas abordé que je pense que vous avez dans votre coin - vous parlez de contrôle de version distribué - par sa nature même, vous pouvez le glisser dans une pratique de facto, un développeur à la fois. Avec un contrôle de version plus étouffant, comme ce que nous utilisons dans mon bureau (MS Visual SourceSafe), vous auriez du mal à aller voir le gars dans le cube en face du mien et à le vendre, face à face sur le fond de contrôle de version. Cependant, avec (n'importe quel) DVCS, vous pouvez simplement dire "hé, essayez ceci, et voyez si vous l'aimez. Je vais vous montrer les cordes, et je serais heureux de répondre à toutes les questions, de vous guider, bla bla blabla". De cette façon, vous n'avez pas besoin d'un "processus" d'en bas, vous pouvez construire un mandat de base, une personne à la fois.

S'appuyant sur la réponse de gbjbaanb.

L'essentiel ici est d'adapter le processus de contrôle de version à tout processus existant et de montrer comment il économise le reste de l'effort d'équipe.

Personnellement, je privilégie également Mercurial, mais je ne voudrais pas nécessairement l'imposer à des personnes peu habituées au contrôle de version, car il est un peu plus difficile à comprendre qu'un système de contrôle de version à verrouillage basé sur un serveur à l'ancienne. Cela dit, si c'est un véritable site greenfields, il vaut peut-être mieux aller tout le porc, sauter les années 80 et 90 et aller avec Mercurial. Je regarderais également certains des trucs du cycle de vie des logiciels tiers construits autour de Mercurial - je suis sûr qu'il y en a un mais son nom m'échappe;)

Je suppose que vous travaillez pour une petite entreprise et que vous êtes relativement nouveau dans l'équipe, donc cela pourrait être difficile à vendre - surtout si le reste de l'équipe est bien établi et a la confiance de la direction. Peut-être serait-il préférable de leur laisser quelque chose de mal, puis de venir à la rescousse. Cela ne signifie pas le sabotage, attendez juste l'inévitable.