バグの統計について

システムの開発の最後はもちろんリリースになります。システムそれぞれは異なりますが、基本的にいろいろ機能モジュールがあり、それぞれのモジュールの難易さや実装者の技術レベルが異なり、バグ回収作業のアサインは非常に重要なことになります。

たとえばシステム上で、A、B、C三つのモジュールがあり、リリースする際Aというモジュールだけバグが多くて、BとCのバグがゼロでも結局全体リリースできなくなってしまいます。

それを回避するのに、バグ改修フェースでPMはリリースの割り当てやスケジュールの調整が必要です。調整の根拠は何でしょうか、答えはバグ統計と思われます。

バグ統計は、システムのテストが開始するから終了するまで、毎日各モジュールの残っているバグ数をエクセルなどのツールで記入して、毎日の点を線で接続してからバグ数遷移グラフになります。

そのバグ数グラフを見ると、通常テスト開始するときに、バグ数はUP、修正作業を始めている且つうまくいけるであれば、バグの線は水平線、バグ数は減るのであれば、該当モジュールは近いうちにリリースできると思われます。

システム全体リリースの日でバグ数はすべてゼロに達す必要があり、そうするとモジュールごとにバグ数によって、バグ改修の人員割り当てができます。例、システムにA,B,C三つのモジュールがあり、あるタイムでAのトレンドはずっとUP、Bは水平、CはDOWNのであれば、Aはリリースするまでバグ改修できないリスクがあるということがわかったので、バグ改修が終了トレンドがあるCの担当者の一部をAモジュールバグ改修作業を移すことは対策のひとつのことはわかります。

張