チケットを利用したプロダクトの健康確認
このスライドを作成した頃は頑張って毎日チケットを手動で計測していたのですが流石にいつまでも手動でやってるのは面倒というよりも恥ずかしいです。と言うことでRedmineのチケットからいくつかの情報をツールを利用して計測する様にしました。

ツールの出力内容

推移チケット全体量がどの様に変化したかを見ます
ステータス別計測チケットのOpen / Closeの詳細情報
増減チケット自体の増減量のみを見ます
消化予測増減値を元に現在量から全体消化
消化量(終わらせた）単純な消化量だけに絞った量と平均
寿命チケットの生成から終了までの平均
報告者チケットの作成＆報告者のランキング
放置量長期間閉じられていないチケットの情報

用意するモノ

現実がツマッたRedmineとチケットとAPI Key
RedmineのQuery - 1 （計測したい区間の全チケットが流れてくるクエリー)
RedmineのQuery - 2 （現在の「未完了」で残っているチケットが流れてくるクエリー)
本ツール

以上の4点を用意してからツールをを実行します。

今回のケースでは計測したい区間として以下の2つを用意しました。

2014/11月から現在までのクエリー
現在の未完了全てのクエリー

ツールの使い方

コード : https://github.com/kawahira/redmineReport.git
実行方法 : RedmineToReport.exe settings.xml

ツールを実行し、以下の様なレポートが表示されれば正常にCSVが出ていると思います。

またはリポジトリ直下にある copycsvs-debug.bat などをビルド後に利用してもらうと取得とコピーを行います。

settings.xmlの内容

settings.xml

<?xml version="1.0" encoding="shift-jis"?>
<Settings>
  <redmine-url>http://hogehoge-api.com</redmine-url>
  <redmine-url-alias>https://hogehoge.com</redmine-url-alias>
  <redmine-project>fugafuga</redmine-project>
  <redmine-apikey>123456abcdefg123456abcdefg123456abcdefg</redmine-apikey>
  <redmine-query-id>666</redmine-query-id>
  <redmine-query-id-all-remining>777</redmine-query-id-all-remining>
  <sprint-size>7</sprint-size>
  <bug-keyword>バグ</bug-keyword>
</Settings>

ツールの実行にはXML形式の設定ファイルが必要です。以下の設定を入れます。

redmine-url : RedmineのURL
redmine-project : Redmine上のAPIキーにアクセスするためのURL
redmine-url-alias : RedmineのAPIキーのURLがブラザーで参照するURLと異なる場合、こちらにブラザで参照するURLを入れます。
redmine-apikey : RedmineのAPIKEY
redmine-query-id : 見たい範囲がフィルターされたクエリ
redmine-query-id-all-remining : 現在の未完了のチケット全てが見えるクエリ
sprint-size : グラフをある程度の期間でまとめる日数 2週間単位なら 14 一ヶ月単位なら 30
bug-keyword : バグと判定するトラッカー名称 Redmineデフォルトなら「バグ」

sprint-size補足

毎日の増分のグラフで見ると詳細過ぎて長期間でのグラフが見難くなります。そのため、ツールには日数を指定する事でその日数を1つの区間としてまとめます。今回のサンプルではこの区間を7日間（1週間）にして5ヶ月ほどのデータを参照しています。

ツールの出力結果

以下の様なCSVが大量に出力されてきます。このCSVファイル全てをリポジトリ内のhighcharts\chartsへ移動します。

このCSVをグラフで見える様にしてあります。highcharts\にあるindex.htmlをブラウザーでひらく事で出力したCSVをグラフ形式で参照出来ます。
※グラフの表示には HIGHCHARTSを利用しています。

推移

チケット量の推移をタスクと不具合で分けた積立グラフで表示します。

例

サンプルでは2015/1月19日から 2015/2月23日までの区間で急激に減少に移りました。タスクとバグどちらも同時に減少しています。素晴らしい消化量を実現していますが一方何故 2014/11 から 2015/1までの区間では、この勢いで消化する事が出来なかったのでしょう。更に3/9以降は一定の増加が発生しています。何が起こったのでしょう。

・・・と言うような点等に注目し他のデータを見て実際の注目した点の発生要因を調べるためのアタリを付ける事に使う情報として利用する事を想定しています。

ステータス別計測

新規作成と完了のステータスをタスクとバグ別に表示します。

例

見方の例として「推移」の項目で注目した以下の点についての原因を調査してみたいと思います。

2014/11月3日から 2015/1月19日まで全く減らなかったのか
2015/1月19日から 2015/2月23日までなぜ急激に減ったのか
2015/3月以降なぜ増えているのか、何が増えているのか

なぜ①の区間は全く減らなかったのか

②との大きな違いは追加作成数が90前後となっており消化量とほぼ一致しています。この点から判ることはプロジェクトは消化可能量が90前後である事。90前後生成されている期間が続いてる状態の場合は減少しないと言う事です。2014/12/29からの区間は急激に落ち込んでいます。これはチームがお正月休みを取ったのかもしれません。

なぜ②の区間に急激に減ったのか

全体量が急激に下がった理由は消化量がなぜか倍に上がった事と不具合の報告が急激に減った事となります。不具合の報告量が減っても本来は消化量に影響はないはずです。ここから考えられる事は以下の様な事かもしれません。

残っていた不具合は処理が楽な不具合が多数残っていた（重く難易度の高い不具合から対応していた）
不具合対応人員が増員された

同じように別に不具合報告量が急激に落ちた理由も予測します。

ソフトウェアが安定してきて報告する不具合が減った
トリアージされた（軽微な問題の修正を諦めた）

なぜ③の区間から増えているのか、何が増えたのか

