Présentation de nouveaux sujets aux collègues

J'ai essayé d'introduire des sujets tels que les tests unitaires, l'injection de dépendances, l'inversion de contrôle, etc ... aux collègues. J'ai donné des mini conférences, des démonstrations, et j'ai suggéré ces sujets pendant le déjeuner et apprend. La réception a été généralement positive et les gens voient de la valeur dans de tels sujets.

Même s'ils semblent attirés par ces sujets, l'adoption a été très faible. Quand je leur en parle, la réponse est généralement dans le sens de:

Je vais l'essayer la prochaine fois. Je veux juste lancer ce projet.

J'ai le sentiment que c'est parce que la plupart de ce qu'ils ont vu ne sont que des démonstrations de type conférence et qu'ils n'ont aucune expérience pratique. Que puis-je faire pour les aider à les pousser? Je ne veux pas les "forcer" à écrire du code s'ils ne le veulent pas, car cela peut sembler être des "devoirs" et cela peut leur laisser une mauvaise impression.

Nos projets ne laissent généralement pas de temps à l'expérimentation, de sorte que les gens ont tendance à se détourner des nouvelles technologies. Cela ne laisse pas de place aux développeurs pour essayer d'incorporer de nouvelles choses pendant la phase de développement.

Y a-t-il des exercices amusants ou intéressants (en solo ou en équipe) qui leur permettent d'avoir plus d'expérience pratique sur ces sujets? J'espère trouver quelque chose qui susciterait suffisamment d'intérêt pour qu'ils soient prêts à planifier une heure de leur journée pour travailler sur quelque chose de bien, ou un intérêt suffisant pour qu'ils enquêtent sur leur propre temps.

Pour «prouver» et donc vraiment implanter une idée dans la tête de quelqu'un, la théorie (parler) n'est jamais suffisante.

Vous devez utiliser ces pratiques dans votre propre code et leur faire "découvrir" que cela a résolu les problèmes d'une manière agréable.

Cela implique que vos pratiques doivent être efficaces et vous devez le rendre évident.

De cette façon, la lecture de votre code les inspirera car ils "le verront en action".

Ne présumez pas que le simple fait de dire comment cela fonctionne suffira.

En parlant d'expérience, s'ils ne veulent pas appliquer ce que vous essayez de leur enseigner, cela signifie qu'ils ne s'en soucient pas. Vous perdez probablement votre temps en essayant d'introduire les sujets à eux, parce que s'ils ont compris les avantages réels de ces sujets qu'ils veulent les appliquer, ne pas donner des excuses pour expliquer pourquoi ils ne peuvent pas.

C'est comme essayer d'introduire quelque chose de mieux que ce qui est actuellement utilisé et obtenir des regards vides ou des réponses immédiates pourquoi il n'est pas possible de le faire; cela indique que l'autre personne ne le voit pas vraiment comme un avantage (parce que s'il était capable d'en voir l'avantage, il ne donnerait pas d'excuse).

Triste mais vrai. Peut-être que votre situation est différente, mais je l'ai rencontré plusieurs fois dans le passé et à la fin, il était douloureusement évident que personne sauf moi n'était intéressé par ces sujets; J'ai finalement pris la décision de partir et d'essayer de trouver des collègues qui s'occupent de moi; le genre de personnes qui n'ont pas besoin de moi pour présenter les sujets (parce qu'ils les connaissent déjà / les utilisent) ou qui sautent sur l'accepter, au lieu de dire comment ils ne peuvent pas le faire.

J'ai vu beaucoup de "meilleures pratiques" tomber en disgrâce et ne plus jamais être utilisées. Il existe de nombreux types de projets et ces techniques ne conviennent pas à tous les projets. Assurez-vous que les articles que vous vendez vous aideront vraiment.

Si vous commencez à le faire et que les gens peuvent voir que vous êtes plus productif ou que vous produisez un code de meilleure qualité, ils auront un autre regard plus tard. Réfléchissez bien, tous les frais généraux supplémentaires aideront-ils vraiment votre projet? Toutes les applications n'en ont pas besoin.

Si vous pouvez motiver vos collègues à participer, vous pouvez organiser des Dojos de codage . Ce sont des défis de programmation où les participants se concentrent délibérément sur l'amélioration de la pratique. Peut-être que participer à un dojo piloté par des tests, par exemple, amènera vos collègues à voir les avantages du TDD.

Alternativement, ces choses doivent parfois être imposées par la culture. Il me semble que la culture de votre entreprise n'est pas d'en avoir besoin.

S'ils deviennent une exigence de clôture du projet (probablement une décision de gestion), vous verrez de l'adhérence, mais au moins une certaine application desdits outils et la culture commenceront à changer.

La meilleure pratique concerne le code de production réel. Les katas sont une belle introduction, mais d'après mon expérience, ne tiennent pas le même "Eurêka!" Des moments comme le voir pour de vrai .

Cependant, vous avez souligné que les délais "ne permettent pas d'expérimentation". C'est vraiment une solution simple. Vous faites déjà ces choses que vous essayez d'enseigner, alors laissez une invitation ouverte à vous jumeler pendant que vous implémentez une nouvelle fonctionnalité géniale X. Laissez-les s'asseoir au clavier et faire la frappe pendant que vous " conduite sur le siège arrière ". Cela leur permettra de construire une mémoire musculaire et de la confiance.

Bonne chance dans vos efforts.