Comment convaincre un coéquipier, qui se voit comme senior, d'apprendre les bases conceptuelles du SVN? [fermé]

Pour commencer avec quelques antécédents, j’ai pris un nouveau poste de développeur cet été et j’ai été le membre le plus récent de l’équipe, mais avec la plupart de l’expérience acquise.

Jusqu'à présent, j'ai réussi à faire passer les initiatives de santé mentale assez facilement en raison des faibles coûts d'adoption (en termes de temps et d'effort). Cependant, les choses se sont un peu améliorées.

Un de mes coéquipiers, bien qu'expérimenté, ne comprend pas vraiment le SVN. Naturellement, les zones vierges de sa carte mentale illustrant les océans de SVN le poussent à adopter des schémas d'utilisation plutôt étranges.

Par exemple, il avait déclaré une stratégie de "1 validation SVN par jour et par développeur", faute de quoi "le serveur manquerait bientôt d'espace disque". Quand je lui ai expliqué que les commits SVN étaient des deltas et non des copies complètes, il a répondu avec un doute et même aujourd'hui, je ne suis pas tout à fait sûr qu'il comprenne ce que cela signifie.

Nous avons également eu un débat passionné sur l'opportunité d'inclure la .projectconfiguration Eclipse dans SVN. Mon coéquipier a insisté pour que nous le fassions, même si cela a provoqué de nombreux conflits inutiles. J'étais contre le maintien de fichiers de configuration de développeur individuels dans SVN. Finalement, il s'est avéré que mon coéquipier avait l'habitude de revérifier l'intégralité de l'arborescence source après chaque validation pour s'assurer simplement que "le code validé dans le référentiel fonctionne". C’est la raison pour laquelle il a tellement insisté pour conserver la configuration du projet dans SVN - il serait donc facile de réimporter le projet. Quand j'ai expliqué que commit synchronisait la copie de travail sur un octet à distance distant, ce qui rendait inutile le re-check-check, mon coéquipier a de nouveau douté et a finalement écarté le problème dans son ensemble comme insignifiant.

À mon avis, notre équipe perd du temps en résolvant les conflits SVN dans les fichiers de configuration de projet qui ne contiennent que des paramètres spécifiques au développeur qui n'ont pas besoin d'être partagés avec SCM. Tout ce gâchis parce que quelqu'un a adapté le processus autour d'hypothèses incorrectes.

Comment puis-je convaincre un coéquipier, qui se considère comme senior, de mieux comprendre les bases du SVN?

OMI, il est préférable de séparer les problèmes qui causent des problèmes directs / nuire au projet de ceux qui affectent uniquement ce développeur . Par exemple, s'il préfère tout contrôler plusieurs fois par jour, cela le ralentira, mais n'affectera pas les autres. Donc, vous pouvez simplement le laisser faire (jusqu'à ce qu'il y ait un retard de performance notable dans son travail), et vous épargner la peine de vous disputer à ce sujet.

Parmi les autres problèmes que vous avez mentionnés, tels que la conservation des .projectfichiers Eclipse dans le référentiel ou un engagement par jour, vous devez vous concentrer, pour permettre à l’équipe de progresser aussi facilement que possible. Tout d’abord, vous devriez demander / recueillir les commentaires des autres membres de l’équipe , si cela leur pose également des problèmes. S'il y en a d'autres, ensemble, vous pouvez exercer plus de pression et, si nécessaire, faciliter l'escalade du problème vers la direction.

En ce qui concerne "le SVN manque d'espace disque", il serait facile de réfuter ses convictions en faisant une expérience (potentiellement dans un référentiel test séparé). Il vous suffit de surveiller la taille de la hiérarchie physique des fichiers repo avant et après la validation des modifications dans un fichier texte énorme, voire plusieurs fichiers. Si cela ne le convainc pas, rien ne le peut.

