問題（バグと機能）はプロジェクトの良い尺度になりますか？
私が取り組んでいるプロジェクトの1つは、問題の数によって測定されます。経営陣は、問題追跡システムにX個以下のバグとY個以下の機能が必要であるという任意の（私が知る限り）測定を行いました。
これは見当違いのアプローチのように思えますが、私はこの主題に関する文章を見つけることができないようです。
いいえ、そのような指標は絶対に逆効果です。この種のメトリックでは、人々は自分の仕事をうまく行う方法を考えるのではなく、メトリックのゲームに時間を費やします。
私は実際に、未解決のバグの最大数について契約が結ばれている状況を見てきました。その結果、ほとんどのバグレポートは偽の解決策で即座に閉じられました。
すべての問題が同じように作成されるわけではありません。些細な変更もあれば、複数開発者による複数週間のプロジェクトもあります。単純な発行数では、これらの要素は考慮されていません。
これは非常にばかげたことです。これは人々が問題を報告するのを思いとどまらせるので、問題は無視され、実際に彼らが悪く、日ごとに悪化しているとき、誰もが物事が良いふりをします。次に、混乱を回避します。経営陣が真実を語ったことで人々を罰することを決定したとき、それは行く時です。
バグと機能リクエストの数だけを追跡することは、私には良い考えではありません。私にとって、それは問題を報告する人々に依存しています。エンドユーザーによる新機能や、現場またはQAで見つかったバグがまったく必要ない場合、追跡されたバグはありません。作業量を見積もるために、パイプラインにバグまたは機能要求がいくつあるかを知ることは興味深いかもしれません。また、「X個以下のバグ」または「Y個以下の機能」という表現が気になります。 X個のバグがあり、別のバグが発見された場合はどうなりますか？または、Y機能と別のユーザーまたはクライアントが何か他のものを要求しますか？バグが閉じられるか、機能が完了するまで、これらを無視しないでください。
代わりに、メトリックで使用するための測定値としてバグレポートと機能リクエストを使用します。たとえば、報告されたバグを経時的に追跡します。内部テストが機能している場合、リリース後に報告されるバグの数は急増しないはずです。もう1つの例は、バグの修正や機能の作成にかかる時間を追跡することです。これにより、システムの保守性と拡張性に関する洞察が得られます。
受講した製品品質コースで引用されている資料を探していました。私はそれを見つけることができませんでしたが、私はこれらを見つけました 変更と欠陥の測定基準に関する注記 。これは興味深いかもしれませんし、機能要求とバグレポートに関するデータを使用して、プロジェクトに関するより信頼性が高く有効な情報を提供する方法についての洞察を得ることができます。
私はかつて、経営陣が進捗状況と生産性を追跡するための非常に精巧なシステムを導入していた会社で働いていました。ほぼ完全に変更管理とバグレポート項目に基づいています。それは悲惨な失敗でした：
例えば。非常にあいまいで再現が難しいバグに対処しなければならなかったプログラマーがいる可能性があります。そのため、1週間で「1項目」だけを解決しました。反対に、他の誰かが比較的簡単なアイテムに取り組んでいて、同じ週に「20アイテム」を解決した可能性があります。表面的には、これは2番目のプログラマーが「20倍生産的」だったように見えます。
さて、公平を期すために、これは実際には直接人々自体に報酬を与えたり罰したりするために使用されていませんでした。私たちの経営陣は、上記のシナリオが発生する可能性があることを理解するのに十分な技術を持っていました。しかし、それでも、メトリックが適切に設定されていることを考えると、何かに永遠に費やした場合、心理的に見た目が悪くなる傾向がありました。また、会社の特定の製品とコードベースは、他の製品よりも厄介なバグを生成する傾向がありました。または、作業は他の製品よりも予測可能でした。つまり、結局のところ、「数字」が他のグループやプログラマーの数字ほど良く見えなかったときに、人々の意欲を削ぐだけでした。
同じチームまたは会社の履歴データとの関連で考えると、追跡システムの問題の数とオープン/クローズの傾向は、プロジェクトのかなり良いステータスの指標である可能性があります。
ただし、問題の数を制限する指令を発行すると、悪用を招くだけです。不正な意図がなくても、人々はシステムをゲームします。バグは報告されないか、不適切に解決され、機能はスキップされるか、文書化されず、テスト/開発チーム間の摩擦が増大します。