BTSはバグを管理するための道具ですが、
普段から作業記録を残すように運用しておけば、
BTSに溜まったデータからわかること
BTSのチケットには作成日時、
マネージャ視点での読み取り
では、
- 報告されるバグの数が少なく、
処理がRESOLVEDになることが多い - 開発者によるテストのみで検証が十分にされていないか、
テスターがいる場合は慎重なテスターがテストしているときこの状態になります。顕在化するバグの数が少ないからといって品質が良いとは限りません。 - 報告されるバグの数が収束し、
RESOLVED以外の結果が目立つ - デバッグは最終段階を迎えています。もしもまだ納期前ならば、
それなりに上手く行ったプロジェクトでしょう。ただし、 派遣会社から調達した経験の浅いテスターをアサインしたなら話は別です。 - NEWからRESOLVEDになるまでの平均時間が長い
- バグが報告されてから修正されるまでの時間が長いなら、
プログラマが不足気味ではないか検討してみる必要があります。また、 チケットの粒度が問題で処理しにくい状態になっている可能性も考えられます。 - REOPENDになる割合が増加している
- 検証に回ったものが頻繁に差し戻されるのは、
何かしらバランスの悪い状態であることを示しています。また、 新しいメンバーが追加されたときなどこの割合は自然に増加します。そのときはプロダクトに慣れて理解が深まれば減っていくのですが、 理由なく増えているならば、 プログラマのモチベーションやチームワークが悪化していないか気をつけた方が良いでしょう。 - INVALID、
DUPLICATEの割合が多い - 未熟なマネージャが犯しやすいありがちなミスの1つに、
最終段階で素人テスターを大量投入してデバッグしようとする行為があります。どこも人手不足ですから、 急に借り出せる人材イコール他で不必要な人材ということです。無駄なチケットを処理するために貴重な時間が失われ、 泥沼になるのはよくあることです。気をつけましょう。 - NEWからFEEDBACKになるケースが多い
- BTSへ不具合を報告する際は、
再現手順などが正確に伝わるよう気をつけなくてはいけません。FEEDBACKは不慣れなテスターがいる場合など基本的に情報が足りないときのステータスですが、 プログラマとテスターのコミュニケーションが取れているかも問題になっていることがあります。コミュニケーションさえ円滑に取れていれば多少のことは直接話し合えば済むはずですが、 敵対関係になっていると問題が生じます。プログラマのモチベーションが低く、 なかなか修正したがらないケースもありえます。 - SUSPENDEDが全体の1/
4以上ある・ SUSPENDEDになったままの期間が長い - 保留というステータスは必要不可欠ですが、
使い過ぎは感心できません。本来、 先方の連絡待ちになっている場合などに使うべきですが、 面倒なチケットを退避しておくために、 何かと理由をつけて保留されることもあります。あまり多くなっている場合は原因を取り除く必要があります。 - ASSIGNEDへのチェンジ回数が多い
- バグ修正がたらいまわしになっていませんか？
- デスマーチに耐えかねたプログラマが続々雲隠れして、
急遽採用した新人に全てを託したりしませんでしたか？
テスター視点での読み取り
テスターも単純にバグを報告するだけでなく、
- WONTFIXが目立つ場合
的外れな不具合報告であればINVALIDになるのでわかりやすいですが、
不具合報告として有効なものの、 処理されないのがWONTFIXです。修正可能な問題でもプロダクトへの要求の範疇から外れる問題は修正されません。 どちらにしろ結果には繋がらないチケットになりますので、
プロダクトへの要求がどんなものか配慮して現実的な問題点を見つけ出すことに目を向けるよう心がけましょう。 - NOT FIXABLEが目立つ場合
本来根源的な問題により修正できない時のステータスですが、
開発陣の技術レベルによっては違う意味で使われているかもしれません。 - もちろん元の報告が非現実的な場合も考えられますので、
注意しましょう。
間違った読み取り方
間違った読み取り方をすると、
- ASSIGNEDからRESOLVEDへ移行する時間を気にする
修正にかかる人的コストを計算しようとするとき、
この時間を集計して個人や組織の能力の判断基準にしたくなると思いますが、 それは間違っていることが多いといえます。これはチケットによりバラツキが大きい数字なので、 ほとんど参考になりません。 - バグの報告数が少ないのを気にし過ぎる。
バグ出しのために発見バグ数のノルマを設けてしまったりすると、
無駄なチケットが増えます。自然な状態を観測することが有益です。 - RESOLVEDからCLOSEになる時間を気にし過ぎる。
修正されたものはすぐ片付けてしまいたいものですから、
スムーズにCLOSEされることを気にするかもしれません。しかし中には検証の難しいバグもあります。そして、 ここで確認されたものは以後監視されないわけですから、 慌てさせてチェックの手を抜くべきではありません。 「バグを3つ直すと1つバグが生まれる」 という諺もあります。
BTSのデータを人事評価に使ってはならない
このように、
しかし、
まとめ
今回はBTSを運用して得られるデータの読み取りと利用法についてご案内しました。BTSは導入しただけでも効果のあるものですが、
次回は、