Redmineの「チケット計測のススメ」の記事がすばらしい

Redmineの「チケット計測のススメ」の記事がすばらしいのでメモ。

【参考】
Redmine - チケット計測のススメ - Qiita

チケット駆動開発によるチーム力向上の事例 #Redmine: プログラマの思索

チケットを利用したプロダクトの健康確認 from kazuto kawahira

チケット計測のアーキテクチャとしては、Redmineのチケット一覧画面で必要なクエリをあらかじめ作成しておく。
次に、RedmineのREST APIを使って、クエリを呼び出してCSVへ出力し、そのCSVをパース＆解析して、各種メトリクスを出力する仕組み。

仕組みは簡単だが、すごく良いアイデアだ。

従来のソフトウェア工学では、常時監視した方が良いメトリクスは既に知られている。
アジャイル開発ならば、下記が既に知られている。
詳細は「リーン開発の現場 カンバンによる大規模プロジェクトの運営」を参考にすると良い。

・累積フロー図：ステータス毎のチケットの枚数を時系列に並べたグラフ
・Velocity：チームの開発規模を表す
・リードタイム：平均のリリース間隔を表す。チケットの平均完了日数。
・サイクルタイム：ステータスが変更される平均時間を表す。

累積フロー図は、チケットの増減を通じて、チームの開発履歴を見る時に使う。
Velocityは、チームの平均の生産性を示す。
アジャイル開発が教える所によれば、Velocityは急激に増やすべきものではなく、安定させるべきものである。

リードタイムはチケットの平均完了日数だから、リリースサイクルに相当する。
リードタイムが長いほど、リリース日数が長くなるため、顧客の新規要望の実現は待たされるようになり、顧客満足度が落ちるだろう。

アジャイル開発の観点では、リードタイムは、XPのイテレーション、Scrumのスプリントの期間よりも短くなる。
そうでなければ、1イテレーション、1スプリントの終了直前までチケットが残ることになるから、リリースできない。
つまり、アジャイル開発では、リードタイムは2～4週間よりも短くなるように運用しなければ意味が無い。

サイクルタイムはチケットの更新間隔に相当する。
サイクルタイムが短いほど、チーム内で活発に作業がやり取りされていることを示す。
逆に長ければ、チーム内のコミュニケーションに問題があったり、開発プロセスが厳格すぎて開発ペースを落としているのかもしれない。

上記の記事では「ステータス別計測」を累積棒グラフにすれば、累積フロー図に相当するだろう。
また、「消化予測」はVelocityに相当するだろう。
「寿命」はチケットの平均完了日数だから、リードタイムに相当する。

さらに、「放置量」という図があり、「指定された区間より以前に作成されて、未だに完了していないチケットを生成時期別に表示」とある。
放置されたチケットが多いほど、Redmineがゴミ箱になっている事実が分かる。

Mantisでは、集計画面に「平均完了日数」や「最大放置日数」のメトリクスを出力する機能があったから、Redmineでも同様に表示できるといいと思う。

これらのメトリクスを手動で収集しなくても、自動計測できるのが素晴らしい。
これらのメトリクスをチームで共有できれば、Redmineによるチケット駆動開発を、現場主導でプロセス改善する動機になり得る。

この辺りのノウハウもまとめていきたい。