Redmineの「チケット計測のススメ」の記事がすばらしい
Redmineの「チケット計測のススメ」の記事がすばらしいのでメモ。
【参考】
Redmine - チケット計測のススメ - Qiita
チケット駆動開発によるチーム力向上の事例 #Redmine: プログラマの思索
チケット計測のアーキテクチャとしては、Redmineのチケット一覧画面で必要なクエリをあらかじめ作成しておく。
次に、RedmineのREST APIを使って、クエリを呼び出してCSVへ出力し、そのCSVをパース&解析して、各種メトリクスを出力する仕組み。
仕組みは簡単だが、すごく良いアイデアだ。
従来のソフトウェア工学では、常時監視した方が良いメトリクスは既に知られている。
アジャイル開発ならば、下記が既に知られている。
詳細は「リーン開発の現場 カンバンによる大規模プロジェクトの運営」を参考にすると良い。
・累積フロー図:ステータス毎のチケットの枚数を時系列に並べたグラフ
・Velocity:チームの開発規模を表す
・リードタイム:平均のリリース間隔を表す。チケットの平均完了日数。
・サイクルタイム:ステータスが変更される平均時間を表す。
累積フロー図は、チケットの増減を通じて、チームの開発履歴を見る時に使う。
Velocityは、チームの平均の生産性を示す。
アジャイル開発が教える所によれば、Velocityは急激に増やすべきものではなく、安定させるべきものである。
リードタイムはチケットの平均完了日数だから、リリースサイクルに相当する。
リードタイムが長いほど、リリース日数が長くなるため、顧客の新規要望の実現は待たされるようになり、顧客満足度が落ちるだろう。
アジャイル開発の観点では、リードタイムは、XPのイテレーション、Scrumのスプリントの期間よりも短くなる。
そうでなければ、1イテレーション、1スプリントの終了直前までチケットが残ることになるから、リリースできない。
つまり、アジャイル開発では、リードタイムは2~4週間よりも短くなるように運用しなければ意味が無い。
サイクルタイムはチケットの更新間隔に相当する。
サイクルタイムが短いほど、チーム内で活発に作業がやり取りされていることを示す。
逆に長ければ、チーム内のコミュニケーションに問題があったり、開発プロセスが厳格すぎて開発ペースを落としているのかもしれない。
上記の記事では「ステータス別計測」を累積棒グラフにすれば、累積フロー図に相当するだろう。
また、「消化予測」はVelocityに相当するだろう。
「寿命」はチケットの平均完了日数だから、リードタイムに相当する。
さらに、「放置量」という図があり、「指定された区間より以前に作成されて、未だに完了していないチケットを生成時期別に表示」とある。
放置されたチケットが多いほど、Redmineがゴミ箱になっている事実が分かる。
Mantisでは、集計画面に「平均完了日数」や「最大放置日数」のメトリクスを出力する機能があったから、Redmineでも同様に表示できるといいと思う。
これらのメトリクスを手動で収集しなくても、自動計測できるのが素晴らしい。
これらのメトリクスをチームで共有できれば、Redmineによるチケット駆動開発を、現場主導でプロセス改善する動機になり得る。
この辺りのノウハウもまとめていきたい。
| 固定リンク
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント