どうやってバイクシェッドをやめさせるのですか（些細なことに焦点を当てる）？

私は他のチームに新しいコードベースを教えることを任されてきましたが、私は問題に直面し続けています。私が実際に人々と一緒にコードを調べに行くときはいつでも、全体の運動が自転車脱落（些細な問題に不均衡な重みを与える組織のメンバー）運動に移るまで、それほど遠くはありません。彼らはコードベースを知らないが、それを改善するのを助ける必要があると思うので、彼らは理解できることに集中します：

Why is that named that? _{（その名前が付けられた理由を説明するのに2分、新しい名前を議論する10分以上）}

Why is that an abstract base class rather than an interface? _{（説明するのに2分、この決定の相対的なメリットを議論する10分以上）}

...等々。今、誤解しないでください-良い名前といい、一貫性のある設計が重要であるが、我々は、コードが実際にどのような議論に取得することはありませんし、システムが何らかの意味のある方法で設計されていたりする方法。私は、これらの接線から人々を引き離すために審判会議をいくつか行ってきましたが、彼らはいなくなりました-彼らのペットの些細さが修正されたときのコードがどうなる/はずであることに気を取られ、彼らはより大きな姿を見逃しています。

そのため、後で（またはコードベースの別の部分で）再試行します。人々は、バイクシェッド効果を克服するのに十分な知識を持っていなかったため、繰り返します。

私はいくつかは、他のものよりを助ける...短いすぐに引数を切断、死にそれを主張し、それらをさせる、小さなグループ、大きなグループ、コード、ホワイトボード、Visioの図、テキストの巨大な壁を試してみたが、何も働きません。地獄、私はチームの他の人に説明してもらおうとさえしました。

それでは、他のプログラマーを教育して、些細なことに固執するのをやめ、設計に有意義に貢献できるようにするにはどうすればよいでしょうか？

問題は、「他のチームに新しいコードベースを教えることを任されている」ことだと思います。

間違った仕事を与えられたか、与えられた仕事を誤って解釈した可能性があります。

コードレベルで提示することにより、コードレベルの思考を促します。

システムレベルで開始し、設計および設計の選択を提示します。長時間の議論を許可しないでください。あなたはそれをレビューしていません。質問を許可してください。あなたは彼らにシステムを理解してもらいたいのです。人々が「違ったやり方でやればよかった」としたら、結構です。たぶん同意します。か否か。しかし、先に進みます。それが今のやり方です。

コードレベルに到達した時点で、システム用語で既に準備されています。名前（私が推測する）は理にかなっています。上記と同じ：拡張討論なし、理解のための質問。進め。

次に、クラスの問題を解決するように設定します。どうすれば拡張Xを作成できますか？システム設計の「流れに沿った」自明ではないものを選択し、変更する内容を検討します。彼らは今、システムの理論的根拠を得ているはずです。間違った方法でシステムを破壊する可能性のある別の拡張機能を選択し、正しく実行できる方法を示します。それは彼らにとってはアーハの瞬間であるべきです。いくつかはあなたにそれを打ち負かすかもしれません！

特にあなたが持っていた間違ったスタートの後、それは厳しいギグです。すでに多くの時間と労力を費やしているように聞こえます。「うんざりして、やり直してください。彼らは賢い人だと思います。より高いレベルで考えるという課題を与えます。そして、新しいセッションのためにチームの異なる断面を選択することにより、既存のグループを分割します。

「パーク」。レッスンの開始時に、何を議論するかを説明し、オフトピックと見なされるものを明確に説明します。明らかにOTである質問をされたら、そう言って先に進んでください。彼らがそれに戻ってきたら、後の議論のためにホワイトボードに質問を書いて（これは重要です）先に進みます。レッスンの終わりに、あなたではなく自分の時間になったら、これらの質問がどれだけ早く解決されるかを見てください。

期待を正しく設定し、正直でオープンかつ率直になります。

目標がオープンで透明であることを確認してください。

andy256（+1）によって促進されるような高レベルのビューで議論を始めますが、目的を含めることも確認してください。

「...この問題を見て、x、y、zに焦点を合わせないようにします。a、b、c、または些細な詳細などの実装の詳細を見ないようにします。 j、k、lのように、コードには多くの詳細があり、対処、改善、またはより標準化できる事項を詳細に定義する必要があることはわかっていますが、実際に達成していることを最初に見てみましょう」

それでは、他のプログラマーを教育して、些細なことに固執するのをやめ、設計に有意義に貢献できるようにするにはどうすればよいでしょうか？

まず、彼らの懸念を「自明」または「自転車脱落」と考えないでください。それらは判断の言葉であり、彼らはin辱しています。彼らの懸念は有効です。現時点では重要ではありません。

良いミーティングの鍵は、誰もが知ることです：

• なぜ会議をしているのか
• あなたがそれから抜け出すことを望むもの
• どれくらい続くか

これらのことを前もって明示的に述べ、目標を説明してください。

