Comment amener les gens à cesser de faire du vélo (en se concentrant sur des trivialités)?

On m'a demandé d'enseigner une nouvelle base de code à d'autres équipes, mais je rencontre toujours un problème. Chaque fois que je vais parcourir le code avec des gens, nous n'allons pas très loin avant que l'exercice entier ne devienne un exercice de bikeshedding (membres d'une organisation donnant un poids disproportionné à des problèmes triviaux). Comme ils ne connaissent pas la base de code, mais pensent qu'ils doivent aider à l'améliorer, ils se concentrent sur les choses qu'ils peuvent comprendre:

Why is that named that? _{(2 minutes pour expliquer pourquoi on l'appelle ainsi, plus de 10 minutes pour débattre d'un nouveau nom)}

Why is that an abstract base class rather than an interface? _{(2 minutes pour expliquer, plus de 10 minutes pour débattre des mérites relatifs de cette décision)}

...etc. Maintenant, ne vous méprenez pas - bons noms et bonne, la conception cohérente sont importants, mais nous ne sommes jamais à discuter de ce que le code fait fait ou comment le système est conçu de manière significative. J'ai organisé des réunions d'arbitrage pour sortir les gens de ces tangentes, mais ils sont partis - distraits par ce que le code va être / devrait être quand la trivialité de leur animal de compagnie sera corrigée, et ils ratent l'image plus grande.

Nous réessayons donc plus tard (ou avec une partie différente de la base de code) et, comme les gens n’avaient pas assez de connaissances pour surmonter l’effet de cyclage, cela se répétait.

J'ai essayé des groupes plus petits, des groupes plus importants, du code, du tableau blanc, des diagrammes visio, des murs de texte géants, leur permettant de se disputer à mort, coupant les arguments immédiatement ... certains aident plus que d'autres, mais rien ne fonctionne . Enfer, j'ai même essayé de demander à d'autres personnes de mon équipe de l'expliquer parce que je pensais que c'était peut-être parce que je n'étais tout simplement pas capable d'expliquer les choses.

Alors, comment éduquez-vous suffisamment les autres programmeurs pour qu’ils arrêtent de se concentrer sur des trivialités et puissent réellement contribuer à la conception?

Je pense que le problème est la tâche: "J'ai été chargé d'enseigner une nouvelle base de code à d'autres équipes".

On vous a donné le mauvais emploi, ou peut-être mal interprété le travail qui vous a été confié.

En présentant au niveau du code, vous invitez à penser au niveau du code.

Commencez au niveau du système et présentez la conception et les choix de conception qui ont été faits. Ne permettez pas une discussion prolongée: vous ne l'examinez pas. Autorisez les questions: vous voulez qu'elles comprennent le système. Si les gens "l'auraient fait différemment", bien. Peut-être d'accord. Ou pas. Mais passons. C'est comme ça en ce moment.

Lorsque vous arrivez au niveau du code, vous les avez déjà familiarisés avec la terminologie du système. Les noms (je suppose) auront un sens. Comme ci-dessus: pas de discussion prolongée, questions de compréhension. Passez.

Maintenant, définissez quelques problèmes de classe à résoudre. Comment pouvons-nous améliorer X? Choisissez quelque chose de non trivial qui "va avec le flux" de la conception du système et analysez ce que vous souhaitez changer. Ils devraient avoir maintenant la logique du système. Choisissez une autre amélioration qui pourrait casser le système si elle était mal faite et montrez comment on peut le faire correctement. Cela devrait être un moment Ah Ha pour eux. Certains pourraient même vous battre à cela!

C'est un travail difficile, surtout après le faux départ que vous avez eu. On dirait que vous avez déjà investi beaucoup de temps et d’efforts, et peut-être que vous ressentez un peu mon sentiment contre eux. Fesser, et recommencer. Nous supposons que ce sont des gens intelligents. Donnez-leur le défi de penser au niveau supérieur. Et divisez les groupes existants en sélectionnant différents groupes d’équipes pour les nouvelles sessions.

