Comment convaincre mes coéquipiers de suivre quelques règles de base

J'ai un problème avec mes coéquipiers. Pour faire court: nous sommes trois étudiants travaillant sur un projet de concours. Le projet se compose de 2 applications distinctes: une pour Windows (que je développe) et une pour Android (mes collègues sont responsables de son développement). Nos bases de code ne se recouperont jamais, les applications communiqueront via des outils tiers.

Le problème est le suivant: j'ai une certaine expérience de travail en équipe car j'ai effectué un stage dans une grande entreprise l'année dernière, et j'essaie d'appliquer certaines normes de codage pour notre code. J'ai également mis en place un référentiel git / wiki / logiciel de collaboration que nous pouvons utiliser pour pousser du code / écrire des idées, des protocoles de document et ainsi de suite, mais il semble que je suis le seul à utiliser ces outils.

J'ai essayé de leur dire qu'écrire du code de qualité et documenter chaque étape nous serait bénéfique à long terme, mais ils ne semblent pas en voir l'avantage. Je pensais aussi ajouter des tests d'intégration mais d'après ce que je peux voir, tant qu'ils n'utilisent pas les outils actuels pour leur faciliter la vie, je ne pense pas pouvoir les convaincre de l'utilité des tests d'intégration.

La plupart du code des pairs réside sur leurs ordinateurs, ils ne partagent pas une base de code commune et comme je l'ai découvert, ils ont intégré leurs morceaux en rencontrant et en partageant du code via une clé USB.