Dans ce cas, malheureusement, vous avez probablement un problème d’autorité, dans lequel l’autre homme voit l’acceptation des conseils d’une personne «de rang inférieur» comme une perte de sa dignité. De tels conflits ne peuvent pas être résolus par un argument logique. Vous devez l'escalader vers la direction, mais veillez à avoir suffisamment de soutien (de la part de vos coéquipiers et / ou de la direction) avant de le faire. Une telle démarche peut être perçue par l’autre personne comme une attaque ouverte et peut donc avoir des conséquences problématiques (pour l’un de vous et / ou pour la paix de l’ensemble de l’équipe). Alors réfléchissez à trois fois et discutez-en avec vos collègues avant de prendre cette décision.

Si votre entreprise utilise un wiki, écrivez quelques articles de haute qualité sur SVN:

• Pourquoi devriez-vous l'utiliser?
• Quand devriez-vous l'utiliser?
• Quels problèmes cela résout-il?

etc.

CTO attirera l'attention, et tous ceux qui refusent d'utiliser devront utiliser :)

En tant que leader, manager et membre de l'équipe, j'ai eu à résoudre des conflits professionnels et de personnalité à plusieurs niveaux. Quel que soit le rôle dans lequel je suis engagé, je suis généralement accepté comme chef même si je ne le souhaite pas. La raison en est la façon dont je gère ces conflits.

Contrairement à beaucoup de gens ici, je ne suis pas d'accord pour dire que traiter avec cette situation est un "abandon" ou "lui montrer un nouvel outil" ou "attendre qu'il tombe sur le dos ou disparaisse". Plus important encore, ce n'est jamais une bonne idée d' attendre que les rôles soient définis plus fermement. Ces rôles sont définis par des personnes qui n'attendent pas, par leurs convictions, leur éthique et leur capacité à faire face à des situations critiques, qu'elles impliquent des personnes ou non.

Il existe plusieurs méthodes pour traiter le type de personne que vous décrivez dans ces situations. La première étape consiste à déterminer pourquoi il se comporte comme il est. Cela a peu à voir avec ce qu'il sait ou ne sait pas. Il aurait facilement pu trouver cette information auparavant, alors la question est vraiment l'une des deux choses: "Pourquoi ne l'a-t-il pas fait?" ou "Pourquoi rejette-t-il les informations qui lui sont fournies?" Cela vous aidera à trouver exactement ce qui doit être traité.

D'après mon expérience, les programmeurs (y compris moi-même) refusent les bonnes pratiques ou les nouveaux outils pour quelques raisons seulement:

• La source n'est pas crédible. Dans une industrie de plus en plus polarisée chaque jour entre le "culte de Mac" et les "adorateurs de la SEP"; entre "Idéologie Open Source" et "Caractère pratique" ... etc etc. - Nombreux sont ceux qui doutent toujours des informations fournies et de leur potentiel de corruption en raison du parti pris de l'auteur ou de l'auteur, même lorsque ces informations sont vérifié comme crédible.
• De mauvaises expériences prolongées ... avec une technologie ou une pratique similaire, voire identique. Rien n’est parfait au début, et beaucoup commencent avec moins d’un quart des fonctionnalités dont ils disposent. Il est tout à fait possible qu’il ait travaillé de nombreuses heures, voire plusieurs jours, voire plusieurs semaines, avec un produit de qualité inférieure ou le même produit au cours d’une phase de mauvaise mise en œuvre.
• Une source "crédible" ... est en conflit avec les informations qu'il présente. Par "crédible", j'entends une personne ou une entité à laquelle il fait confiance. Beaucoup de gens ont tendance à élever les personnes en qui nous avons confiance à des niveaux qui ne représentent pas la réalité. Cette source n'a même pas besoin d'avoir imposé cette croyance à la personne. Le plus souvent, nous le faisons nous-mêmes. Cela nous donne souvent quelque chose ou quelqu'un à qui aspirer à être, dans au moins un aspect.
• Manque de sécurité Cela a été souligné par une affiche précédente. Nos programmes deviennent des atouts à partir du moment où nous commençons à y travailler. Pas seulement pour les entreprises pour lesquelles nous travaillons, mais pour les personnes avec qui nous travaillons. Ce n'est pas simplement un problème de contrôle. Certains d'entre nous veulent être en mesure de montrer leur contenu aux personnes qui nous tiennent à cœur. Certains d’entre nous veulent s’assurer qu’une personne ou un produit extérieur ne leur nuira pas. Pour certains, c'est une extension de ce que nous pensons et ressentons, même. Il abrite certaines de nos philosophies et idéologies et expose nos cœurs intellectuels. Pour beaucoup, c'est notre avenir, que ce soit pour une classe, un employeur ou un client. Pour certains, ce sont tous ceux-là. La "sécurité" dans ce sens ne s'applique pas nécessairement aux données, ni au code.

