スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

バグの優先順位が致命的とかでいいのだろうか? 

多くのバグトラッキングシステムにはそれぞれのバグに対して 優先順位がつけられるようになっています。致命的とかshowstopperとか criticalなどのような順位を見たことがある人も多いと思います。 バグの優先順位をつけるときに迷われたことはありませんか?私はあります。

 

そもそも優先順位というのは何の優先順位なのでしょう。ハングアップして しまうものを1、ハングアップはしないものの、プロダクトとして致命的なものを 2というような順位をつけた場合、「みられまくっちゃ」と入力するとハングアップ する不具合と30秒で通話が途切れてしまう不具合があればどちらを 優先して対応すべきでしょうか?30秒で切れたらかけ直せばいいだけだから ハングアップを先に直そうという判断をするプロジェクトは無いと私は信じています。

 

プロジェクト終了後、今回はたくさんハングアップがでたな、と眺めるための ものだと割り切ってしまえばそれでおしまいですが、プロジェクトの運営に なんらかの影響を与えるものだとすればこのような優先順位のつけ方は あまり有効でないように思えます。

 

通常のプロジェクトではバグが発見された場合に最初に判断されるべきは 修正されるべきか、そうでないかです。別の言い方をすれば 修正する許可が得られる(Do)か保留される(Pendingかです。極論すれば優先順位は この2つでよいと言えるでしょう。これ以上の細分化はプロジェクトの 運営形態などを考慮して行われるべきです。

 

比較的一般的な細分化の例としては修正許可は得られていて 期日までに対応しなければならないものとそうでないもの という分け方があります。この場合だとHigh,Low,Pending という優先順位でしょうか。このような優先順位付けであれば プロジェクト運営においてバグ管理データベースから得られる情報 がどのように活用されるべきかは明確になります。重要なのは 優先順位がきちんとMECEになっていることだと思います。


コメント

コメントの投稿















管理者にだけ表示を許可する

トラックバック

この記事のトラックバックURL
http://ochoo.blog48.fc2.com/tb.php/70-961d9fe1

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。