« 2系統のバージョン管理戦略 | トップページ | ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する »

2008/06/12

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

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

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

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

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

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

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

チケット起票、アサイン(新規、担当)

SVNコミット

チケット終了(終了)

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

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

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

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

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

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

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

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

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

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

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

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

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

|

« 2系統のバージョン管理戦略 | トップページ | ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する »

Redmine」カテゴリの記事

ソフトウェア工学」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

試験項目が均等に実施されているなら、累積バグ数の傾きが水平になるのは、バグが減っているからという解釈になると思います。
一般に試験工程を設けている(つまりウォータフォール的なテスト)なら、上記前提が満たされやすいですが、それでも不完全なので、横軸を試験項目数にすべしという意見があります。
あきぴーさんのところで、試験項目数がとれるなら、一度試してみられてはいかがでしょうか?

投稿: さかば | 2008/06/13 10:56

◆さかばさん

BTSチケットの状態変化からバグ収束曲線を測定する試みは現在模索中です。

横軸が時間、イテレーションがよいのか、テストケース数が良いのか、色々試しています。
時間の方がRedmineでPGM作成は簡単で、テストケース数の場合はRedmineのDBにないのでTestlinkでやるしかないかなと思ってます。

モチーフは「チケットの状態からプロジェクト進捗を見える化する」です。
色々とアイデアを試したいと思ってます。

投稿: あきぴー | 2008/06/14 12:33

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/41515011

この記事へのトラックバック一覧です: Redmineを使って気づいたことpart2~バグ収束曲線:

« 2系統のバージョン管理戦略 | トップページ | ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する »