Il est souvent très facile de savoir quel est le facteur. Obtenez la personne dans un cadre neutre. Expliquez à la personne ce que vous observez, en général. Demandez honnêtement à la personne ce qui cause ce comportement. Maintenant, ça ne va pas toujours bien, mais la plupart des adultes réagissent plutôt bien lorsque vous semblez vouloir aider quelqu'un qui semble agir de façon irrationnelle. Les chances sont qu'il n'agit pas de façon irrationnelle, mais il ne se rend pas compte que personne ne peut comprendre ce qui se passe réellement.

Une fois que vous avez identifié le problème, vous pouvez vous doter des outils appropriés pour le résoudre. Si c'est le scénario n ° 1, encouragez-le à faire des recherches à partir des sources en lesquelles il a confiance et (c'est important)revenir à vous avec ses propres conclusions. Cela lui dira que ses propres informations ont de la valeur pour vous. Dans le cas du scénario 2, fournissez des comparaisons précises avec ce qui est différent maintenant. Encouragez-le à faire un essai, mais prévoyez un plan de secours en cas de problème. Pour le scénario 3, demandez-lui de consulter votre source avec VOTRE information. Les chances sont que sa source ne partage pas les vues qu'il pense avoir, mais l'a fait à un moment donné. La plupart d’entre nous s’adaptant avec le temps, son point de vue a probablement changé. S'il ne le veut pas, encouragez-le à vous présenter sa source. Enfin, pour le scénario 4, assurez-vous que ses inquiétudes sont les vôtres. (Ils devraient être à un certain niveau) Démontrez en quoi ce "nouvel" outil peut protéger ses intérêts et accroître sa sécurité. Et si ça ne peut pas,

Je sais que tout cela semble trop simple pour fonctionner, mais parfois, c'est tout simplement le cas. En fait, plus vous êtes sincère, plus c'est souvent le cas. En répondant à ses besoins, vous répondez aux besoins de l'équipe, qu'il soit "senior" ou non, car il fait partie de l'équipe. Lui montrer que vous voulez être sur la même page que lui, mais que ce n’est tout simplement pas le cas, pourrait l’encourager à commencer à travailler avec vous. Si vous avez fait tout cela et que vous n’avez toujours pas résolu le problème, vous avez fait tout ce qui était en votre pouvoir pour parler au chef d’équipe.

FuzzicalLogic

Il y a beaucoup de superstition autour du contrôle de source. C'est contre-intuitif, le calcul est obscur, et cela concerne l'actif le plus important d'une société de logiciels. Je dois admettre qu'il y a une partie de moi qui n'a toujours pas confiance en elle. Mais je ne m'en passerais pas pendant une minute.

Une solution pourrait être de proposer de prendre en charge la gestion du repo. Bien sûr, si vous le présentez comme "c'est beaucoup de travail pour vous, et c'est un domaine dans lequel j'ai une certaine expérience", plutôt que "vous ne savez pas ce que vous faites", ce qui une meilleure chance de travailler.

