質問(チームのカウボーイをコード化)を見つけましたが、私が抱えている問題よりも「忍者コーダー」に関連しています。
「Cowboy Coder」の純粋な実例であるチームメンバーがいます。人を変えることはできないと思いますが、「カウボーイコーダー」のように振る舞うのを止める方法はありますか?
彼はチームに耳を傾けることを拒否し、最近コードレビュー、ユニットテスト、実装の詳細の共有などを停止しました。
はい、彼は高速に「コーディング」しますが、彼のコードは単なるバグジェネレータです。他のチームメンバーと私は「バグ修正フェーズ」にあり、バグの80%は彼のコードに起因しています。私は彼のバグを修正したくありません。そして経営陣は盲目であるか、これを見たくないか、あるいはおそらく彼らは彼の「スピード」が好きです。
私(彼の上司ではなく年齢で若い同僚)がそれについて何かできる方法はありますか?
どうすればこのカウボーイコーダーを武装解除できますか?
私はプロジェクトを本当に気にかける最後の人のように感じます。
いくつかのオプションが表示されます:
彼はチームの話を聞くことを拒否し、最近コードレビュー、ユニットテスト、実装の詳細の共有を停止しました...
コードレビューでは、コーダーがレビューのために作品を提出する必要は必ずしもありません。
彼が何をしているかを追跡する簡単な方法は、VCSの履歴を監視し、チェックインを探すことです。彼のコードが心配な場合は、これで簡単に見つけることができます。差分の履歴を取得し、彼が何を入れたかを見て、赤い旗が飛び出していないか確認します。彼のチェックインを十分に速くキャッチし、問題が見つかった場合は、コミットをロールバックして、その旨をメールで送信できます。明らかに問題がある場合は、ジュニアコーダーであっても、チームメンバーを呼び出すことができます。
はい、彼は高速に「コーディング」しますが、彼のコードは単なるバグジェネレータです。他のチームメンバーと私は「バグ修正フェーズ」にあり、バグの80%は彼のコードに起因しています。私は彼のバグを修正したくありません。そして経営陣は盲目であるか、これを見たくないか、あるいはおそらく彼らは彼の「スピード」が好きです。
コードは要件からきています。要件により、要件が満たされていることを確認する実行可能なテストが実行されます。これらのテストはさらに細分化でき、変更が行われる前に記述して、変更が要件を満たしていることを確認できます(red-green-refactor、TDDの本質)。
チームのビルドサーバーに "コードカバレッジ"メトリックを追加します(うまくいけば、それができます。ない場合は、それが最初の問題です)。単体テストに合格したことを確認するだけでは、単体テストのない領域で作成された、彼の新しい非TDDのコードの問題は検出されません。すべての単体テストを実行した後、ビルドサーバーはすべてのコード行を実行するのが理想的ですが、実際には単体テストで実行できないことがいくつかあります。現実的には、95%以上のカバレッジを期待できるはずです(または特定のライブラリやファイルのタイプをカバレッジから除外します)。遅かれ早かれ、カウボーイはカバレッジレベルがしきい値を下回ったためにビルドを中断する何かをチェックインし、あなたは彼に電話をかけます。
そして、「速度」に関する限り、速度は物事を「完了」させる速度であり、正しく完了するまで「完了」することはありません。このようにしてマネージャに渡すことができます。マネージャーが彼のBMWにオイル交換を依頼したときに、オイルパンのプラグを戻すのを忘れ、その結果、ガレージから車で出る前に新しいオイルがすべて流出する自動車整備士を考えてみましょう。確かに、オイルの交換は5分しかかかりませんでしたが、マネージャーが車のエンジンが家に帰る途中に停滞したときは気にしません。彼はメカニックが一歩足りなかったことを気にかけます、それは彼が修正するために彼に多くの追加の時間とお金を費やすことになるでしょう。現在、彼は1人のカウボーイにお金を払って仕事を非常に速く行っており、それからチームの他のメンバーにかなり大きな額を支払って、仕事をやり直してもらいます。本当に、カウボーイに彼のことをさせ続けることの利点は何ですか?
私(彼の上司ではなく年齢で若い同僚)がそれについて何かできる方法はありますか?
彼を呼んでください。彼が失敗した何かを見つけたら、彼のコードがどのように失敗しているのか、最初に問題を回避できたはずの方法(適切な設計、TDD、コードレビューを含む)、および結果として何をしなければならない、またはする必要があるのかを見せてください。彼の壊れたコードを修正する。
私はプロジェクトを本当に気にかける最後の人だと感じています。
クラクション音が鳴り、ライトが点滅し、サイレンが鳴く-チームが作成したコードの品質を気にかけているのは自分だけだと本当に思う場合は、深刻な問題があります。チーム全体をドラッグして、優れたコーディングの時代に引きずり出そうとしていると感じ、それが重すぎて運搬できない場合は、ドロップしてください。社内で正しく機能している別のチームがいる場合は、転勤を依頼してください。
この1人の開発者から寄せられたバグ/問題の数に関する統計を使用して、管理に移動します。バグを修正するとチームの生産性に影響することを説明します。実際、問題の80%が1人からのものである場合、それは間違いなく対処する必要があります。彼らが同意できるように管理者に説明する限り(つまり、「時間の浪費はお金の浪費です」)、彼らは介入します。
また、この開発者は独自のバグ/問題を修正する必要があるため、これらの問題をそれらに割り当てると役立つ場合があります。あなたのチームはこの一人をカバーするべきではありません。
私(彼の上司ではなく年齢の若い同僚として)がそれについて何かできる方法はありますか?
仲間のプレッシャーと模範を示すことが唯一の良い方法です。最良の方法は、上司/リードによって行われます。あなたが彼らのボス/リードではない場合は、その人と話してください。しかし結局のところ、あなたではなく、世話をするのが彼らの仕事です。あなたが良い仕事をしていて、物事がうまくいく傾向があることを確認してください。
彼はチームの話を聞くことを拒否し、最近コードレビュー、ユニットテスト、実装の詳細の共有を停止しました...
レビュー、テスト、実装を通じて、コード化されたパスを文書化していませんか?そうでなければ、もっと広い問題があります。もしそうなら、これはエスカレーションする必要があるものです。