TOPシステム開発> 第2回:開発チームにおけるバグの扱い方 (2/3)




バグ管理再考のススメ - TFSの場合

バグ管理再考のススメ - TFSの場合

第2回:開発チームにおけるバグの扱い方

著者:マイクロソフト 長沢 智治

公開日:2008/03/11(火)

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

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

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

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

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

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

図2:反復型開発とトリアージのタイミングの関係
(画像をクリックすると別ウィンドウに拡大図を表示します)

トリアージ

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

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

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


前のページ  1   2  3  次のページ


マイクロソフト株式会社 長沢 智治
著者プロフィール
マイクロソフト株式会社  長沢 智治
ソフトウェア開発業務改善のプリンシパル コンサルタントやソリューション アーキテクトとして多くの多種多様なソフトウェア開発の現場のお手伝いを経験。2007年1月よりマイクロソフトのエバンジェリストとして、特にチーム開発の訴求を行うべく活動中。
ブログ「長沢智治のライフサイクルブログ」
http://blogs.msdn.com/tomohn


この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。

INDEX
第2回:開発チームにおけるバグの扱い方
  バグとして認識するタイミング
開発ライフサイクルとバグの意思決定
  MSFにおけるトリアージ
バグ管理再考のススメ - TFSの場合
第1回 バグのライフサイクルを理解する!
第2回 開発チームにおけるバグの扱い方
第3回 バグが開発者と開発チームメンバーをツナグ!
第4回 バグを作り込む前に開発者にできること
関連記事
今こそ聞きたいVisual Studio 2008の基礎の基礎