Si "se voit comme supérieur" signifie ce que je pense, il ne l'abandonnera pas parce qu'il le considère comme une source d'autorité et de contrôle. La solution pour vous serait donc d’utiliser Git localement pour gérer des unités et des branches de commit saines, puis d’appuyer sur svn une fois par jour comme il le demande. Git est conçu comme un système peer-to-peer et doit avoir une copie complète du référentiel sur chaque ordinateur local. Vous pouvez proposer git à d'autres développeurs qui préfèrent le faire de cette façon. Cela peut rester un complément au SVN que des groupes de travail individuels (qu'il s'agisse d'un ou de plusieurs développeurs, formels ou ad-hoc) utilisent en interne. Et quand vient le jour où un responsable senior cède sa place à un autre service ou à une autre entreprise, ou s’inscrit dans une impasse irrécupérable grâce à sa politique SVN, vous avez l’avance de tout nettoyer.

Il suffit de leur parler. Ecoute, je suis un développeur senior, mais il y a des choses que je ne sais pas. C'est la nature de l'entreprise. S'ils deviennent défensifs ou agressifs, c'est un problème de personnalité avec le développeur au cas où cela devrait être traité par le chef d'équipe, ou s'il est le chef d'équipe, par son patron.

Démarrez une initiative concernant les sacs en plastique. Une fois toutes les semaines, une personne tient un déjeuner pour parler de quelque chose qu’elle connaît et la présente aux autres.

Vous utilisez ceci comme une excuse pour présenter SVN en détail et peut-être une partie de la réflexion derrière certaines des alternatives.

Quelques semaines plus tard, quelqu'un d'autre peut tenter sa chance.

Je vais essayer de vous donner quelques indices, étayés par mon expérience personnelle.

Un de mes coéquipiers, bien qu'expérimenté, ne comprend pas vraiment le SVN. Naturellement, les zones vierges de sa carte mentale illustrant les océans de SVN le poussent à adopter des schémas d'utilisation plutôt étranges.

Par exemple, il avait déclaré une stratégie de "1 validation SVN par jour et par développeur", faute de quoi "le serveur manquerait bientôt d'espace disque". Quand je lui ai expliqué que les commits SVN étaient des deltas et non des copies complètes, il a répondu avec un doute et même aujourd'hui, je ne suis pas tout à fait sûr qu'il comprenne ce que cela signifie.

Même si l’espace disque pose problème, vous pouvez toujours valider de nombreux fichiers à la fois. Je pense donc que ce qu’il suggère est la mauvaise solution. En outre, il est possible de gaspiller beaucoup d’espace en archivant des fichiers binaires volumineux, car SVN ne stocke pas les deltas pour les fichiers binaires. Un enregistrement par jour est également mauvais, car il vous oblige à valider des modifications qui ne vont pas ensemble, par exemple si vous corrigez plus d'un bogue par jour.

La solution que nous avons adoptée dans notre société est qu’il existe un filtre qui rejette tout commit contenant des fichiers binaires. Nous pouvons forcer le commit en utilisant un mot-clé spécial dans le commentaire de check-in (nous devons montrer à SVN que nous savons ce que nous faisons). Une fois par an ou deux, un chef de projet archive les anciennes branches et les supprime du référentiel. Avec cette stratégie, nous n'avons pas de problèmes d'espace à ma connaissance (notre référentiel prend en charge plusieurs projets différents et compte plus de 100 000 révisions).

En résumé, vous pouvez lui dire que vous êtes d’accord avec lui pour dire que l’espace disque est une question importante, mais vous devez

1. l'importance des enregistrements relatifs aux fonctionnalités plutôt que d'un enregistrement quotidien monolithique;
2. le fait qu’en archivant un fichier binaire volumineux par jour, on puisse quand même remplir le disque.

Vous pouvez ensuite suggérer d'organiser une réunion (éventuellement avec d'autres développeurs ou administrateurs système) pour discuter de stratégies permettant de contrôler l'utilisation de l'espace disque (par exemple, filtres de fichiers binaires, sauvegarde régulière et nettoyage d'anciennes branches inutilisées).

Nous avons également eu un débat passionné sur l'opportunité d'inclure la configuration de .project Eclipse dans SVN. Mon coéquipier a insisté pour que nous le fassions, même si cela a provoqué de nombreux conflits inutiles. J'étais contre le maintien de fichiers de configuration de développeur individuels dans SVN. Finalement, il s'est avéré que mon coéquipier avait l'habitude de revérifier l'intégralité de l'arborescence source après chaque validation pour s'assurer simplement que "le code validé dans le référentiel fonctionne". C’est la raison pour laquelle il a tellement insisté pour conserver la configuration du projet dans SVN - il serait donc facile de réimporter le projet. Quand j'ai expliqué que commit synchronisait la copie de travail sur un octet à distance distant, ce qui rendait inutile le re-check-check, mon coéquipier a de nouveau douté et a finalement écarté le problème dans son ensemble.

À mon avis, notre équipe perd du temps en résolvant les conflits SVN dans les fichiers de configuration de projet qui ne contiennent que des paramètres spécifiques au développeur qui n'ont pas besoin d'être partagés avec SCM. Tout ce gâchis parce que quelqu'un a adapté le processus autour d'hypothèses incorrectes.

Utilisez-vous un serveur de compilation? Nous avons un serveur de compilation qui vérifie le projet complet et le compile chaque nuit. Le lendemain matin, les testeurs disposent d'un programme d'installation prêt à tester du produit (si la construction principale a fonctionné correctement) et nous (les développeurs) avons un rapport de construction avec tous les avertissements (et les erreurs, le cas échéant). Bien sûr, vous devez configurer les fichiers de configuration standard pour le serveur de build et de les vérifier. Chaque développeur peut alors les vérifier avec le reste du projet, mais ils ne sont pas autorisés à vérifier dans les changements locaux.

Dans ce scénario, vous répondez à son besoin de pouvoir extraire le projet complet et de le construire à tout moment. Vous évitez également de passer du temps à fusionner des modifications qui n'auraient pas dû être vérifiées au départ car elles ne font pas partie du produit: le produit est la version principale et doit être maintenu propre. Si quelqu'un casse la construction principale (en enregistrant par exemple son propre fichier .project), vous pouvez annuler les modifications ou forcer ce développeur à résoudre le problème.

Peut-être que s'il soulève à nouveau le problème, vous pouvez à nouveau suggérer de tenir une réunion (éventuellement avec d'autres développeurs) et de trouver ensemble une stratégie commune.

Comment puis-je convaincre un coéquipier, qui se considère comme senior, de mieux comprendre les bases du SVN?

Je pense que la meilleure stratégie serait d'éviter de ramener le conflit à un niveau personnel et de discuter plutôt des problèmes actuels et des solutions possibles. Si vous avez l’impression qu’il recherche une confrontation personnelle, voici quelques suggestions (encore une fois, tirées de son expérience personnelle):

• Comment est la dynamique de votre équipe? Est-ce que vos autres collègues ont une expérience similaire avec ce coéquipier? Il existe de nombreux petits conseils pas trop explicites qu'une équipe peut donner à l'un de ses membres pour décourager certains comportements (petites blagues ou observations) et encourager la confrontation constructive (proposer une réunion ou aborder un sujet de manière informelle pendant une pause-café). ) Parfois, une bonne équipe peut rapidement isoler un élément perturbant et ramener la situation à la normale.
• Quelle est la qualité de votre gestion du personnel? Nous avons eu un cas de conflit dans notre entreprise et le chef du personnel a dû intervenir pour éclaircir la situation. Ce n’était pas bien, mais l’ambiance de travail se dégrade parfois tellement qu’elle ne s’améliorera pas toute seule. J'espère que ce n'est pas votre cas (je n'ai pas l'impression qu'il soit encore si loin), mais il est toujours bon de savoir si vous avez une bonne administration du personnel ou si vous devez résoudre vous-même des conflits.

Pourquoi est-ce que j'écris ceci? Vous dites que vous voulez "convaincre un coéquipier, qui se voit comme senior", de mieux comprendre les bases du SVN ". Pour moi, il semble que le conflit devienne trop personnel. Certains psychologues soutiennent que 70% de nos communications se font au niveau émotionnel. Si ce niveau ne fonctionne pas, les gens cessent de parler de faits parce qu'ils sont trop occupés par leurs émotions.

Ainsi, en plus d'expliquer vos points, vous pouvez également essayer de faire quelque chose pour améliorer la communication. Inviter à prendre un café ou à prendre le déjeuner ensemble, tenir une brève conversation sur un sujet sans rapport avec le travail, etc., peut améliorer la communication et ramener l'attention de votre collègue sur les faits importants que vous souhaitez lui faire comprendre. S'il accepte ce type de communication, les conflits que vous avez eu jusqu'à présent étaient peut-être liés au fait que vous ne vous connaissiez pas bien et qu'il y avait quelques petits malentendus, mais il est probablement disposé à établir une collaboration constructive. S'il refuse, il pourrait alors y avoir une hostilité plus profonde de son côté.

Dans ce cas, je pense que vous devriez attendre que vos rôles deviennent plus clairs. Si votre coéquipier n'a pas officiellement un rang plus élevé que le vôtre, il ne sert à rien de s'énerver pour tenter d'améliorer les choses. Avec le temps, il devra l'accepter ou se ridiculiser s'il continue d'essayer de montrer qu'il sait mieux. S'il a un rang plus élevé, vous devriez trouver un moyen de lui faire comprendre que cela n'est pas en discussion: vos observations ont pour but d'améliorer la productivité et non de nuire à sa position, cela doit être clair à 100%. Une fois que les rôles ont été clarifiés, s’il ne peut toujours pas accepter les suggestions ou critiques constructives, il doit vraiment avoir un problème d’estime de soi ou quelque chose du genre.

Donc, si toutes les stratégies ci-dessus échouent et que vous continuez à vous sentir (très) frustré (e), je crains que la seule chose raisonnable à faire sera de préparer vos affaires et de chercher un meilleur endroit. J'ai fait cette expérience il y a trois ans et j'ai trouvé une entreprise bien meilleure dans laquelle je suis très satisfait maintenant. Peut-être que ce n'est pas votre cas (j'espère bien sûr que non) mais essayez de comprendre aussi ce point.

