ウォーターフォール型開発はバージョンの概念が無い

RedmineやTestlinkを運用して気づいたこと。
アジャイル開発の基本構造はまさに、チケット駆動開発(TiDD)なのだ、ということ。

アジャイル開発のスタイルは、短いイテレーションで小刻みにリリースすること。

この時、イテレーションとはシステムのバージョンのことだ。
Redmineならバージョン、Testlinkではビルドに相当する。
つまり、リリースするマイルストーンを指す。
実際の手順は、リリースする時に、Subversionにバージョンというタグを付ける。

すると、チケット駆動開発では、1個のプロジェクトで、たくさんのイテレーション、つまりバージョンが発生し、その単位でリリースすることになる。

そのイテレーションに、実現する機能(ストーリーカード)を作業(タスクカード)に分解して、どれを優先するか、チケットをふるいにかける。

イテレーションの日数とメンバーの人数から、機能を実現できる工数は限られる。
だからこそ、限られた工数内で、チケット(タスクカード)に優先順位を付ける。

この時、バグ修正のチケットが機能追加よりも優先する。
理由は、品質を最優先にするからだ。
バグが多く出れば、機能追加は次のイテレーションに延期するしかない。

BTSのチケット管理は自然に、限られたリソース(工数、人、時間)でやり繰りするようになる。
バージョン履歴こそがプロジェクト管理の要なのだ。

しかし、ウォーターフォール型開発は、リリースが最後の1回だけ。
マイルストーンを区切ったとしても、要件定義が終わった、設計が終わったというだけで、動くシステムは形すらできていないのが普通。
システムのバージョンという発想そのものが欠落している。

その理由は、人月ビジネス、受託開発スタイルにあると思う。
かき集められたプログラマは、リリース後はプロジェクトからいなくなる。
彼らにとって、システムを育てていくという発想がそもそも契約上ないから。

ソフトウェア開発では、バージョンという概念が一番大事。
バージョンUpしながらシステムを育てていく、という発想をチケット駆動開発は支えてくれるはずだ。