Redmineの各機能から眺めたチケット駆動開発の課題

Redmineの各機能から眺めたチケット駆動開発の課題についてメモ。
ラフなメモ書き。

【プロジェクト】
「Redmineのプロジェクトはどんな単位で作るべきか？」という質問は良く出る。

僕がTiDDをアジャイルに運用した経験から言えば、二つある。
一つ目はブランチのライフサイクルに合わせる。
二つ目はITILの運用保守プロセスに合わせる。

前者は、RedmineのプロジェクトがSCMリポジトリと1対1に対応している思想から、自然に扱える。
例えば、本番リリースしたソースは本番ブランチとして作られて、trunkとは別のコードラインで保守される。そして、次のメジャーバージョンが出たら、古い本番ブランチは廃止されて、以後は保守されなくなる。
つまり、プロジェクトとブランチが1対1に対応する状態遷移になる。

プロジェクト：新規作成→使用中→非公開→終了
ブランチ：新規作成→使用中→廃止(以後保守しない)

本番ブランチとtrunkをRedmineプロジェクトで別管理する利点は、ソースのライフサイクルもタスクの内容も異なるからだ。
本番ブランチは障害修正のみで、機能追加は基本はしない。
trunkはガンガン機能追加していくが、本番ブランチの障害修正があればマージ作業が発生する。
この時、trunkへのマージ作業は、本番ブランチの障害修正のタスクと別にしておく方が管理は楽になる。
マージ作業のタイミングは、本番ブランチの障害修正のタイミングと異なる時があるからだ。

後者は、ITILの4つの運用保守プロセスの観点で、Redmineプロジェクトが分割される。
例えば、プロジェクトと要望にあがった機能改善チケットのライフサイクルは下記のフローになる。

プロジェクト：開始→インシデント管理→問題管理→変更管理→リリース管理→終了

チケット：
開始
→改善要望は、インシデント管理でチケットに起票
→チケットは、問題管理でバックログに入れられる
→チケットは、変更管理でイテレーション計画に組み込まれて、タスクに分割される
→チケットは、リリース管理でタスクを担当者が開発&テストして、リリースして反映される
→終了

本来、改善要望をリリースするプロセスは、いきなりタスクカードに落とすのではなく、そもそも開発すべき対象なのか、どのバージョンでリリースすべきなのか、等の観点で吟味すべきだ。
実際、他の機能で既に実現されているのにユーザが知らないだけだったり、次バージョンに向けて現在開発中のタスクに含まれているならば、そのチケットは対応不要だからだ。

【ワークフロー】
「BTSでは問合せ管理がやりにくい」という話は良く出る。
それは当たり前で、BTSの標準ワークフローであるバグ修正と問合せを混同しているからだ。

運用保守も含めたSW開発を考えると、ワークフローもITILの運用保守プロセスで制御できると思う。
例えば、Redmineプロジェクトとワークフローは下記のような対応が存在するのではないか？

プロジェクト：開始→インシデント管理→問題管理→変更管理→リリース管理→終了

インシデント管理のワークフロー：新規→問合せ中→回答済み→終了
問題管理のワークフロー：新規→担当→調査解決→終了
変更管理のワークフロー：新規→担当→方針決定→終了(承認済み)
リリース管理のワークフロー：新規→担当→解決→検証中→検証完了→終了(リリース完了)

※あくまでも思いつき。

つまり、インシデント管理はオペレータ、問題管理や変更管理は設計者、リリース管理は開発者やテスター等のように、それぞれのプロセスでは担当者のロールが異なるし、チケットのライフサイクルも異なるし、ワークフローも大きく異なる。
パッケージ製品開発のように、製品開発部隊と品質保証部門、問合せオペレータ部隊などでチームが分かれているならば、別プロジェクトで別ワークフローにして管理した方が楽かもしれない。

【チケット】
「チケットは仕様書ですか？」「チケットの粒度はどれくらいですか？」という質問は良く出る。
TiDDをアジャイルに運用するならば、チケットはXPのタスクカードのように扱う。
つまり、チケットを作業指示書として扱う。
この手法はIssue Trackingと呼ばれる。

チケットをタスク管理に使えば、ガントチャートなどを生成できるから進捗管理できる。
チケットは元々バグ管理の障害報告票だから、バグ収束曲線を生成すれば品質管理もできる。
つまり、ITSのチケットはとても柔軟な概念。

そして、チケットをXPのタスクカードのように扱えば、その粒度は自然に細かくなる。
この時、チケットをストーリーカードにも使いたいと思うのはとても自然。
ストーリーカードとタスクカードの関係の制約は下記で表現できる。

