TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？

チケット駆動開発を運用していると話すと、必ず「チケットの粒度はどれくらいが妥当ですか？」という質問が来る。
僕はまだその質問に完全な回答は持っていない。
その質問について考えていることをメモ。

【1】RedmineやTracで、全てのタスクからQAまでチケットを起票してから作業を始めるようにすると、チケットの粒度がかなり細かくなってしまう。
粒度が小さいと作業しやすいが、チケットの完了速度よりもチケットの登録速度が上回ってしまう時が多いため、どんどんタスクが増えていってしまうような感覚に陥ってしまう。
かと言って、チケットの工数が5人日以上になってしまうと、進捗がはかどっているのかどうかも分からない。

チケットの粒度が問題になる状況は、顧客へ進捗報告を出したい時だ。
RedmineやTracによるチケット管理はあくまでも開発者のためのタスク管理が目的だから、粒度が細かすぎて、顧客から見れば開発全体の進捗が分かりづらい。

実際のソフトウェア開発では、WBSで予想されたタスクよりもはるかに多いバグや仕様変更、突発的なタスクなどに忙殺される。
それらのタスクとWBSから作成されたタスクの粒度は元々合わない時が多い。

又、プロジェクトリーダーがプロジェクトの立ち上げでWBSを書きおこした時、チケットの粒度はどれくらいがいいのか悩む時がある。実際のWBSはユーザの観点から必要な作業を洗い出すから、実際にメンバーに作業を割り当てる場合、チケットよりも粒度が大きい。
粒度が大きすぎると、チケットをどんどんこなしていくリズムが生まれにくいので、チケット駆動開発の利点が薄れてしまう。

更に、バグを起票した時、バグのチケットはバグの原因や同類バグ調査結果など色んな項目を書く運用にしたいものだ。
何故なら、それらの入力項目は品質管理の観点で集計したいからだ。
つまり、集計された結果から、どの機能にバグが集中しているのか、どんな原因が多いのか、などの調査に使い、次の開発で改善する対策作りに当てたいからだ。
だが、チケットの入力項目が多いほど、チケットの登録がおっくうになり、1個のチケットを完了させるまでの期間が長くなってしまいがちだ。
そうすると、チケット駆動開発で自然に現れる開発のリズムが生まれにくくなり、進捗が停滞してしまう。

【2】チケットの粒度の問題は2つの原因があると思う。
一つは、ユーザやPMの観点と開発者の観点によるチケットの粒度の違い。
もう一つは、チケットの属性とチケット集計機能の関連。

前者は、フィーチャないしストーリーとタスクの違いだ。
この観点については既に下記に書いた。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
Redmineの最後の課題～チケットの親子関係: プログラマの思索

最終的には、ストーリーカードとタスクカードをRedmineのどの概念に当てはめるのか、という問題に落ち着く。
この問題は3つのプラグインの使い方によって解決方法は異なると考える。

【2-1】パーキングロットチャートを使う場合は、下記を使う。このプラグインは@daipresentsさんが作られており、とても使いやすい。

redmine_parking_lot_chart

redmine_parking_lot_chartを使う場合、
バージョン＝フィーチャ、ストーリーカード
バージョン＞タスクカード
と見なして、WBSからマッピングすればいい。
バージョンがサブシステム単位、大きな機能(フィーチャ)単位にリリースするならば管理しやすいだろうと思う。
@daipresentsさん作成のタスクボード、バーンダウンチャートと合わせて使うと有効だろう。

redmine_version_burndown_charts
redmine_task_board

【2-2】バックログを使う場合は、redmine_backlogsを使う。@yusuke_kokubo さんが使いこなしているプラグインであり、まさにScrumそのものの使い方だ。

relaxdiego/redmine_backlogs - GitHub

Redmine Backlogs :: Introduction

redmine_backlogsを使う場合、
バージョン＝スプリント
親チケット＝ストーリーカード
子チケット＝タスクカード
と見なすので、Redmine本来の構造にとても近い。
おそらく、アジャイル開発本来の使い方だろうと思う。
プラグインの機能に若干癖があるが、使いこなせれば、Scrumのアイデアをそのまま取り入れて運用できるだろう。

【2-3】Advanced roadmapを使って、Redmineのデフォルト機能にはないマイルストーンを導入する方法もある。

Advanced roadmap - Advanced roadmap plugin for Redmine - Redmine OCIO y TECnologi'a

Advanced roadmapを使う場合、
マイルストーン＞バージョン＞タスクカード
マイルストーン＝フィーチャ
バージョン＝リリース単位
と見なせばいいだろう。
つまり、複数のバージョンが集まったら一つのフィーチャになる場合に使いやすい。
すなわち、複数回のリリースを経て一つのサブシステムが出来上がる場合、マイルストーンという階層を増やすと、より大きな観点で進捗度合いを簡単に表現できるように思う。

ただ、いずれにしてもRedmineのチケットの親子関係の機能をフルに使えてないと思う。
本当は、チケットに階層構造を導入して3階層以上のチケットの構造を表現できれば、WBSと完全にマッピング可能なのだ。
又、親チケットの集計機能があれば、簡単にストーリーカードの進捗度合いを表現できるはずだ。
Redmineが導入したチケットの親子関係による集計機能は、今後のRedmineプラグインの課題と言える。

【3】後者については、チケットの粒度とチケット集計ビューの間に密接な関係があると言う事実を指摘している。
チケットの粒度が細かいほどチケットの枚数は増えるので、プロジェクトの動向はチケット集計結果に敏感に反映される。
又、チケットの入力項目が多いほど、色んな観点でチケットを集計することは可能。
チケットの粒度が大きかったり、チケットの入力項目が少ないと、集計してもあまり役立つ情報は得られない。

Redmineのチケットの属性とチケット集計機能の関連については、下記でまとめている。

チケット管理システム比較Wiki

この比較Wikiを書きながら、新たな問題意識として、プロジェクト管理に必要なビューはどれだけの種類があって、どんな状況にどんなビューが有効なのか、というノウハウが実は整理されていないように思っている。

アジャイル開発では、InfoQ: かんばんボードによるプロジェクトの見える化のように、パーキングロットチャート・タスクボード・バーンダウンチャート・ニコニコカレンダーの4種類が最も有名なビューだが、これだけではないはずだ。
又、PMBOKでもガントチャートやPERT図、バグ収束曲線だけでなく、他にもあるはずだ。

今知られているプロジェクト管理のビューは、どんなコンテキストに対して有効なのか、という議論を整理してみたい。
そのようなノウハウがあれば、RedmineやTracという優れたプロジェクト管理ツールを使いこなすと、自然にプロジェクトマネジメントのスキルも身に付くようになるだろうと考えている。