チケットの粒度と進捗ビューの関係

チケットの粒度と進捗ビューの関係について、考えたことをメモ。

【元ネタ】
TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索

【1】チケットの粒度はどれくらいが妥当か？という質問はよく聞く。
RedmineやTrac、Mantisで色々試行錯誤した結果、気にせず登録した方がいい、という回答にしている。
その代わり、トラッカー(ワークフロー)単位では粒度を揃えて、ビューによる切り替えを上手く使えばいい、と回答することにしている。

前者の回答は、チケット駆動開発を運用した場合、チケットはタスク、要望、課題、問合せなど色んな種類があるので、そもそも観点が異なるし、粒度を揃えること自体が無意味だからだ。
開発者の観点では、チケットの粒度を揃えて綺麗にチケットを書くよりも、成果物を早く作るための作業記録代わりにみなした方がいい。
Agile開発なら、動くシステムが最終ゴールであり、顧客に取って一番価値あるものが動くシステムだからだ。

【2】後者の回答は、ITSに貯められたチケットは、見たいと思う観点のビューでSQLを発行してビューを作ればいいということだ。
そもそもチケットの粒度を揃えたいという要望は、マネージャ層から発生する。
その理由は、ITSから顧客へ提出する進捗報告や課題一覧、工数集計を出力したいのに、チケットがバラバラだと抽出しにくいからだ。

でも、それらの報告書は、チケットの属性を選択してフィルタリングして、抽出すればいいだけのことだ。
顧客向けの進捗報告はストーリーカードだけ抽出すればいいし、課題一覧は課題チケットだけ抽出すればいい。
工数集計はチケットの実績工数を合計して導出すればいいだけのことだ。

そのイメージを描いてみた。

Scrum・pf・wfのビュー from akipii Oga

PF(プロジェクトファシリテーション)では、開発者はかんばん、ユーザはバーンダウンチャートで作業の進捗を計測し合う。
Scrumでは、開発者はタスクボードにタスクカードを貼り付けて進捗管理するし、プロダクトオーナーはバックログに実現したい機能をストーリーカードに書いて優先順位付けする。
ユーザの観点のビューでは他にも、パーキングロットチャートがあげられるだろう。
つまり、Agile開発では、開発者やユーザが見たい観点はそもそも異なることを前提として、それらビューを作っている。

しかし、WF型開発では、開発者はガントチャートで進捗が管理されるが、ユーザの観点の報告書のフォーマットが定型化されてない。
ガントチャートはあまりにも細かすぎるので、顧客向け報告には向かない。
普通は顧客向け報告書をExcelで表形式に作るだろうが、何を書けばいいのか、というフォーマットは特に指定されておらず、各プロジェクトで全然違う。
つまり、各プロジェクトでローカルルールがはびこり、プロセスの標準化がやりにくい弱点がある。

【3】RedmineのようなITSの利点の一つは、チケットというデータベースに作業や課題の情報を蓄積すれば、チケットの属性を上手く使うだけで色んなメトリクスが抽出出来ること。
進捗報告や課題一覧は、プロジェクトの一側面の情報に過ぎない。

Redmineが他のITSよりも優れている理由の一つは、チケットの属性とチケット集計機能の関係がとてもよく考えられている点だと思う。
ガントチャートは、チケットの開始日、終了日、進捗率がセットされていれば自動生成できる。
バーンダウンチャートは、チケットの対象バージョン、予定工数、実績工数、終了ステータスがセットされていれば自動生成できる。
PMBOKのEVMですらも、チケットの予定工数、実績工数、開始日、終了日、進捗率があれば、自動計算できる。

もしRedmineのデフォルトのチケット集計機能が不足しているなら、MySQLに直接SQLを発行すればいいだけのことだ。
RedmineはRailsアプリなので、テーブル設計はとても綺麗だし、JOINしたSQLも書きやすい。

Agile開発であれPMBOKであれ品質管理であれ、メトリクスは所詮、チケットの属性をキーとしたSQLのビューに過ぎない。
だから、チケットの粒度なんか気にせず、むしろチケット集計機能をもっと強化していくことが大事だと思う。