・ストーリーカードの開始・終了日は、タスクカードの開始・終了日のUnionである。
・ストーリーカードのステータスは、タスクカードのステータスの共通集合である。
・ストーリーカードの工数は、タスクカードの工数の合計である

しかし、現状のRedmineでも、チケットを要件管理に使うのは難しい。

【バージョン】
バージョンをイテレーションに見立てると、自然にアジャイル開発になる。
バージョンのライフサイクルは下記になる。

バージョン：開始→実施前→実施中→終了(リリース済)

実施前ステータスは、リリース計画に基づいてバージョンを作ったものの、バージョンにあるチケットを精査しておらず、未完成な状態。
実施中ステータスは、イテレーション計画を立てて、どんな機能をリリースするか決定済みで、リリースに向けて作業中の状態。
そして、全てのチケットが終了ステータスになったらリリースできる。リリースしたら、Redmineのロードマップ画面からバージョンは非表示になり、変更履歴にChangeLogとして残る。

この時、リリースしたバージョンは、以前はSVNのTagでリネームしていた。
理由は、リリースする直前に必ずSVNでTag付けした後、本番ブランチを作り、ビルドモジュールをデプロイするから。
ビルド管理ツールHudsonを使い始めてから、「SVNタグ.ビルド番号」のような形式でリネームするようになった。

しかし、設計やテストでは、バージョンをリリース単位に分割するのは難しい。
複数のバージョンをこなした後に初めてリリースできる時もある。
これは、漸進型開発ではなく、反復型開発になっている。

つまり、バージョンをイテレーションに見立てる時もあるし、マイルストーンとして運用する時もある。

【SCM連携】
SCMコミットログにチケットNoを書くと、成果物の変更をチケットで追跡できる。
チケットに構成管理情報を付与できる点が、従来のBTSにはない大きな利点。
Excelの仕様書も構成管理すれば、ソースのように成果物の変更を追跡できる。

最終的には下記のようなトレーサビリティを実現できるはず。

要件→タスク→チケット←SVNリビジョン←ビルドモジュール

つまり、ビルドモジュールから要件まで辿れるし、逆に要件からビルドモジュールまで辿ることもできる。
この性質をうまく使えば、仕様変更やバグの影響調査をサポートできるし、リバースエンジニアリングも可能になる。

Hudsonのプロモーション機能を使えば、ビルド番号にも「優良ビルド」「不良ビルド」を色付できる。
例えば、リリースできるがまだ不安定なモジュールなら「不良ビルド」、本番ブランチでバグ修正を施したモジュールなら「優良ビルド」になるだろう。
それらビルドモジュールからチケットを辿り、それらチケットを集計すれば、バグの傾向分析もできるのではないか？

【レポート出力】
「MSProjectのレポートとRedmineのレポートを連携しにくい」という質問はよく聞く。
それは当たり前で、MSProjectはストーリーカードの観点、Redmineはタスクカードの観点で進捗管理しているからだ。
顧客向けの進捗報告を作る場合、Redmineから生成する進捗報告は粒度が細かすぎて、似合わない。
つまり、Redmineでストーリーカード、すなわち要件管理を実現できなければ、この問題は解決できない。

Redmineのデフォルトのチケット集計機能は若干不足しているけれども、いくつかのプラグインを使えば、バーンダウンチャートやイテレーション単位の進捗情報を作ることができる。

プロジェクトファシリテーションでは3つの道具が頻出する。
かんばん、ダッシュボード、あんどん。

かんばんはイテレーションの状況を表すボードで、ステータス毎のチケット集計結果に置き換えられる。
ダッシュボードはイテレーションの進捗を表すボードで、例えば、バーンダウンチャートだから、RedmineのChartsプラグインで置き換えられる。
あんどんはシステムが危険な状況になった時に出る警告のようなものだが、ソフトウェアあんどんでなくとも、Hudsonでビルドに失敗した時にメール通知すればいいだけだと思う。
つまり、PFのアイテムはRedmine上で容易に実現できるはず。

最終的にやりたいのは、PMBOKのEVMをRedmine上で出力したい。
PVは予定工数、ACは実績工数、EVは終了チケットの予定工数で対応付ければ、Redmineのチケット集計機能で実現できるはず。
実現できれば、EVMの各種メトリクスによって、コストやスケジュールのシミュレーションが可能になる。

チケット駆動開発は元々RedmineやTracのチケット管理から生まれた。
Redmineは、プロジェクト・バージョン・チケットの機能が柔軟なので、うまく運用すれば、いろんな使い方を実現できる。
チケット駆動開発でアジャイルに運用する手法はまだ確定していないけれど、ものすごく可能性を感じている。