開発ライフサイクルとバグの意思決定

さて、バグ管理システムに登録されたバグは、開発ライフサイクルの中のどのタイミングで駆除対象のバグとして認識され、どのタイミングで駆除されるべきであろうか（バグの意思決定）。

例えば、ウォーターフォールモデルの場合は、多くの実装が実装工程で行われ、その後に結合し、テスト工程でテストが開始される。この場合は、通常テスト開始以降に、バグとしての意思決定がなされることになる。

テスト開始以降は、1週間に1回などのように、定期的な意思決定タイミングを設けることになるだろう。もちろん、致命的なバグについては、即刻駆除の検討を行う必要がある。ウォーターフォールモデルでの開発では、テスト工程でバグの駆除というコーディングも行う必要が出てくるため、ソースコードの管理と同じかそれ以上にバグ管理が重要になってくる。

反復型開発の場合はどうか。反復型開発では計画された短いサイクルでウォーターフォールモデルの工程を反復することになる。この場合は、より作業が簡素化される。テスト工程において発見したバグは、バグ管理システムに蓄積していくことができる。蓄積されたバグの意思決定のタイミングは、次の反復の開始時ということになる。次の反復の計画にどれくらいのボリュームのバグを駆除すべきかを決定することもできるため、プロジェクト管理という意味でも予測が行いやすい。

どちらにおいても言えることは、バグ管理システムが開発のライフサイクルにおいて、重要な位置を占めているということだ。さまざまなロール間において、バグという共通の敵を基点としてコミュニケーションとコラボレーションを最適化するのにも大いに役に立つ。

トリアージ

バグの意思決定を行うことをトリアージと言うことがある。もともとは医療用語であり、災害医療時に多くの傷病者を重症度合や緊急性により分別する方法を指す。この考え方をバグにも適用することができる。

新たな報告や再発したバグの状況を確認し、優先度の設定や駆除のタイミングを決定する。さらには、駆除を担当する開発者のアサインや、駆除対象のベースラインを決定することも含まれる。これがソフトウェア開発におけるトリアージだ。

トリアージを行うためには、バグの全容が把握できていなければならない。例えば、現時点でのバグの総数のうち「駆除済みのバグがどれくらい占めているか（進捗や品質の1つのも目安）」や「致命的なバグがどれくらいあるのか」といった内訳、チームの開発者が今どれくらいのワークロードで、すべてのバグを駆除しきることができるのかなどのバグの全容が把握できないことには、トリアージのプロセスはままならないのだ。 次のページ