チケット駆動開発の戦略

【1】チケット駆動開発は、まちゅさんが最初に提唱されている。

チケット駆動開発 ITpro Challenge のライトニングトーク

上記では「チケット無しのSVNコミットは不可」という思想が強調されている。
これは、本番リリースしたモジュールはチケット無しの場合修正不可、あるいは、プロジェクト内部の作業はチケットを作ってアサインして初めて稼動する、とも言い換えられる。

つまり、チケット駆動開発をプロジェクト管理の基本とすると、チケットに作業プロセスと作業担当者をアサインするのが前提条件になる。

そして、このチケットをバージョン単位にグループ化し、小刻みにリリースするのがチケット駆動開発。

僕がこの手法を運用して、強く意識するものは、チケットの取捨選択だ。

実際のプロジェクトでは、当初の計画した時のチケットの枚数と同じぐらい、バグ修正作業時にチケットが発生する。
つまり予期しない作業が、納期ギリギリになって、かなり発生する事実を意味する。

MSProjectでは、当初のスケジュールに途中で追加した作業と工数を組み込んで、平準化する機能がある。
この機能は確かに便利だが、スケジュールが納期を越えたら、作業の組み合わせや担当を入れ替えて、納期に間に合うようにしなければならない。
この作業がガントチャート保守であり、いつも無駄な作業だと思っていた。

僕のRedmineによるチケット管理では、ロードマップの画面で、1週間単位にチケットをアサインしている。
（但し、1週間と言うスプリントは各プロジェクトで異なると思う。）

つまり、1週間で解決できないチケットは捨てるか延期する。
今は1週間単位のスケジュールしか見ていない。

このやり方がどこでも通用するかどうか分からないけれど、手ごたえは感じている。

3ヶ月先のスケジュール作成に時間を費やすよりも、1週間先までのチケット解決に全力を注ぐ方が、成功する確率は高い。

チケット駆動開発では、ロードマップと言うバージョン単位のリリース計画を作るのが非常に重要なのだ。

【2】Redmineによるチケット駆動開発の凄い所は、下記3点だと思っている。

2-1.SVNリポジトリとRedmineチケットが紐づくので、要件とソースコードのトレーサビリティのインフラが整う。
つまり、BTSが構成管理ツールになる。

2-2.BTS(Bug Tracking System)のワークフローは、ITS(Issue Tracking System)のように、プロジェクト管理のフレームワークへ昇華・汎用化できる。

2-3.チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

今の僕の興味は、BTSを構成管理ツールにして、BTSの運用をプロジェクト管理の汎用化したプロセスにして、最後はソフトウェア工学の知識を流用して、プロジェクトを改善する材料にしたい。

これらの論点について更に考察したい。