Vous avez déjà de bonnes idées
Les idées que vous décrivez dans votre question semblent excellentes. C'est une grande surprise que vous ne trouviez pas de succès. Nous sommes en 2012 et la révolution orientée objet est depuis longtemps passée de l'état de l'art à l'état de la pratique. Il semble qu'à moins d'avoir un taux de rotation très faible et très peu d'embauche, vous auriez du mal à ne pas obtenir plusieurs dizaines, voire une centaine de bons programmeurs orientés objets solides.
Agile ou orienté objet?
Vous mentionnez certaines technologies agiles comme TDD et certains concepts plus récents, alors ne soyez pas trop sévère avec les gens pour ne pas embrasser quelque chose qui est toujours activement combattu par certaines équipes de gestion. Certains prétendent embrasser Agile, mais quand ils en parlent, cela signifie ce qu'ils disent que cela signifie. L'organisation n'est pas caractérisée par des équipes qui prennent des décisions et s'adaptent, mais plutôt par un contrôle hiérarchique de type contrat fort.
Mais revenons à l'objet orienté. Vous ne mentionnez pas l'analyse ou la conception orientée objet, et je ne sais pas trop quel langage de programmation cède la place à quel langage de programmation orienté objet. Je sais que UML a des problèmes de popularité parmi de nombreux programmeurs orientés objet. Ayant une formation approfondie en OOAD, je pense que cela peut être comme apprendre la culture et l'histoire d'un pays dont vous voulez apprendre la langue naturelle. Par exemple, si je voulais apprendre le grec, je pourrais apprendre l'alphabet, le vocabulaire et la grammaire, mais si j'ignorais la riche histoire et la culture, je manquerais beaucoup. En tout cas, si vous apprenez tout sur un langage de programmation orienté objet, mais rien sur OOAD, je pense qu'une opportunité importante a été perdue.
Des problèmes à surmonter?
Pont trop loin? Si vous demandez aux gens d'apprendre une petite chose par semaine, en un an, parmi les gens qui participent, il y aura beaucoup de changements. Si vous leur demandez de changer tout ce qu'ils savent, cela sera bien accueilli par quelques-uns, difficile pour beaucoup et impossible pour d'autres. Certains changements comme le contrôle de code source sont localisés. Vous transitions de ne pas le faire avant, vous avez eu une formation qui ne mettait pas l'accent sur les limites de la mémoire, quelqu'un vous a guidé la première fois, puis le quotidien était assez facile.
D'autres changements sont omniprésents. Par exemple, le dumping de C et le passage à Java nécessitent une formation, une configuration et des changements importants dans la vie de tous les jours pour adopter un nouvel IDE, un nouveau compilateur, un nouveau langage, une nouvelle API, un nouveau modèle de déploiement, etc. des choses qui se produisent le plus souvent en conjonction avec un programme pilote ou une restructuration d’entreprise.
Mener une révolution? Si les personnes qui effectuent actuellement le travail ont des antécédents de récompense et que l'entreprise ne semble pas menacée d'échec, quelle est leur motivation pour le changement? Si vous semblez être un étranger qui veut indiquer la direction et les laisser responsables des résultats qu'ils ne peuvent pas prévoir, cela peut sembler être un risque, aucune récompense.
Positionner le leadership ou le leadership d'idées? De nombreuses organisations fonctionnent sur la base du pouvoir de position. Si vous manquez d'un soutien visible de la part des gestionnaires, des chefs de section, des directeurs et des vice-présidents, vous n'êtes qu'un leader d'idées. Certaines personnes sont dans la position dangereuse d'avoir une idée et de ne pas pouvoir en retenir une seconde. Si vous pouvez leur montrer au lieu de leur dire, cela fera beaucoup pour calmer les sceptiques et intéresser des alliés talentueux.
Base de support trop petite? Faites un tri parmi ces 250 personnes et triez-les en trois catégories: prêt à embrasser, disposé à apprendre et peu disposé à apprendre. Vous avez de bonnes raisons d'être frustré par certaines des personnes qui n'ont aucun intérêt à faire un changement. Vous pourriez aussi bien pousser sur une corde. C'est un effort inutile. Si vous savez qui soutient le changement, vous pouvez découvrir ce qui les intéresse.
Contrairement à un triage médical où le choix éthique et pratique est d'aider le groupe intermédiaire qui peut le faire avec de l'aide, vous pouvez investir votre énergie et votre temps en fonction de votre jugement et de vos préférences. Pour votre réussite, pourquoi ne pas cultiver le groupe qui est prêt à embrasser de nouvelles idées? Ils peuvent être peu nombreux en premier, mais comme une boule de neige, votre visibilité et votre crédibilité en tant que défenseur grandiront. Bientôt, les gens vous demanderont quand aura lieu la prochaine formation.
Dans le long terme? Jusqu'à ce que vous cultiviez un champion pour porter les choses après vous, vous devriez vous attendre à investir du temps dans l'établissement de relations. Vous devrez peut-être rester avec les équipes que vous entraînez pendant plus d'un mois. Jusqu'à ce que l'équipe possède des pratiques améliorées pour elle-même, vous n'êtes qu'un flic en technologie ou en méthodologie. Le mentorat est un processus qui peut prendre des années. Il y a beaucoup de choses que vos développeurs ne veulent pas faire que vous jugez importantes (vous avez spécifiquement mentionné les tests unitaires, je pense). Cela peut prendre un certain temps pour construire une vision partagée de la valeur que cela apporte. Je le sais par expérience, car j'ai déjà plaidé pour un outil de couverture de code dans une entreprise du Fortune 500 qui avait une grande réputation de qualité, mais les gestionnaires et les pairs se méfiaient de s'y engager.
Expert ou populaire? Bien plus rapidement que le mentorat, il s'agirait de favoriser le soutien local qui vient de chaque membre de l'équipe. En commençant par une équipe de dix spécialistes des logiciels, si j'avais le choix d'avoir une personne travaillant sur le processus tout le temps ou dix personnes travaillant sur le processus dix pour cent du temps, je choisirais la seconde. Le processus de base permet aux défenseurs de ressentir l'impact de l'approche et d'adapter l'approche pour résoudre au mieux les problèmes de l'équipe propriétaire du travail.
Voyez-vous la Freedom Line? Une partie de l'introduction des «meilleures pratiques» consiste à amener les gens à renoncer à une certaine liberté de faire les choses d'une manière commune. Renoncer à la discrétion du programmeur sera plus acceptable si vous recherchez des opportunités pour laisser de nombreux choix aux développeurs. Ce qu'ils choisissent est délimité de ce qui est mandaté par une partition que nous pouvons appeler la ligne de liberté. Il peut être nécessaire de créer des divisions similaires et bien justifiées concernant les pratiques organisationnelles, régionales / spécifiques au site, d'équipe et personnelles.