Comment amener les gens à arrêter le bikeshedding (en se concentrant sur les futilités)?
J'ai été chargé d'enseigner aux autres équipes une nouvelle base de code, mais je continue de rencontrer un problème. Chaque fois que je vais réellement parcourir le code avec des gens, nous n'allons pas très loin avant que l'exercice ne se transforme en un bikeshedding (membres d'une organisation accordant un poids disproportionné à des questions triviales). Puisqu'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 il a été nommé ainsi, 10+ minutes pour débattre d'un nouveau nom)
Why is that an abstract base class rather than an interface? (2 minutes pour expliquer, 10+ minutes pour débattre des mérites relatifs de cette décision)
...etc. Maintenant, ne vous méprenez pas - de bons noms et une bonne conception cohérente sont importants, mais nous n'arrivons jamais à discuter de ce que le code fait ou de la façon dont le système est conçu de manière significative. J'ai fait un arbitrage en réunion pour sortir les gens de ces tangentes, mais ils sont partis - distraits par ce que le code sera/devrait être lorsque leur trivialité pour animaux de compagnie sera corrigée, et ils manqueront la vue d'ensemble.
Nous essayons donc à nouveau plus tard (ou avec une autre partie de la base de code) et comme les gens n'ont pas suffisamment de connaissances pour surmonter l'effet de bikeshedding, cela se répète.
J'ai essayé des groupes plus petits, des groupes plus grands, du code, du tableau blanc, des diagrammes visio, des murs de texte géants, en les laissant simplement argumenter à mort, en coupant court aux arguments immédiatement ... certains aident plus que d'autres, mais rien fonctionne . Enfer, j'ai même essayé de demander à d'autres personnes de mon équipe de l'expliquer parce que je pensais que je pouvais juste mal expliquer les choses.
Alors, comment éduquez-vous suffisamment les autres programmeurs pour qu'ils arrêtent de se concentrer sur les trivialités et puissent contribuer de manière significative à la conception?
Je pense que le problème est la tâche: "J'ai été chargé d'enseigner aux autres équipes une nouvelle base de code".
On vous a donné le mauvais travail, ou vous avez peut-être mal interprété le travail qui vous a été confié.
En présentant au niveau du code, vous invitez la réflexion au niveau du code.
Commencez au niveau du système et présentez la conception et les choix de conception qui ont été faits. N'autorisez pas une discussion approfondie: vous ne l'examinez pas. Autorisez les questions: vous voulez qu'ils comprennent le système. Si les gens "l'auraient fait différemment", tant mieux. Peut-être d'accord. Ou pas. Mais continuez. C'est comme ça en ce moment.
Lorsque vous arrivez au niveau du code, vous les aurez déjà amorcés avec la terminologie du système. Les noms (je suppose) auront du sens. Comme ci-dessus: pas de discussion approfondie, questions pour comprendre. Passez.
Maintenant, définissez certains problèmes de classe à résoudre. Comment pouvons-nous améliorer X? Choisissez quelque chose de non trivial qui "accompagne le flux" de la conception du système, et réfléchissez à ce que vous changeriez. Ils devraient obtenir la justification du système maintenant. Choisissez une autre amélioration qui pourrait briser le système si elle était mal faite, et montrez comment cela peut être fait correctement. Cela devrait être un moment Ah Ha pour eux. Certains pourraient même vous battre!
C'est un concert 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 qu'il y a un peu un sentiment de moi contre eux. "Fessez et recommencez. Nous supposons que ce sont des gens intelligents. Donnez-leur le défi de penser au niveau supérieur. Et divisez les groupes qui existent déjà en sélectionnant différentes sections d'équipes pour les nouvelles sessions.
"Garez-les". Au début de la leçon, expliquez de quoi vous allez 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 à autre chose. À la fin de la leçon, lorsqu'ils sont sur leur propre temps, pas sur le vôtre, regardez à quelle vitesse ces questions sont résolues.
Définissez correctement les attentes 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 assurez-vous également d'inclure vos objectifs, par exemple.
"... en examinant ce problème, assurons-nous de ne pas nous concentrer sur x, y et z. Assurez-vous également que nous ne regardons pas les détails d'implémentation tels que a, b, c ou des détails triviaux comme j, k, l. Je sais qu'il y a forcément beaucoup de détails dans le code et détaille les choses qui pourraient être adressées, améliorées ou standardisées, mais essayons d'abord de voir ce qu'il est vraiment en train de réaliser à un niveau supérieur "
Alors, comment éduquez-vous suffisamment les autres programmeurs pour qu'ils arrêtent de se concentrer sur les trivialités et puissent contribuer de manière significative à la conception?
Tout d'abord, ne considérez pas leurs préoccupations comme des "trivialité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 chacun sache:
- pourquoi vous rencontrez et
- ce que vous espérez en retirer
- combien de temps cela devrait durer
Énoncez ces choses de façon explicite et expliquez les objectifs.
Par exemple, vous pourriez dire: "Cette réunion est pour moi de vous familiariser avec le package Foo et comment il est utilisé dans notre module de reporting. Mon objectif est de vous faire comprendre suffisamment sur Foo pour que vous puissiez travailler sur le projet Bar Reports à venir la semaine prochaine. J'aimerais que nous ayons terminé dans les 90 prochaines minutes. "
Ensuite, lorsqu'un sujet revient, il peut se présenter comme suit:
Nouvelle personne: "Pourquoi FooWidget est-il implémenté comme motif de façade?"
Vous: "Eh 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 parfait. Sinon, et ça continue:
NP: "Ne pensez-vous pas que ce serait mieux de faire un 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 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 prévue que jusqu'à 11h00 et nous avons 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 raccourcir en "Cela sort du cadre de cette réunion".
Notez que vous dites pas "C'est stupide de s'inquiéter" 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 nécessaire.
Dans certaines organisations, vous ne pourrez jamais y parvenir. De nombreuses organisations accordent plus d'importance aux querelles politiques et aux escalades qu'aux capacités intellectuelles, à la diligence et à la loyauté. Et pourquoi pas. L'escalade met 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 cette lutte de pouvoir avec la résolution de problèmes réels, la pensée abstraite et la prise de décision sur des questions difficiles dont ils pourraient être responsables des conséquences plus tard, 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 indiquiez clairement, dans le contexte de votre organisation, si possible, que ces participants destin personnel dépend de leur compréhension, de leur contribution et de leurs efforts pour résoudre le vrai problème que vous essayez de résoudre. Si c'est l'architecture d'entreprise, exprimée dans cette base de code -errant et tous ses échecs, c'est tout. Expliquez-leur clairement qu'ils doivent fournir des informations significatives substantielles sur . Pas un autre hasard, qui se trouve être la bête noire d'une personne âgée ou autre et leur rapportera de bons points brownie en convenant avec ladite personne âgée.
C'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, malheureusement, contrôle les ingrédients bruts: le temps des employés; embauche et incendie, politique de salle de conférence, promotions, etc., etc. sérieusement, et cetera au nième.
Ce que vous appelez le bikeshedding, j'appellerais la conversion du flux de pensées de quelqu'un dans le nôtre. En discutant des noms, des modèles, ils apprennent à comprendre le code dans leurs propres termes et il n'y a aucun moyen de l'empêcher, c'est nécessaire.
En outre, il n'est pas nécessaire de parcourir une procédure très détaillée d'une base de code entière, car les détails seront oubliés bien avant de pouvoir y travailler.
Sur la base de ces deux idées, je suggère de diviser la base de code en unités et les apprenants en groupes de deux personnes. Pour chaque unité de code, chaque groupe aura, disons 25 minutes (dépend du LOC bien sûr), pour pouvoir faire 5-10 minutes présentation du code aux autres. Trois minutes de questions et répétez avec l'unité suivante. Expliquez est le mot clé; ils doivent s'assurer que les autres ont tout compris.
Vous ne seriez là que pour faire respecter le temps, aucun hors-sujet et contrôler l'unité n'a été suffisamment compris. Ils seront acteurs de leur apprentissage et se concentreront davantage 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é et conservé sur les documents partagés par l'équipe, afin qu'ils aient quelque chose de tangible à consulter à l'avenir. C'est bien aussi pour ancrer des souvenirs.
Désolé si vous avez déjà essayé ça ...
Essayez d'abord de leur enseigner la conception de la base de code, guidez-les dans l'architecture, AVANT de commencer à examiner des exemples spécifiques. De cette façon, ils pourraient voir comment les exemples de code que vous regardez s'inscrivent dans une plus grande image. Pensez à la structure de votre programme de formation. Et inclure la motivation commerciale derrière la conception.
J'ai passé plusieurs années à former d'autres développeurs et je ne suis jamais entré dans le code avant de leur montrer comment le système s'emboîtait. Ensuite, quand je les ai fait faire des exercices de code dans le cadre, les questions étaient structurées et sur le sujet.
Avez-vous essayé de faire des pré-leçons que les gens regardent individuellement?
Faites de courtes vidéos ou présentations qui expliquent le contenu, comment fonctionne le code, ou essentiellement tout ce que vous voulez leur enseigner dans un format où ils doivent le regarder 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 sont uniquement destinées à la discussion et au dépannage des problèmes liés au contenu.
Si vous fournissez les leçons aux gens sur une base individuelle, vous pourrez peut-être éviter cet autre problème social où 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.