Honnêtement, ça devient un peu frustrant pour moi d'entendre autant de paroles, mais de ne voir aucune action de mes coéquipiers. En tant que nouveau venu, comment puis-je les pousser à l'action sans ébouriffer les plumes? Je ne veux pas être ce type.

Utiliser des expressions comme "big talk" et "push them" peut en effet faire de vous ce type , alors vous ne Je ne veux pas y aller.

Pensez à demander à votre responsable s'il vous convient de créer une présentation sur certaines des pratiques que vous jugez importantes. Certaines entreprises organisent des «discussions sur le sac brun» pendant le déjeuner où de tels sujets sont courants.

Si vous êtes accepté, vous pouvez parler de ce que vous proposez, des raisons pour lesquelles vous le jugez important (espérons-le pas seulement parce que vous pensez que c'est un " bonnes pratiques ", mais en savoir plus sur les raisons pour lesquelles cela bénéficiera à l'équipe / l'entreprise dans leur contexte particulier), et comment vous pouvez tous mettre en œuvre ces idées.

Essayez d'obtenir l'adhésion explicite du responsable avant temps, puis utilisez vos pouvoirs de persuasion pour convaincre les autres de prendre le train en marche. Parfois, suggérer un projet pilote démarre bien les choses - le plus simple est souvent de commencer modestement pour apporter des améliorations.

Le reste de l'équipe semble aimer l'idée des tests et des enregistrements fermés, mais n'a pris aucune mesure pour commencer à faire ces choses

Est-ce qu'ils savoir comment faire des tests unitaires?

Si vous n'avez jamais fait cela auparavant, ce n'est peut-être pas simple de commencer à le faire. Surtout si vous avez des années d'expérience à ne faire aucun test.

Il semble que toute votre équipe au moins soit ouverte à l'idée de changer ses processus. Je voudrais m'assurer que vous savez pourquoi ils ne font pas les choses. Je soupçonne que c'est soit une résistance générale au changement, soit un manque de compréhension de la façon de faire les choses.

Si c'est un manque de connaissances, vous pouvez envisager des moyens d'aider. Un bon moyen pourrait être de demander de l'aide à quelqu'un et de faire une sorte de programmation en binôme, lorsque vous travaillez avec du code que vous ne comprenez pas (aussi complètement). Vous pouvez parler de ce que vous faites, et voir si vous pouvez écrire des tests avec l'autre personne là-bas, expliquant ce que vous faites.

Notez que voir un test écrit (révision de code) et savoir comment aborder écrire un test n'est pas forcément la même chose.

Si c'est juste un problème "nous aimons en parler et paraître branché sans rien faire", vous pouvez essayer quand cette conversation a lieu, suggérer ou demander sur des choses très spécifiques et pratiques (plutôt que de simplement déplorer le manque de révision de code ou de test unitaire, aussi):

• "mec, j'aimerais que nous soyons plus agiles."
• " Eh bien, voulez-vous revoir le code de chacun? Je suis libre cet après-midi et j'ai un commit que je fais "

Pour rendre les révisions de code pratiques, vous avez besoin d'un système qui les facilite.Par exemple, comme GitHub le fait avec les requêtes d'extraction ou comme GitLab avec les requêtes de fusion, j'ai entendu de bonnes choses sur Gerrit, mais je ne l'ai pas utilisé. de ceux-ci ou similaires installés (même juste sur votre propre PC, au début), sinon ce ne sera tout simplement pas pratique.

Voici un exemple d'introduction de révisions de code à un collègue utilisant GitHub.

Mettre en œuvre un changement raisonnablement intéressant sur une branche, et laisser intentionnellement des erreurs.Créez une Pull Request et demandez à un coéquipier de bien vouloir l'examiner.Soyez avec lui, montrez-lui votre erreur et comment il peut entrer un commentaire sur Parcourez-lui le reste de vos modifications, s'il fait des remarques, demandez-lui de saisir un commentaire immédiatement après avoir examiné tous les changements ensemble, revenez à votre bureau, validez et appliquez les corrections. les commentaires antérieurs disparaîtront de la demande de tirage, demandez-lui de faire une autre passe au cas où il trouverait autre chose. Il n'y a rien, et la Pull Request peut être acceptée.

Montrez-la également aux autres coéquipiers, continuez à leur attribuer des Pull Requests et encouragez-les à faire de même avec vous. J'espère que la pratique va se répandre.

Le processus est exactement le même avec GitLab (clone gratuit de GitHub), mais ils appellent les Pull Requests comme des Merge Requests Je ne sais pas avec Gerrit et d'autres, j'imagine que des fonctionnalités similaires existent.

Nous avons mis en œuvre cette idée dans deux équipes jusqu'à présent, au cours des 3 dernières années.C'est la pratique la plus populaire que nous avons mise en œuvre.Les gars qui le font adorent le faire et m'envoient parfois des demandes de fusion même après avoir rejoint une autre équipe .Dans mes nouvelles équipes, j'essaie de diffuser la pratique exactement comme je l'ai décrit ci-dessus.

En ce qui concerne les tests unitaires:

• Obtenez un système de construction continue qui fonctionne et qui s'exécute tests unitaires dans le cadre de la construction.
• Proposez un déjeuner-causerie avec des exemples de bons tests unitaires et de mauvais tests unitaires. Placez le contenu que vous avez utilisé dans un référentiel public.
• Rédigez de bons tests unitaires et attribuez des demandes de fusion à un coéquipier qui est le plus susceptible d'accepter l'idée.
• Faites du lobbying pour que tout le monde mette en œuvre (au moins) un test unitaire par semaine. Assurez-vous de mesurer et de suivre les progrès (j'utilise une simple feuille Excel).

En ce qui concerne les améliorations de la qualité du code:

• Obtenez un outil d'analyse statique intégré dans le système de construction continue. Par exemple SonarQube.
• Mettez en œuvre des corrections aux problèmes soulevés par l'outil d'analyse statique et attribuez des demandes de fusion à un coéquipier qui est le plus susceptible de souscrire à l'idée.
• Proposer d'acheter des livres qui sont bien connu pour être de bonnes ressources dans votre domaine, faites-les traîner sur votre bureau et encouragez les autres à prendre et à emprunter à tout moment.
• Faites du lobbying pour que tout le monde mette en œuvre (au moins) une correction aux problèmes soulevé par l'outil d'analyse statique par semaine. Assurez-vous de mesurer et de suivre les progrès (j'utilise une simple feuille Excel).

Notez le modèle commun dans les deux exemples ci-dessus:

1. Obtenez un configuration d'outils qui vous aideront à atteindre vos objectifs efficacement
2. Utilisez les révisions de code comme un moyen de montrer l'exemple
3. Obtenir des documents complémentaires complémentaires
4. Faire du lobbying pour mettre en œuvre des améliorations en petites étapes faciles à gérer

Toutes ces idées sont des changements incrémentiels si petits et simples qu’elles sont vraiment faciles à vendre.

Personnalisez et utilisez une variante adaptée à votre environnement.