たとえば、次のように言うことができます。「この会議は、Fooパッケージとレポートモジュールでの使用方法を理解するためのものです。私の目標は、Fooについて十分理解して、Bar Reportsプロジェクトに取り組むことができるようにすることです来週。次の90分で私たちを終わらせたい」

次に、トピックが表示されると、次のようになります。

新しい人：「FooWidgetがファサードパターンとして実装されているのはなぜですか？」

あなた：「まあ、それは（設計決定の簡単な説明）または「わからない」ためだと思う。

答えが十分であれば、それは素晴らしいことです。そうでない場合、それは継続します：

NP：「シングルトンとしてやったほうがいいと思いませんか？」

あなた：「私はそれについて本当に考えていませんでしたが、私はFooWidgetがどのように機能するかを説明しながら前進し続けたいです。」

NP：「しかし、それがシングルトンとして行われた場合、私たちはできる-」

あなた：「ごめんなさい。しかし、FooWidgetの仕組みに焦点を当てておく必要があります。この会議は11:00までしかスケジュールされておらず、やり遂げることがたくさんあります。 」

それを1、2回行った後、「この会議の範囲外です」と略すことができます。

「心配するのはつまらない」、「関係ない」、「黙る」、「入力するのがあまりにも新しい」などと言っていないことに注意してください。あなたは単に、何を成し遂げる必要があるのか​​、そして時間を費やすだけに会議の焦点を合わせています。

特定の組織では、これを達成することはできません。多くの組織は、知的能力、勤勉、忠誠心よりも政治的論争や梯子登りを重視しています。そして、なぜそうならないのでしょう。ラダークライミングは人々を権力の地位に置き、裁量的な収入で個人の生活を向上させ、決して時代遅れになることはありません。

この力の争いを実際の問題解決、抽象的思考、そして後の結果に責任があるかもしれない困難な問題についての決定と比較してください。

私が提案する唯一のアドバイスは、可能であれば、これらの参加者の個人的な運命は、あなたが解決しようとしている実際の問題に対する理解、貢献、および努力に依存することを組織の文脈で明確にすることです。これがエンタープライズアーキテクチャであり、この-errant-codebaseとそれがすべて失敗した場合、それだけです。彼らは周りに実質的意味の入力を提供しなければならないことを彼らにそれを明確にすること。他のランダム性ではありませんが、それはたまたま先輩のペットのぞき見であり、先輩の先輩に同意することで素敵なブラウニーポイントを獲得します。

高齢者は通常、進行中のテクノロジーを理解しておらず、興味がなく、残念ながら、原料を制御しているため、これはしばしば困難です。従業員の時間。雇用と消防、会議室の政治、プロモーションなど、真剣に、などなど。

あなたがbikesheddingと呼ぶものは、私は誰かの思考の流れを私たち自身のものに変換すると呼びます。名前、パターンについて議論することで、彼らはコードを独自の用語で理解するようになり、それを防ぐ方法はありません。それが必要です。

それに加えて、コードベース全体を詳しく説明する必要はありません。詳細に取り組む前に詳細が忘れられてしまうからです。

これら2つのアイデアに基づいて、コードベースをユニットに分割し、学習者を2人のグループに分割することをお勧めします。コードの各ユニットについて、各グループは、たとえば25分（もちろんLOCに依存）を持ち、他の人にコードを5〜10分間ウォークスルーできるようにします。3分間の質問と次の単元で繰り返します。説明がキーワードです。他の人がすべてを理解していることを確認する必要があります。

あなたは時間を強制するためにそこにいるだけで、トピックを無視してユニットを十分に理解していません。彼らは学習の主体になり、自転車を流すよりも他の人に説明することに集中します。

コード単位の高レベルの手書きスキーマが必要になる場合があります。これはコピーしてチーム共有ドキュメントに保存されるため、将来参照できる具体的なものがあります。それも思い出を定着させるのに良いです。

既に試してみたらごめんなさい...

人々が個別に見直す事前レッスンを試みましたか？

コンテンツ、コードの仕組み、または基本的にそれらを教えるために必要なすべてを説明する短いビデオまたはプレゼンテーションを作成し、自分でそれを見て、教えようとしている情報を学習します。

次に、チームベースのセッションを使用して、コンテンツに関連する問題について話し合います。チームセッションは、コンテンツのみに関連する問題の議論とトラブルシューティングのためのものであることを明確に識別する必要があります。

個々の人にレッスンを提供する場合、単一の問題が集合体としてグループの声になり、レッスンの実際の目的からそらすことができる他の社会問題を避けることができるかもしれません。

特定の例を見る前に、最初にコードベースの設計を教え、アーキテクチャ全体をガイドしてください。そうすれば、彼らはあなたが見ているコード例がどのように全体像に適合するかを見るかもしれません。トレーニングプログラムの構成について考えてください。また、設計の背後にあるビジネスの動機を含めます。

私は他の開発者のトレーニングに数年を費やしましたが、システムがどのように適合するかを示す前にコードに出たことはありませんでした。その後、フレームワークでコードの練習をしてもらうと、質問は構造化され、トピックに沿ったものになりました。