チケットの親子関係が持つ意味

さかばさんのBlogを読んで考えたことをメモ。

【元ネタ】
[TiDD] RedmineのWBS: ソフトウェアさかば

プロジェクトの初期にタスク洗い出しとして作られるWBSは普通、5階層までが良いと言われている。
WBSの階層が深いと管理しにくいが、階層化しなければ、タスクの見通しが悪い。

Ver0.8までのRedmineでは
「プロジェクト－サブプロジェクト－バージョン－チケット」
の構造を持つので、4階層になるようにWBSを作ればいい。
しかし、実際はもっと深く作りたい時もあるから、その場合は階層を省略するなど無理するしか無かった。

Ver0.9では、プロジェクトの階層が無制限へ機能改善されたので、
「プロジェクト－サブプロジェクト1－サブプロジェクト2－バージョン－チケット」
のように、5階層のWBSを簡単に作ることができる。

ここで、さかばさんの指摘のように、下記のように対応付ければ、小規模リリースを簡単に実現できる。

チケット←→モジュール(部品・機能)
バージョン←→コンポーネント(リリース可能な最小の稼動できるモジュール)

しかし、チケットをタスクカードに見立てることはRedmineで簡単に実現できるが、ストーリーカードを実現するのは難しい。
ストーリーカードを実現するには結局、チケットの親子関係、つまり、チケットの階層構造を作らなければならない。
そして、ストーリーカードとタスクカードには、Redmineの各機能から眺めたチケット駆動開発の課題:プログラマの思索のような制約が必要になる。

もし、この制約が実装できたならば、下記のイメージのようなRedmineで要件管理も可能になるだろう。

チケット管理の観点：プロジェクト－サブプロジェクト1－サブプロジェクト2－バージョン－チケット
要件とタスクの観点：ストーリーカード1－ストーリーカード2－ストーリーカード3－ストーリーカード4－タスクカード

つまり、要件をストーリーカード1～ストーリーカード4の単位で階層化・細分化し、タスクカードを最下層に配置する構造が対応するようにできる。
そして、要件の階層は、ステークホルダーの観点で進捗管理する単位にすればいいと思う。
例えば、第1～3階層までは顧客や管理者向け、第4～5階層は開発者やライブラリアンの観点で、要件や作業をチケットにすればいい。

上記のようなツリー構造をRedmine上で実現できれば、要件からモジュールまでのトレーサビリティが容易に可能になる。
例えば、モジュールでバグが発生した場合、バグが発生したストーリーカードを探せば、その階層構造から影響するストーリー(要件・機能)の範囲が分かるので、修正方法や修正工数の決定が楽になる。
あるいは、仕様変更が起きた場合、影響するストーリーカードの階層構造から、影響範囲が分かるので、対応工数を見積しやすくなるだろう。

即ち、チケットの親子関係という機能は要件管理と要件のトレーサビリティと密接に関係するからとても重要だ。
そして、要件管理が実現できれば、設計プロセスの品質改善に大きく役立つと思う。
何故なら、設計プロセスのバグである設計漏れの原因の大半が、要件漏れや要件の影響範囲の考慮漏れだからだ。

上記のアイデアは、既にRedmineのScrum系プラグインで実装されているが、Ver0.9で動くか確証がないし、Ver0.8でもそもそも不安定なプラグインもある。
早くRedmineのデフォルト機能として実現して欲しいと思う。