2

開発チームのメンバーから意図しない結果をもたらさないバグの原因を追跡または測定する方法はありますか？最近、追跡システムにバグの原因を割り当てる機能を追加しました。原因の例としては、不正なコード、欠落したコード、不完全な要件、欠落した要件、不完全なテストなどがあります。開発チームからの意図しない動作につながることがわかったため、私はこれを支持していませんでした。現在まで、このフィールドはチームメンバーから隠されており、積極的に使用されていません。

現在、私たちは通常よりも多くのバグを抱えているプロジェクトの真っ最中です。この種の情報は、どこが間違っていたのか、将来どこで改善（または調整）できるのかをよりよく理解するために持っておくとよいでしょう。今）。バグの原因に関する適切なデータを取得するには、このフィールドを開いてdevおよびqaチームのメンバーが入力できるようにする必要があります。これにより、動作が悪くなるのではないかと心配しています。たとえば、自分が作成しなかった欠陥を修正したくない場合は、パフォーマンスへの反映が不十分であると感じたり、同様の理由で欠陥の分類について議論する時間を無駄にしたりする場合があります。

誰かが悪い行動を引き起こすことなくこのタイプの追跡を行うメカニズムを見つけましたか？データの背後にある理由をチームに説明すると、チームメンバーから有用なデータを期待できますか（個々のパフォーマンスメトリックを駆動するのではなく、プロジェクトの成功メトリックを駆動するため）？この種のことを行うための別のより良い方法はありますか（おそらく、よりアドホックな事後分析または問題に関するオープンな議論）？

4

2 に答える 2

1

多くのバージョン管理パッケージには、のようなものがありsvn blameます。これはバグを追跡するための直接的な指標ではありませんが、重大なバグが含まれているリリースへの変更を誰がチェックインしたかを知ることができます。

http://www.bugzilla.org/のような、時間の経過とともに物事を追跡するのに役立つプログラムもあります。

しかし、バグが存在する理由を実際に掘り下げる限り、確かに調査する価値がありますが、その情報を収集するための標準的なメトリックを提供することはできません。システムが非常にバグがある理由はいくつかあります。

  • 不十分に書かれた仕様
  • 急いでタイムライン
  • 低スキルプログラミング
  • 士気が悪い
  • ベータテストまたはQAテストの欠如
  • ベータテストまたはQAテストを実行できるようにソフトウェアを準備していない
  • バグのクリーンアップと新機能のリリースに費やされた時間の比率が低い
  • バグのない拡張機能を作成するのに費やした時間と機能を引き出すのに費やした時間の比率が低い
  • 壊れやすい非常に複雑なシステム
  • マシン管理など、コードベース外の変化する環境
  • プログラマーの報酬や昇進に影響を与える間違いのせい

ほんの数例を挙げると...バグが多すぎることが大きな問題である場合は、管理者とリードプログラマー、およびプロセス全体の他の利害関係者が座って問題について話し合う必要があります。

于 2010-07-14T20:00:35.780 に答える
0

バグ率が高い場合は、スケジュールが急ぎすぎたり、柔軟性がなかったりすることを示している可能性があります。ゼロディフェクトアプローチに切り替えると役立つ場合があります。新しいコードで作業する前に、すべてのバグを修正してください。

理由を割り当てることは、問題のある領域があるかどうかを確認するための優れた手法です。私が見たり遭遇した典型的な指標は、次のようにさえ分かれています。

  • 仕様エラー（欠落、不正確など）
  • アプリケーションのバグ（誤ったコード、欠落したコード、不良データなど）
  • 不正確なテスト/エラーなし（一般的に不正確な期待、または仕様がまだ実装されていない）

欠陥の原因を調べて確認すると便利です。

于 2010-07-14T20:19:46.507 に答える