グラフを見ると、この時期からタスクの追加が始まっています。合わせるように不具合の消化が停止しています。ここで予測できることは以下の様な事です。

プロダクトは不具合対応から実装フェーズに切り替わった

この様に推移でアタリを付けた部分についての理由を詳細情報で更に分析し実際の内容をプロダクトに対して確認します。確認の結果が予想の通りであれば大きな問題はないかもしれませんが予想と外れていた場合、（例えば安定していないし、トリアージもしていないのに報告が減っていたり、お正月は実は誰も休んでいない（ヒィィ・・）事実が発覚した場合には、「なぜ」この様なグラフになったのかの原因を調査する必要があると考えるべきです。

増減

チケットが増えたのか減ったのかだけを表します。値が 0 以下になっている場合、その区間でチケットの総量が「減った」事を意味しています。

例

チケットは作成＆報告された数よりも消化された数が上回ればチケットは減ります。そこで分類などの情報を減らして単純な増減量のみに注目したのがこのグラフです

青い線で、これは指定区間範囲の増減の平均となります。これが意味する事はプロダクトは時期により増減がありますが平均的では毎週 11枚のチケットが減らせていると言うことが判ります。これはとても良いことです。逆にこれが反転していた場合（常に増え続けている）場合などは収束しない事を意味しますので対応が必要と考えるべきです

消化予測

増減値から算出した平均的な量を元に残りのチケットが「何時消化されるか」を予測したグラフとなります。処理量が少なすぎる場合や期間が狭い場合などにはグラフが異常に長く（終わる予測が出せないケース）なりますのでリミッターとして20区間を最大として表示しています。

例

今回のグラフの例だと不具合は4ヶ月後には0になりますがタスクは4ヶ月後の段階で1割しか減っていないと言う事が判ります。このプロダクトはタスクの新規追加をしなくても大丈夫なプロダクトでしょうか。不具合が取りきれるのは4ヶ月後でスケジュール的に問題がないのでしょうか。もちろん問題がある場合はどの様にして減少量を増やせるかを検討する必要があるでしょう。

消化量

消化量のみのグラフと平均を表示します。

例

増減のグラフは実際の増加と消化を足した数値で現実的な数字となりますが、こちらは消化だけに着目した処理量となります。ステータス別計測で処理量が70-90前後では無いかとの予測を立てましたが、ここでは、その平均が実際に出せたと思います。この値を元にトリアージする量やタスクを追加する量を調整する事が出来ると有効に使えるケースがあります。

寿命

チケット作成後からそのタスク（またはバグの修正）が完了となるまでの平均日数を表示します。

例

このグラフはチケット発行ルールや運用方法によって大きく変わりやすい性質があります。初動段階で大量のチケットを発行する形での利用方法の場合には値が大きくなりすぎます。また不具合が大量にあふれてしまって優先度などで貯められている場合なども単純なフィルターだけだと厳しいかもしれません。それらの場合は再優先の物だけのフィルターで取り込んでみるなどの工夫が有効に働くケースもあります。

報告者

報告者の割合を表示します。

例

理想はチームの全員が同じ割合になっている事だと思いますが、もちろんプロジェクトやチームの状況によってはリーダーが確認後に報告も行うなどのプロセスの場合もあると思います。その場合は、このグラフはあまり意味のあるものにはならないかもしれません。

ただ、もし特定のスタッフに集中している、または依頼してる作業のペースが落ちている人がなどがいれば、狭い区間で、こちらを見てみると該当する人が上位に来ている可能性があります。その様な確認には有効に働きやすいです。

放置量

指定された区間より以前に作成されて、未だに完了していないチケットを生成時期別に表示します。

例

過去のチケットがたまっている状況と言うのはあまり良くないケースに発展しやすい事があります。運用ルールとして大量にある場合にはしょうがありませんが、単純なケアレスミスで残っていたり、閉じ忘れなどもチケットプロセスなどでは起こりやすいです。こちらを利用して適切な処置をお行えると有効です。

オススメの使い方

この様なツールを使う場合にはやはり以下の様な点に注意出来ると利用効果が上がります

必ず着手する必要があるタスクだけをクエリーで算出
異なる区間や期間（1週間, 4週間, 12週間など）で同じプロダクトを見れる様に
発見した問題点に対応する時間を出来るだけ確保

必ず着手する必要があるタスクだけをクエリーで算出する

着手が不要なタスク（異なるプロジェクト、次のリリース予定の物）などが含まれていると予測や消化量推移の値を見るのが難しくなりがちです。グラフはシンプルにRedmineのクエリーで出来るだけ絞り込んであげる事を心がける事で使いやすく（見やすく）なりやすいと思います。

異なる区間で同じプロダクトを見れる様に

平均にしても予測にしても取得区間で結果が変わります。また、大きい区間や期間からしか見えない特異点もありますし逆に小さい区間や期間でないと目立たない特徴などもあります。ただし異なるプロダクトで見る場合は値の取り扱いに注意が必要です。

発見した問題点に対応する時間を出来るだけ確保

沢山グラフを見ても問題が絞れるだけで何一つ解決されません。可能であればJenkinsなどで本ツールを複数走らせて異なる区間や異なるプロダクトなどとも相互比較や参照が出来るように自動更新させて、発見された問題点の解決により時間をかけられるようにすることがとても大事だと思います。グラフが如何に綺麗でも実際にプロダクトがガタガタだったり大きな問題を抱えているケースは山ほどあります。このツールが問題を発見するツールとして機能し解決のちょっとした手助けとなる情報になればと思います。

Redmine Plugin

欲しいな！
|ω・`）チラ

チケット計測のススメ