パフォーマンスレビューの指標の一部として継続的なビルド結果を使用していますか？[閉まっている]

私の上司は、パフォーマンスレビュー（「品質」メトリック）の一環として、継続ビルド（コミットごとにテストをビルドおよび実行）のメトリックを使用することを計画しています。これは私にとって本当に悪い考えのように思えますが、誰かがこれを研究したか、以前に試したことを見たかどうかを知りたいです。

私の考えでは、テストが失敗することを恐れて、開発者が他の方法でテストするほど多くのテストを行わないようにします。彼は貴重な開発者ツールを開発者を打ち負かすための棒に変えていると感じています。

明白な反論は、人々がコミットする前により慎重になることを促進し、それにより品質が向上するということです。

私はここから離れていますか？パフォーマンスのレビューを行うべきかどうかの質問は別としてください。他の場所で回答されています。

パフォーマンスのレビューは問題ありませんが、次のような便利な指標はどうでしょうか。

• 機能の単体テストカバレッジの割合
• 締め切りに間に合わせる能力
• 明確で簡潔なドキュメント
• 適切なコーディング規則に従う
• 他の人とうまく通信する
• 要件とユーザーストーリーをタスクに変換する機能

これらは、パフォーマンスを測定するためにすべての良い方法が、経営陣は、これらは、彼らが実際に必要とすることにしていると持っているように見えるという問題です...うーん...よくyaは知っている... 実際の作業自分の一部にします。

残念なことに、ほとんどの経営陣は、「それについて地獄に行くには、実際に自分がしていることを追いかける必要がない指標で従業員を判断したい」という態度を持っています。

私の意見では、ここでシステムをゲーミングすることはかなり可能性があり、あなたの上司はそれが現実にならないようにする方法を見つけなければなりません。あなたが言及しなかった他のケースは、開発者が何回もコミットするため、ビルドのカウントが使用されるレビューの一部があるかのように、変更の数が比較的少ないこのチェックインの洪水がありますこれは、簡単に誤用される可能性がある新しいツールになる場所です。私は何かの名前が変更されたり、空白が変更されたりするチェックインを考えています。これはチェックインであり、生産性の何らかの形が教訓的なビューになると考えています。