"Garez-les". Au début de la leçon, expliquez ce que vous devez discuter et expliquez clairement ce qui est considéré comme hors sujet. Si on vous pose une question qui est clairement OT, dites-le et passez à autre chose. S'ils y reviennent, écrivez la question sur un tableau blanc (ceci est essentiel) pour une discussion ultérieure et passez à la suite. À la fin de la leçon, observez la rapidité avec laquelle ces questions sont résolues, quand elles ne sont pas à vous, mais quand vous le souhaitez.

Définissez les attentes correctement et soyez honnête, ouvert et franc.

Assurez-vous que vos objectifs sont ouverts et transparents.

Commencez les discussions avec la vue de haut niveau promue par andy256 (+1), mais veillez également à inclure vos objectifs, par exemple:

"... alors que nous examinons cette question, assurons-nous de ne pas nous focaliser sur x, y et z. Veillons également à ne pas nous intéresser aux détails de la mise en oeuvre tels que a, b, c ou des détails triviaux. comme j, k, 1. Je sais que le code contient énormément de détails et de détails sur les points qui pourraient être abordés, améliorés ou rendus plus standard, mais essayons d'abord de voir ce que nous accomplissons réellement à un niveau supérieur "

Alors, comment éduquez-vous suffisamment les autres programmeurs pour qu’ils arrêtent de se concentrer sur des trivialités et puissent réellement contribuer à la conception?

Premièrement, ne considérez pas leurs préoccupations comme des "banalités" ou des "bikeshedding". Ce sont des mots de jugement, et ils sont insultants. Leurs préoccupations sont valables. Ils ne sont tout simplement pas importants pour le moment.

La clé de toute bonne réunion est que tout le monde sache:

• pourquoi tu as une réunion et
• ce que vous espérez en sortir
• combien de temps ça devrait durer

Énoncez ces choses dès le départ, explicitement, et expliquez les objectifs.

Par exemple, vous pourriez dire: "Cette réunion me permet de vous familiariser avec le paquet Foo et son utilisation dans notre module de reporting. Mon objectif est que vous compreniez suffisamment Foo pour pouvoir travailler sur le projet Bar Reports la semaine prochaine. J'aimerais que nous ayons terminé dans les 90 prochaines minutes. "

Ensuite, lorsqu'un sujet est abordé, cela peut ressembler à ceci:

Nouvelle personne: "Pourquoi FooWidget est-il implémenté en tant que motif de façade?"

Vous: "Bien, je pense que c'est parce que (brève explication de la décision de conception)" ou "je ne sais pas".

Si la réponse est suffisante, c'est génial. Si non, et ça continue:

NP: "Vous ne pensez pas que ce serait mieux fait en tant que singleton?"

Vous: "Je n'y avais pas vraiment réfléchi, mais j'aimerais continuer à expliquer comment fonctionne FooWidget."

NP: "Mais si c'est fait en tant que singleton, alors nous pouvons--"

Vous: "Je suis désolé de vous interrompre, mais je dois rester concentré sur le fonctionnement de FooWidget. Cette réunion n’est planifiée que vers 11h00 et nous avons encore beaucoup à faire. La discussion sur la conception devra attendre une autre fois. . "

Une fois que vous avez parcouru cela une ou deux fois, vous pouvez le résumer comme suit: «Cela n’entre pas dans le cadre de cette réunion».

Notez que vous ne dites pas "c'est idiot de s'inquiéter pour" ou "ça n'a pas d'importance" ou "Tais-toi" ou "Tu es trop nouveau pour avoir une entrée." Vous concentrez simplement la réunion sur ce qui doit être fait et le temps impliqué.

Dans certaines organisations, vous ne pourrez jamais atteindre cet objectif. De nombreuses organisations accordent plus d'importance aux querelles politiques et à l'escalade que la capacité intellectuelle, la diligence et la loyauté. Et pourquoi pas eux. L'escalade en échelle place les gens en position de pouvoir, leur permet d'améliorer leur vie personnelle avec un revenu plus discrétionnaire et ne devient vraiment jamais obsolète.

