チケット駆動開発を開発プロセスへ理論化できるか？

下記Blogで、これがやりたいことなんだ！と思ったのでメモ書き。

【元ネタ】
実践バグ管理―プロジェクトを成功に導くための (単行本) - watawata日記

まあ要するに僕が読みたいのはバグ管理も含めた構成管理とか開発プロセスの本なんだｗ。

僕が考えるプロジェクト管理サーバーのイメージは下記の通り。

RedmineやTracのようなプロジェクト管理機能を持つBTSをチケット駆動でタスク管理する。

Subversionで、ソースコードだけでなく、WordやExcelの仕様書もバージョン管理する。
更に、trunkとブランチを上手に使い分けて、メインラインモデルとしてコードラインを並行開発する。

Hudsonで、継続的インテグレーションを実現するだけでなく、並行に走らせて、ビルドや自動テストの工数を短縮する。

TestLinkで受入テストを効率化する。

VMWareでテスト環境、本番環境を仮想化して、複数の環境を作り、並行テストしてみる。
あるいは、複数のブラウザや複数のバージョンのOSのクライアント環境を仮想化して、ブラウザ依存、OS依存の検証をできるようにする。

上記のようにツールを駆使して、SW開発のプロジェクト管理からExcelをなくす。
プロジェクト管理サーバーを用意して、アジャイル開発の弱点を補強して、アジャイル開発のハードルを下げる。
ツールに合わせた運用によって、現場独自の開発プロセスを編み出す。

ツールはあくまでもSW開発を楽にするための道具の一つ。
特にオープンソースのツールには、世界中の開発者のベストプラクティスが含まれている。
ツールの運用に慣れれば、自然に開発者のスキルも上がる。

それらのツールをまとめたものが、プロジェクト管理サーバーと言う概念。
実際の開発プロセスはチケット駆動開発(TiDD：Ticket Driven Development)。

その運用プロセスを一つの開発プロセスへ昇華できないか？

おそらく、その開発プロセスは、ハンフリーのPSPやTSPに似た開発プロセスになるのではないか？

Personal Software Prcess

Team Software Prcess