unoh.github.com

バグの状態でプロジェクトの状態を知る

Tue Jul 11 03:29:01 -0700 2006

こんにちは!やまもと@テスト番長です。

以前バグのステータスというのを書いたのですが、その最後の方で続きがあるようなことを申したら、気になるから教えろという奇特な方がいらっしゃいましたので今回は続きを書いてみましょう。

BTSはバグを管理するだけの道具ではありません。バグを追いながら適切に記録をつけて統計を取ることで、プロジェクトやチームの状態を知ることが出来ます。例えば、以下のような事象です。(なお、WEBアプリが前提)


・バグの報告数が増えず、結果がVERIFIEDになることが多い。
→まだデバッグが始まったばかりのプロダクトか、慎重過ぎるテスターがアサインされています。

・バグの報告数が少なくなり、VERIFIED以外の結果が目立つ。
→デバッグは最終段階を迎えています。もしもまだ納期前ならば、それなりに上手く行ったプロジェクトでしょう。

・NEWが発生してからRESOLVEDになるまでの平均時間が長い。
→バグに対してプログラマのパワーが不足しているかもしれません。過酷な労働を強いないようにしましょう。

・REOPENDになる割合が増加している。
→初期デバッグであったり、新人プログラマをアサインした後などはこの割合が増加します。プロダクトに慣れて理解が深まれば減っていくはずのものですが、理由無く増えているならばプログラマのモチベーションや労働環境が悪化していないか気をつけた方が良いです。

・結果ステータスの中で、INVALID、DUPLICATEの割合が多い
→未熟なプロジェクトマネージャが犯しやすいミスの一つに、プロジェクトの最終段階で素人テスター(報告者)を大量投入してデバッグしようとする行為があります。そんなときにはINVALID、DUPLICATEの割合がどっと増えます。無駄な報告を裁く為にパワーを使ってしまっていませんか?
レアケースですが、発注者が複数の重層構造になっている場合もこうなることがあります。

・FEEDBACKになるNEWが多い
プログラマとテスターのコミュニケーションは取れているでしょうか?FEEDBACKは不慣れなテスターがいたり、バグ報告を厳密に行うルールにしたりすると多く発生しますが、コミュニケーションさえ円滑に取れていれば多少のことは直接話し合えば済むはずです。それ以外に、プログラマのモチベーションが低いケースもあります。なかなか修正したがらないようなケースです。

・SUSPENDEDが全体の1/4以上ある。
プロマネがミスを犯してプロジェクト進行上のトラブルが発生し回り道しているか、プログラマのモチベーションが低いか、上層部から何が何でもアクティブなバグ数を減らすようにと強引な指示が出て退避されています。

・WONTFIXが目立つ。
もしプロジェクトの完全終了直前でなければ、プロジェクトチームに熱意が不足しているか、開発費が不足しているか、そのプロダクトのバージョン2の計画が既に立ち上がっていませんか?

・NOT FIXABLEが目立つ。
もしプロジェクトの完全終了直前でなければ、プロジェクトチームに技術が不足しているか、開発費が不足しているか、ITリテラシーの低い発注元が無茶な要求をしていませんか?

・ASSIGNEDへのチェンジ回数がバグ数の1.4倍以上ある。
バグ修正がたらいまわしになっていませんか?もしくは、過酷な労働条件に耐えかねたプログラマが夜逃げして、何も知らない哀れな後釜に全てを託したりしませんでしたか?


上記は状況判断に使える系の見方ですが、
役に立たない&有害な「間違った情報の見方」もありますので、そっちも少し書いてみます。

・ASSIGNEDからRESOLVEDへ移行する時間を気にする。
→要は修正にかかったコストだろうと、これを個人や組織の能力の指標にしようという輩がたまにいますが、バラツキが大きい数字なのでちっとも参考になりません。少なくともREOPENDの時間も足さなくては意味が無いことくらい気付いて欲しいものですね。

・NEWの個数が少ないのを気にし過ぎる。
→デバッグが進行していることのある程度の指標にはなりますが、報告を増やすだけなら幾らでもやりようがあるので不毛です。逆に、自然な状態を観測することが有益です。

・RESOLVEDが減らないのを気にする。
→結果が出てバグ処理が終らないと落ち着かない気持ちは分かりますが、検証の難しいバグもあります。そしてここで確認されたものは以後監視されないわけですから、慌てさせてチェックの手を抜くべきではないのです。「バグを3つ直すと1つバグが生まれる」という諺もあるとか。


さて、お楽しみ頂けましたでしょうか?
ウノウくらいの規模のチームですと、こういった判断方法を使わずとも雰囲気で判るのですが
大所帯で色々上手くいかないという職場にお勤めの方はご参考にしてください。
数値で可視化可能なので、直訴の材料なんかにも使えますよ?