Comparez ces conflits de pouvoir à la résolution de problèmes, à la pensée abstraite et à la prise de décisions sur des questions difficiles, qui pourraient être responsables des conséquences de la situation ultérieure, et de nombreux employés pèsent lourdement sur le fait d'essayer de faire du vélo autant que possible.

Le seul conseil que je suggère est que vous expliquiez très clairement, dans le contexte de votre organisation, si possible, que le destin personnel de ces participants dépend de leur compréhension, de leur contribution et de leurs efforts face au vrai problème que vous tentez de résoudre. Si c'est l'architecture d'entreprise, exprimée dans cette -errant-codebase et tout ce qu'elle échoue, c'est tout. Expliquez-leur clairement qu'ils doivent fournir une contribution significative et significative à ce sujet . Pas un autre hasard, cela se trouve être la bête noire d'une personne âgée ou d'une autre personne et leur rapportera de bons points brownie en étant d'accord avec cette personne âgée.

Cela est souvent difficile à faire, car la personne âgée ne comprend généralement pas la technologie en cours, n’est pas intéressée et contrôle malheureusement les ingrédients de base: temps des employés; embaucher et renvoyer, politique de la salle de conférence, promotions, etc., etc. sérieusement, et ainsi de suite.

Ce que vous appelez le cyclisme, j’appellerais convertir le flux de pensées de quelqu'un en notre propre flux de pensées. En discutant des noms, des schémas, ils comprennent le code dans ses propres termes et il n’ya aucun moyen de l’empêcher, c’est nécessaire.

En outre, il n'est pas nécessaire de passer en revue de manière très détaillée une base de code complète, car les détails seront oubliés bien avant qu'ils ne travaillent.

Sur la base de ces deux idées, je suggérerais de diviser la base de code en unités et les apprenants en groupes de deux personnes. Pour chaque unité de code, chaque groupe disposera, disons, de 25 minutes (dépend du COL, bien sûr), pour pouvoir effectuer une visite guidée du code de 5 à 10 minutes aux autres. Trois minutes de questions et répétez avec l'unité suivante. Expliquer est le mot clé; ils doivent s'assurer que les autres ont tout compris.

Vous ne seriez là que pour faire respecter le temps, pas hors sujet et contrôler l'unité a été suffisamment comprise. Ils seront des acteurs de leur apprentissage et seront plus concentrés sur l'explication aux autres que le bikeshedding.

Vous pouvez avoir besoin d’un schéma dessiné à la main de haut niveau de l’unité de code, qui sera copiée et conservée sur les documents partagés par l’équipe, afin qu’ils aient quelque chose de concret à consulter à l’avenir. C'est bon aussi d'ancrer des souvenirs.

Désolé si vous avez déjà essayé cela ...

Avez-vous essayé de faire des pré-leçons que les gens regardent individuellement?

Réalisez de courtes vidéos ou des présentations qui expliquent le contenu, le fonctionnement du code ou tout ce que vous voulez leur enseigner, dans un format où ils doivent l'examiner par eux-mêmes et apprendre les informations que vous essayez de leur enseigner.

Ensuite, vous utilisez les sessions en équipe pour discuter des problèmes liés au contenu. Vous devez identifier distinctement que les sessions d'équipe servent uniquement à discuter et à résoudre les problèmes liés au contenu uniquement.

Si vous fournissez des leçons à des personnes sur une base individuelle, vous pourrez peut-être éviter cet autre problème social dans lequel une seule question peut devenir la voix du groupe en tant que collectif et détourner l'attention du but réel des leçons.

Essayez d'abord de leur apprendre le design de la base de code, de les guider dans l'architecture, AVANT de commencer à regarder des exemples spécifiques. De cette façon, ils pourraient voir comment les exemples de code que vous examinez s'intègrent dans le tableau d'ensemble. Pensez à la structure de votre programme de formation. Et incluez la motivation commerciale derrière la conception.

J'ai passé plusieurs années à former d'autres développeurs et je ne me suis jamais penché sur le code avant de leur montrer comment le système était intégré. Ensuite, lorsque je leur ai demandé de faire des exercices de code dans le cadre, les questions étaient structurées et abordées.