Juste mes 2 cents.

Indiquez-lui du matériel didactique sur le fonctionnement de SVN et sur les meilleures pratiques d’utilisation de SVN.

Comme @Peter le dit - choisissez vos batailles avec soin et ne gaspillez pas votre énergie à se battre avec quelqu'un qui, de toute évidence, ne comprend pas les bases. SVN n’est pas vraiment une technologie de pointe, et cela fait un moment que nous avons suffisamment d’informations à ce sujet.

Essayez de garder un journal de la «perte de temps SVN». Chaque fois qu'un problème de conflit / commande / version doit être résolu, notez le temps qu'il a fallu à vous / à l'équipe pour le résoudre. S'il s'avère que vous perdez beaucoup de temps chaque semaine, faites-le savoir avec lui et la direction. Je suis certain que la direction demandera bientôt des solutions si elle se rend compte que la productivité peut être améliorée par de simples changements dans le processus de travail.

Ou essayez de convaincre votre collègue de passer une semaine d'essai au cours de laquelle l'équipe utilise votre système de contrôle (si cela est facilement réalisable avec vos projets actuels et votre base de code). Promettez-lui que si cela ne fonctionne pas, vous pourrez revenir à l'ancien système une fois la semaine passée. Mais il pourrait venir après l'avoir essayé lui-même.

1. Laissez Subversion résoudre le problème pour vous. Comme vous le dites, votre collègue est relativement peu sophistiqué en ce qui concerne Subversion. Dans ce cas, une solution technique pourrait être une bonne option. Si le reste de l'équipe est d'accord et que vous pouvez obtenir la bénédiction de votre responsable, ajoutez un global-ignoreschamp au fichier de configuration du référentiel afin d' exclure les fichiers .project et autres que vous ne souhaitez pas sous contrôle de version.

2. Aidez-le. Au lieu de lui imposer votre façon de faire les choses, essayez d'aider le gars à faire les choses à sa manière sans causer de problèmes à tout le monde. Si votre collègue travaille dans sa propre branche, vous ne devriez vraiment pas vous soucier de ce qu'il commet. S'il veut valider son fichier .project afin de pouvoir extraire une nouvelle copie de tout le répertoire, ce n'est pas un problème pour vous. La seule chose dont vous devez vous soucier, c'est qu'il ne fusionne pas son fichier .project avec la branche de développement commune. Cela devrait être facile à gérer, encore une fois, en définissant la propriété ignore sur la branche de développement pour exclure le fichier .project.

