2020-09-27

一流のバグ管理心得

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

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

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

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

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

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

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

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

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

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

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

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん