カウボーイコーダーをどのように武装解除しますか？[閉まっている]

私は質問（チームのコードカウボーイ）を見つけましたが、それは私が抱えている問題よりも「Ninja Coder」に関連していました。

「カウボーイコーダー」の純粋に生きた例であるチームメンバーがいます。人を変えることはできないことを理解していますが、彼が「カウボーイコーダー」のように振る舞うのをやめる方法ですか？

彼はチームの意見を聞くことを拒否し、最近、コードレビュー、ユニットテスト、実装の詳細の共有などを停止しました。

はい、彼は高速に「コーディング」しますが、彼のコードは単なるバグ生成プログラムです。他のチームメンバーと私は「バグ修正フェーズ」にあり、バグの80％は彼のコードに起因しています。私は彼のバグを修正したくありません。そして、経営陣は盲目であるか、これを見たくないか、多分彼らは彼の「スピード」を好む。

私（彼の上司ではなく、年齢の若い同僚として）がそれについて何かできる方法はありますか？

このカウボーイコーダーを武装解除するにはどうすればよいですか？

私はこのプロジェクトを本当に気にかけている最後の人だと感じています。

いくつかのオプションがあります：

• 懸念事項についてコーダーにアプローチしてください。特定のポイントで建設的な批判として行われなければなりません。より大きな一歩を踏み出す前に、懸念を直接かつプライベートに提起して、その人に変化の機会を与えることが適切です。
• 情報と統計を収集し、管理者に提供します。経営陣は気にかけないように見えるかもしれませんが、うまくいく場合にはとにかく努力をすることがしばしば重要です。考えられる否定的な結果には、経営陣への苦情を認めない他者の疎外が含まれます。
• カウボーイコーダーの仲間を見つけて、プライベートで議論してください。彼/彼女は、その人に聞いてもらうより良いチャンスを持っているかもしれません。
• 別のチームで作業するよう依頼してください。問題は解決しませんが、正気を保ちます。少なくともあなたの能力を最大限に発揮し、あなたを引きずり込まないでください。
• 誰も聞かない場合は組織を離れます。悪い環境のようですね。

彼はチームの意見を聞くことを拒否し、最近、コードレビュー、ユニットテスト、実装の詳細の共有を停止しました...

コードレビューでは、必ずしもコーダーがレビューのために作品を提出する必要はありません。

彼がしていることを追跡する簡単な方法は、VCSの履歴を監視して、チェックインを探すことです。彼のコードが心配なら、これを見つける簡単な方法です。diffの履歴を取得し、彼が何を入れたかを見て、赤旗が飛び出すかどうかを確認します。彼のチェックインを十分な速さでキャッチし、問題が見つかった場合は、コミットをロールバックしてその旨をメールで送信できます。明らかに間違っていることがわかった場合は、ジュニアコーダーであっても、仲間のチームメンバーを呼び出すことができます。

はい、彼は高速に「コーディング」しますが、彼のコードは単なるバグ生成プログラムです。他のチームメンバーと私は「バグ修正フェーズ」にあり、バグの80％は彼のコードに起因しています。私は彼のバグを修正したくありません。そして、経営陣は盲目であるか、これを見たくないか、多分彼らは彼の「スピード」を好む。

コードは要件に基づいています。要件は、要件が満たされていることを検証する実行可能なテストになります。これらのテストはさらに細分化することができ、変更が要件を満たしていることを確認するために、変更が行われる前に記述することができます（赤緑リファクタリング、TDDの本質）。

「コードカバレッジ」メトリックをチームのビルドサーバーに追加します（できれば、それがあればいいのですが、そうでなければ、それが最初の問題です）。単体テストの合格を確認するだけでは、単体テストのない領域で作成された彼の新しい非TDDコードの問題をキャッチできません。すべての単体テストを実行した後、ビルドサーバーは理想的にはすべてのコード行を実行する必要がありますが、実際には単体テストではできないことがいくつかあります。現実的には、95％以上のカバレッジを期待できます（または特定のライブラリまたはファイルの種類をカバレッジから除外します）。遅かれ早かれ、カウボーイはカバレッジレベルをしきい値以下に落としたため、ビルドを壊す何かをチェックインし、あなたは彼を呼び出します。

また、「速度」に関する限り、速度とは、物事を「完了」させる速度のことであり、正しく完了するまで「完了」しません。この方法でマネージャーにそれを置くことができます。ある自動車整備士が、マネージャーがBMWをオイル交換のために持って行ったときに、オイルパンプラグを元の位置に戻すのを忘れ、その結果、ガレージから出て行く前に新しいオイルがすべて流出します。もちろん、オイル交換には5分しかかかりませんでしたが、マネージャーは車のエンジンが家に帰る際に気にすることはありません。彼はメカニックがステップを逃したことを気にします。それは彼が修正するために多くの追加の時間とお金を費やすことになります。今、彼は本当に速く仕事をするためにカウボーイを1人払っている。sチームの残りのメンバーに非常に大きな金額を支払い、仕事を正しくやり直します。カウボーイに自分のことをさせ続けることの利点は、本当に何ですか？

私（彼の上司ではなく、年齢の若い同僚として）がそれについて何かできる方法はありますか？

彼を呼び出します。あなたが彼が台無しにしたものを見つけたら、彼が彼のコードがどのように失敗したか、彼がそもそも問題をどのように防ぐことができたか（適切な設計、TDD、コードレビューを含む）とあなたが結果として何をするか、またはする必要があるかを彼に示す彼の壊れたコードを修正します。

私はこのプロジェクトを本当に気にかけている最後の人だと感じています。

クラクションが鳴り響き、ライトが点滅し、サイレンが泣き叫ぶ -チームが作成したコードの品質を気にかけているのが自分だけであると本当に感じている場合、深刻な問題があります。チーム全体を蹴って叫ぶことを優れたコーディングの時代に引きずり込んでいると感じ、それが重すぎて運搬できない場合は、ドロップします。会社に別のチームが適切に行っている場合は、異動を求めます。

この1人の開発者から寄せられたバグ/問題の数に関する統計情報を管理に移動します。バグを修正すると、チームの生産性に影響することを説明します。実際に問題の80％が1人の人から生じている場合は、間違いなく対処する必要があります。経営者に同意できる条件（つまり、「時間の浪費は金の浪費」）で説明する限り、彼らは介入します。

また、この開発者は独自のバグ/問題を修正する必要があるため、これらの問題を割り当てることが役立つ場合があります。あなたのチームはこの一人をカバーすべきではありません。

私（彼の上司ではなく、年齢の若い同僚として）がそれについて何かできる方法はありますか？

仲間からの圧力と例による指導が唯一の良い方法です。最良の方法は上司/リードによって行われます。あなたが彼らのボス/リードでない場合は、その人と話してください。しかし、最終的にはあなたの仕事ではなく、それを大事にするのが彼らの仕事です。あなたが良い仕事をしていて、物事がうまくいく傾向があることを確認してください。

彼はチームの意見を聞くことを拒否し、最近、コードレビュー、ユニットテスト、実装の詳細の共有を停止しました...

レビュー、テスト、実装によるコードの文書化されたパスがありませんか？そうでない場合は、より広範な問題を抱えています。そうした場合、これはエスカレートする必要があるものです。