3. Demander l’appui d’en haut. N'entrez pas dans une dispute avec le type "vous n'êtes pas le patron de moi", mais si son comportement vous pose problème, assurez-vous que votre responsable est au courant de la situation. Si vous ne savez pas comment contacter votre responsable, essayez de demander conseil: "Mike, j’ai essayé de parler à Larry, mais je ne réussis tout simplement pas. Il insiste pour que X, Y et Z et le reste d'entre nous passe beaucoup de temps inutile à résoudre les problèmes que cela crée. Pouvez-vous me donner des indications sur la manière de traiter ce type? "

4. L'ignorer. Pourquoi quelqu'un dans l'équipe écoute-t-il ce type? At-il une autorité réelle sur le projet? Qui s'inquiète s'il déclare une politique d'engagement unique par développeur s'il n'a pas le pouvoir de l'appliquer? Laissez-le penser qu'il est Yertle la tortue si cela le fait se sentir mieux, mais ne le laissez pas créer de vrais problèmes pour vous.

Faites virer le gars et faites-le avec son talon traînant et une tache évidente vers une technologie plus récente. Ou vraiment souffler son esprit et commencer à utiliser GIT. S'il ne peut pas comprendre SVn, il sera sûrement épaté par GIT.

Vous semblez avoir une bataille perdue mais vous pouvez vous en sortir. Machiavel dans Le Prince a décrit combien il est difficile de changer le statu quo. Je suggérerais de relire ce chapitre et de ne pas peut-être faire ce qu'il suggère - cela peut être dur.

Vous devez faire part de vos préoccupations au développeur senior en privé et vous assurer de critiquer de manière constructive la façon dont les choses se passent, et non de lui-même ou de tout autre développeur. Ensuite, proposez de faire un exposé et rédigez un guide de bonnes pratiques. Montrez-leur que mieux comprendre SVN leur facilitera la vie. En fin de compte, tout est une question de coûts et d’efficacité. Si vous pouvez prouver que votre façon d'améliorer les choses sans marcher sur les pieds, vous pouvez gagner celui-ci.

Essayez de comprendre pourquoi le (s) senior (s) utilise (sont) le référentiel tel quel. Quelles sont leurs préoccupations? Qu'est-ce qu'ils essaient de réaliser? Comment pouvez-vous les aider à être plus productifs? Surtout, essayez de garder une approche calme et professionnelle. Il est facile d'être frustré. Affirmez-vous: Assertivité au travail: Un guide pratique pour gérer les situations inconfortables de Ken Back et Kate Back est une bonne lecture. Enfin, pensez "comment pourrais-je me convaincre de changer?". Soyez un défenseur honnête du diable et cela peut vous aider à trouver de bonnes réponses et des questions à poser.

En note de bas de page, je ferais attention à utiliser l'humour. Cela peut faire des merveilles ou vous faire sonner comme un asshat. Ainsi, je l'éviterais.

Fondamentalement, choisissez vos batailles avec soin, car vous ne gagnerez peut-être pas celle-ci. Si tel est le cas, ne vous en souciez plus ou cherchez un autre emploi. Harsh, je sais.

Je me trouvais une fois à l’inverse de votre position il ya environ 8 ans, lorsque SVN était une technologie raisonnablement nouvelle. J'étais un développeur senior et un développeur junior a été invité à installer SVN sur un bug (en réalité, il s'agissait plus d'un support informatique qu'un développeur). Malgré mes premiers soupçons quant à l’augmentation de la charge de travail, à la complexité inutile, etc., j’ai eu l’esprit ouvert et en suis devenu un grand fan.

À mon avis, ce que vous avez décrit décrit clairement ce problème qui revient aux personnalités de l’équipe: son entêtement constitue un obstacle pour l’ensemble de l’équipe sur cette question. Vous ferez peut-être mieux de simplement reculer à ce stade et laisser la pression du reste de l'équipe se développer naturellement pour lui forcer la main.

C'est à peu près un cas de "manque d'autorité" et une personne qui applique le pouvoir de sa propre peur à garder les choses "sous contrôle"

