Redmineを使って気づいたことpart2～バグ収束曲線

Redmineを運用して気づいたことを書いてみる。

【1】活動欄にプロジェクトの活発度合いが現れる

Redmineには活動欄という画面がある。

システムへ機能追加してテストすると、たくさんのバグ報告があがる。
それらを一つずつチケットに登録して、担当者をアサインする。
この時に、活動欄はチケットの起票で埋まる。

その後、修正したらSVNコミットするので、SVNコミットログが活動欄に現れる。
それから、テストで検証し、問題なければチケットは終了する。
この時に、活動欄に「チケット(終了)」と現れて、ロードマップのチケットに取消線が入る。

つまり、下記の流れが活動欄に出てくる。

チケット起票、アサイン(新規、担当)
↓
SVNコミット
↓
チケット終了(終了)

活動欄が少ない場合、チケットの状態変化もSVNコミットも少ない。
つまり、プロジェクトの進捗が停滞していることを意味する。

逆に活動欄が多い場合、チケットの起票や終了が頻繁で、SVNコミットも多い。
つまり、プロジェクト内部で開発者やテスト担当者が活発にやり取りしていることを意味する。

チケットがたくさん起票されるということは、バグがたくさん出たということなので、リスクが表面化したこと。

SVNコミットやチケットがたくさん終了したことは、バグが解消されて、品質が安定し始めたこと。
リスクが減ってきていることを意味する。
つまり、プロジェクト終盤にはバグ報告のチケットは減っていく。

だから、活動欄にたくさんのトランザクションが発生することは、リスクの顕在化という観点からすると、重要だと考える。

ロードマップに取消線のチケットが増えていくのを見ると、何故か楽しくなってくる。
タスクやバグ修正を確実に終了させた充実感を感じるからだ。

【2】チケットの状態変化をバグ収束曲線で表現できないか？

バグ収束曲線という図がある。
つまり、システムテストのバグ発生件数を時系列で描いた図。
この図は普通は、前半は指数関数的に増えて、後半は対数関数のような傾きになり、最後は上限で頭打ちになる。
バグ収束曲線のメリットは、品質の分溜りが後どれくらいの時間必要なのか、を予測できること。

上記のチケットの状態変化を追跡してみると、バグ収束曲線のような曲線になっていることが感覚的に分かる。

Redmineにはバグ収束曲線の表示機能はないが、DBにチケットの状態があるはずだから、プログラムさえ書けば表示は可能なはず。
しかも、Railsなので、DBさえ分かれば書けるはずだろう。

Redmineによるチケット駆動開発(TiDD)を実践してみて重要なポイントは、チケットの状態変化をきちんとトレースすることだ。
チケットを単に起票して終了するだけでは意味が無い。

今、チケットが増えているのは、バグ収束曲線から類推して、良いことなのか？
あるいは、チケットが減っているのは、バグ収束曲線から類推して、もうすぐ品質も安定する兆候なのか？
それとも、単にバグ報告があがっていないだけなのか？

それらを見極めることが大事。