サン流だけど一流のバグ管理心得

ちがう、ちがう、ちがう。

バグポートフォリオをどうやって使うのかを、また説明しなきゃいけないようだね。もう毎回ずっと、ああもう、8年くらい？　リリースのたびに説明してこなかったっけ？

バグにそもそものプライオリティなんかないんだ。バグはプライオリティとともにうまれるわけじゃない。バグのプライオリティってのは、我々の決定なんだ。単なる技術的な決定じゃない。単なるバグの影響度でもない。単なる重大性でもない。バグは、リソース、ビジネス上の判断なんかによって、決定されるもんなんだ。

バグの優先度は、意思決定プロセスの結果なんだよ。つまり、どれがバグで、どれがバグじゃないのかって決めたことのね。

もし、あるバグを絶対、確実にFCSの前に直さなければならなくて、そいつがFCSの前に直っていないならば、絶対にその一つのバグが直されるまでリリースを止めなきゃいけない、それをP3としてマークするんだ。ベータ版のときもおんなじように、P2ってマークするんだ。どんなにP1バグってのが重大なものか理解できるだろ？

単に直したいってだけなら、それはP4バグなんだよ。

もし、P4バグを担当していて、それをFCSまでに直したい、でもそれを忘れないようにしたいってなら、「ターゲットリリース」のところに、それまでに直そうとするリリースのバージョンを書いておこう。

それで、もしそんなすぐに直したくないP4バグがあるなら、そう、それがP5バグがある理由なんだよ。

バグに変なキーワードを加えちゃだめだ。

これが900のバグを管理する方法なんだ。バグをカテゴリーにわけるのは管理できるようにしているんだ。注目に値するバグってのは、なにがなんでも絶対に直さなきゃならないもんだ。そういうバグが900よりも少ないくないっていうのなら、なんか深刻な問題があるってことなんだ。

バグを報告するときにおぼえておこう。バグを割り当てるときにおぼえておこう。バグを評価するときにおぼえておこう。もし、バグの優先度が正しいってことをコンスタントに証明できないのならば、管理もできない無数のバグで大混乱にみまわれることになるんだ。

あー、バグ一覧に、Glassfishにつっこむコンポーネント全部がはいってない。それもおんなじようにカウントする必要がある。

追記：inoueさんのご指摘に従って、いくつかの部分を修正しました。ありがとうございます。