Pour résoudre ce problème, trouvez quelqu'un qui a inspiré votre coéquipier ou une personne qu'il respecte et qui est capable d'expliquer l'urgence d'utiliser quelque chose comme SVN. De cette façon, sa peur du changement et de sa "perte d'autorité" n'est pas en jeu, car ce n'est pas un membre de l'équipe qui lui dit quoi faire. Je m'abstiendrais d'utiliser quelqu'un comme un gestionnaire pour parler à ce type, car cela ne ferait qu'ajouter de la pression et pourrait même créer une situation plus stressante pour vous-même.

J'ai récemment lu le document intitulé Driving Technical Change: Pourquoi les membres de votre équipe n'agissent-ils pas sur de bonnes idées et comment les convaincre qu'ils devraient , publié par The Pragmatic Programmers. Ce livre fournit des informations de base que vous devez connaître avant d'essayer d'introduire des modifications techniques, un certain nombre de modèles chez les personnes qui s'opposent ou refusent de changer, des techniques pour mettre en œuvre les changements, puis des stratégies pour optimiser l'utilisation de ces techniques et de l'ensemble des personnes présentes. toi.

Sur la base de votre message, je dirais que votre coéquipier tombe probablement dans le modèle non informé ou cynique, mais il pourrait aussi être un cas d'irrationnel. Certaines des techniques recommandées pour contrer ces types de personnes consistent à acquérir de l'expérience dans l'environnement cible afin de pouvoir détecter tout problème et proposer des réponses aux problèmes que d'autres personnes rencontreront avant qu'elles ne surviennent, résoudre le problème approprié, transmettre le message avec passion, mais sans être trop zélé, montrez les techniques en montrant clairement les avantages de vos méthodes et outils et vendez-les biologiquement (mais ne créez pas de problèmes simplement pour les résoudre), obtenez de la publicité et achetez ainsi du reste de votre équipe. Cependant, s'il est irrationnel, il

Enfin, lorsque vous commencez à utiliser ces techniques, vous avez besoin d’une stratégie globale. Il est important de ne pas laisser ceux qui sont activement hostiles ou irrationnels vous ralentir - les ignorer. Au lieu de cela, trouvez des personnes que vous pouvez démontrer et convaincez que vous avez une meilleure façon de faire et appliquez les techniques appropriées en fonction de chaque individu. Une fois que les gens voient les améliorations apportées par vos connaissances, utilisez-les pour continuer à convaincre les autres. Enfin, utilisez cet effort local pour convaincre la direction qu'il existe une meilleure façon de procéder, mais assurez-vous de l'exprimer en termes compréhensibles (temps, argent, qualité).

N'essayez pas de "convaincre" ce gars de quoi que ce soit. Les gens (même les programmeurs) ne vont pas répondre ou respecter les arguments raisonnables / logiques de la part de quelqu'un qu'ils considèrent comme subalterne. Alors ne perdez pas votre souffle. Au lieu de cela, travaillez sur l'établissement d'un niveau de confiance avec cette personne. Cette personne n'écoutera ce que vous avez à dire que lorsqu'il y est ouvert.

En attendant, vous avez de vrais problèmes:

1. Le gars vérifie son fichier .project dans le dépôt: ignorez-le. vous n'avez pas besoin de modifier le fichier, pas plus que les autres membres de l'équipe qui connaissent mieux. Laisser aller. Si cela donne à votre "membre senior" un sentiment de chaleur et de bonheur, comme une couverture de sécurité, alors qu’il en soit ainsi.
2. Il existe un budget perçu sur l’espace disque: c’est la raison pour laquelle M. Senior impose 1 engagement par jour. La pénurie d'espace est-elle réelle ou perçue? Même si cela vient d’être perçu, vous pouvez peut-être faire quelque chose pour changer cette perception. Cela devrait être traité immédiatement - si vous prenez l'initiative, cela aide également à créer un climat de confiance.

Je pourrais aussi ajouter que ce gars-là sera prêt à adopter de meilleures pratiques SVN quand il pense que ce sont ses idées. Cela nécessitera un peu de réflexion de votre part, et il aura probablement le mérite d’avoir mis en place de meilleures pratiques - mais cela ne vous dérange pas.