チケット駆動開発は課題管理が中心

TracやRedmineの運用を前提にしたチケット駆動開発は、従来のウォーターフォール型開発のプロジェクト管理とは手法が違う。
下記のBlogを読んで考えたことを書く。

【元ネタ】
プロジェクト管理ツール検討失敗

【1】SW開発ではガントチャート保守のコストが高い

汎用機＋CobolによるSW開発は、プログラミングやビルドのコストが高いから、ウォーターフォール型開発で十分だった。
最初に作った計画が変更されることはない。

しかし、特にWebシステム開発では、実際の受入テストでバグ修正だけでなく、大量の改善要望が発生して、当初の計画や見積もりと食い違う時は多い。
だから、XPなどのアジャイル開発は、小規模リリースというプラクティスを実践して、小さく作って小刻みにリリースして、顧客からフィードバックを受けて更に開発するやり方を取る。

ウォーターフォール型開発なら、ガントチャートを途中で大きく変更することはないが、アジャイル開発では、頻繁なタスク追加や変更が生じるため、ガントチャート保守のコストが高くなる。

【2】チケット駆動開発ではガントチャートは重要ではない

Redmineでチケット駆動開発を実践し始めて、ガントチャートの重要性が低くなった。
Redmineではガントチャートがデフォルト表示だが、その機能よりもロードマップというイテレーション計画の方が重要だと分かってきた。

Redmineでは、ラフなタスク管理をしている感じ。
チケットの当初の作業期間や工数見積もりが、実際に作業すると時間がかかる時は多い。
チケットはまさに課題、つまり、Issueだ。
ガントチャートで予測通りにタスクがはかどるとは限らない。
チケット管理は、SW開発のToDoを緩やかに管理するが、むしろ、作業の追跡性、一貫性を重視する。
まさに変更管理の観点を含む。

【3】チケット駆動開発はSW構成管理のインフラ

アジャイル開発では、計画の変更を前提に開発する。
計画の変更が多いということは、変更要求(RFC)をベースラインとして確定し、更にソースまで追跡できるインフラを必要とする。
しかし、つい最近まで、変更管理や継続的インテグレーションを含む包括的なSW構成管理のインフラが無かった。
ようやく、TracやRedmineのような強力なプロジェクト管理ツールのおかげで、SW構成管理のインフラが整うようになってきた。

SW開発では、ガントチャートによるガチガチのプロジェクト管理よりもSW構成管理による追跡性や一貫性を保障する方がはるかに重要だ。