Ma question est: suis-je trop sévère à ce sujet? Dois-je appliquer des règles absurdes? Gardez à l'esprit qu'il s'agit d'un petit projet, les exigences sont très claires (j'ai créé des documents spécifiant ce que doivent faire les applications), trois développeurs qualifiés pourraient le faire en 3-4 jours, donc ils pourraient ne pas voir la complexité supplémentaire de la qualité d'écriture du code tant que leur méthode actuelle fonctionne.

Existe-t-il un moyen de leur montrer l'avantage de documenter le code, d'utiliser git, etc.?

Ma question est: suis-je trop sévère à ce sujet?

Vous pouvez conduire un cheval à l'eau, mais vous ne pouvez pas le faire boire.

Il est difficile de dire si vous êtes «trop sévère», mais il peut être irréaliste de s'attendre à ce que vos coéquipiers adoptent toute l'infrastructure que vous espérez. Et vraiment, si l'équipe travaille bien ensemble, utiliser un wiki pour communiquer entre trois personnes est probablement exagéré.

Réduisez vos attentes et cherchez des moyens d'atteindre certains de vos objectifs sans les obliger à utiliser des outils qu'ils ne connaissent pas. S'ils ne savent pas utiliser git, ils n'en tireront probablement pas beaucoup d'avantages de toute façon. Cependant, vous voulez toujours vous assurer que tout le code est sauvegardé en cas de défaillance du disque dur ou d'une autre catastrophe, alors demandez-leur de copier périodiquement leur dossier de projet sur Google Drive, Dropbox ou un service de partage de fichiers en ligne similaire. Assurez-vous de faire de même.

Mon attitude est que si vous pouvez apprendre à faire ces choses sur de petits projets, vous serez prêt lorsque de grands projets arriveront.

S'ils suivent de bonnes pratiques de développement avec ce projet, ils auront du code à présenter aux futurs employeurs et ils auront une expérience qui les rendrait précieux en tant qu'employés.

Si vous voulez plus de matériel pour les convaincre, je vous référerais au programmeur pragmatique , ou Code complet .

D'un autre côté, pensez à leur couper un peu de mou. Si le projet est une preuve de concept qui est rejetée juste après la compétition, alors vous devriez simplement les laisser faire ce qu'ils veulent. Ils pourraient avoir du mal à écrire le code en premier lieu, sans la surcharge mentale des bonnes pratiques.

Je crains que les règles que vous avez décrites ne soient pas du tout fondamentales.

La tâche la plus simple de l'OMI est de convaincre vos coéquipiers d'utiliser certaines normes de codage. Et un moyen simple d'y parvenir est de leur montrer le même extrait de code une fois bien formaté puis mal stylisé, de leur demander de lire le code, de comprendre ce qu'il fait et de les laisser se juger eux-mêmes.

En ce qui concerne l'utilisation d'un référentiel git, cela peut être pénible pour les novices. Lorsque je travaillais dans une équipe de 3 personnes sur un projet Android, nous avons eu beaucoup de problèmes avec notre système de contrôle de version au début. J'espère donc que vos coéquipiers auront eux aussi des ennuis.

Vous avez mentionné qu'il faudrait 3-4 jours aux développeurs expérimentés pour terminer le projet (je suppose que cela prendrait 2-3 fois plus de temps à votre équipe). Il s'agit d'une très courte période de temps, donc l'argument selon lequel l'utilisation de nouveaux outils aidera à long terme ne fonctionnera tout simplement pas.

Ce que vous pouvez faire, c'est faire des démos courtes et simples pour montrer comment ces outils sont utilisés. Couvrez d'abord les fonctions les plus élémentaires, asseyez-vous à leurs côtés et aidez-les à utiliser les outils. Soyez prêt à effectuer toutes les tâches telles que la configuration de git, la création de la structure de la page wiki, etc.

Edit : En réponse au commentaire, je pense qu'il est plus important d'établir des tâches claires, des estimations et des délais et de garder une trace du temps passé que d'utiliser git ou des outils similaires. Si vous prévoyez de travailler sur l'application plus tard, il est très important de garder une trace de ce qui est déjà fait et du temps que chaque fonctionnalité a pris. Je vous suggère donc de commencer par la gestion des tâches, puis de passer aux outils que vous souhaitez utiliser.

En fait, j'aime les réflexions de Joel Spolsky à ce sujet, comme il l'a expliqué dans Getting Things Done When You Only Only Grunt . Résumer:

1. Faites-le simplement - Écrivez des makefiles, créez un serveur de construction quotidien, etc.
2. Personne n'utilise le contrôle de code source ou les bases de données de bogues? Commencez à les utiliser vous-même. Si quelqu'un signale un bogue contre votre travail, demandez-lui poliment d'utiliser la base de données de bogues pour vous signaler des bogues afin que vous puissiez en garder la trace; sinon vous ne pourrez pas les garder droits dans votre tête et les réparer. Sur tout projet non trivial, il y aura une situation qui ne peut être résolue qu'avec le contrôle de source: utilisez le contrôle de source pour le code par vous-même et foncez héroïquement pour sauver le jour où une telle situation se produit. Une fois que cela se produit plusieurs fois, ils seront convaincus
3. Créez une poche d'excellence - Faites les bonnes choses pour vous-même: spécification, planification, etc. Étant donné que cela ne semble pas être un projet de travail, il ne semble pas que vous puissiez suivre ce conseil jusqu'au bout, car vous ne pouvez pas embaucher nouveaux membres de l'équipe qui croient en votre message
4. Devenez inestimable - Démontrez que vous êtes un grand contributeur pour cimenter votre influence dans l'équipe. Sinon, vous courez le risque de devenir connu comme une personne qui valorise les processus et les outils par rapport aux résultats

La documentation, le wiki, le logiciel de versioning, les méthodologies, etc. sont des expériences et des leçons apprises au fil du temps; travailler sur plusieurs projets et probablement sur plusieurs équipes. Et cela colle généralement à ceux qui ont déjà un emploi ou qui prennent leur industrie au sérieux. Ce sont des étudiants, donc leurs intérêts sont probablement limités avant ce qui se passera à l'avenir. :)

Mais pour essayer de répondre à votre question:

Si vous faites partie d'une équipe avec eux, vous devez appliquer ce que vous jugez important d'une manière qui profite à leurs intérêts. À titre d'exemple: devraient-ils se plaindre de la rupture de leur code lorsque le partage USB le fait? Ensuite, donnez-leur peut-être une manière simple (non compliquée) d'utiliser SVN (plutôt que git) comme outil de versioning.

Je suis également d'accord avec le commentaire d'Arnaud.

Vous avez vu l'avantage de tous ces outils lorsque vous travailliez avec eux et c'est ainsi que vous avez vu leur valeur et pourquoi vous comprenez leur utilisation. Si vos coéquipiers ne voient pas de valeur ajoutée dans leur façon de faire, ils ne l'appliqueront pas. Et le plus triste, c'est que cela compte même pour des équipes composées de personnes ayant n'importe quel niveau d'expérience.

L'approche a des problèmes:

1. Votre approche n'est pas symétrique. Les autres membres de votre équipe doivent changer, mais vous n'apprenez pas leurs bonnes pratiques. L'application des règles dans une situation comme celle-ci est difficile. Une meilleure approche serait de collecter les bonnes règles et pratiques de tous les membres de l'équipe et ensuite tout le monde lit simplement le document résultant.

2. L'apprentissage est difficile. Les règles des autres n'ont tout simplement pas de sens car ces règles n'ont pas la structure logique que vos programmeurs attendent. L'application de règles qui n'ont aucun sens n'est pas une activité utile.

3. Tout le monde a appris des choses différentes. Il est naturel que des programmeurs venant d'horizons différents aient appris des choses différentes. Leurs forces sont différentes et les styles d'écriture du code différents. Les outils qu'ils utilisent sont différents. L'application d'un ensemble de règles / outils / styles va être un cauchemar car les limitations perdent la force que ces développeurs ont passé des années à apprendre.
4. Le changement prend du temps. Alors que la personne qui a inventé les règles que vous appliquez a du mal à suivre les règles, tout le monde souffre et passe du temps à apprendre les nouvelles règles. C'est une des raisons pour lesquelles tout le monde dans l'équipe devrait pouvoir changer les règles.
5. Le choix d'outils / conventions de codage ou styles pour toute une équipe est une activité difficile . Cela ne peut se faire que lentement au fil du temps, en testant ce qui fonctionne et ce qui ne fonctionne pas. Donner à une équipe 2 semaines pour commencer à suivre 50 règles ne fonctionnera pas.

J'ai trouvé ce problème à l'université. Beaucoup de gens ne veulent tout simplement pas apprendre une manière différente (et peut-être plus professionnelle) de travailler.

Si vous avez des systèmes en place et expliquez comment utiliser le système, alors beaucoup de gens sont prêts à l'essayer. Je pense également que les référentiels sont des outils très sous-utilisés et que les gens utilisent généralement simplement quelque chose comme dropbox.