« TestLinkがExcelのテスト仕様書よりも素晴らしい点 | トップページ | Googleのアーキテクチャ »

2008/06/08

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

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

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

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

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

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

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

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

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

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

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

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

|

« TestLinkがExcelのテスト仕様書よりも素晴らしい点 | トップページ | Googleのアーキテクチャ »

Git・構成管理」カテゴリの記事

Redmine」カテゴリの記事

チケット駆動開発」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

ウォーターフォールの場合、当初確定した仕様をベースラインとして、その後は変更管理が行われます。おっしゃるようにアジャイルと違い現物主義ではないので、正式リリースは最後の一度かもしれませんが、仕様という意味では複数バージョンが存在し、それが管理されています。
また、アジャイルでも新システムに対する第三者検証、マニュアル作成とか、教育とか、いろいろ必要になると思うので、多くの場合、正式リリースは一度あるいは半年~一年に一度程度だと思うのですが、違いますか?
結局、リリースまでのバージョンが仕様としてあるか、コードとしてあるかの違いだと思います。

投稿: さかば | 2008/06/09 00:18

◆さかばさん
非常に参考になります。
ウォーターフォール型開発でも、仕様はバージョン管理されているということですね。

他プロジェクトはよく知りませんが、Webシステムの場合、正式リリースは長くても6ヶ月以内でしょう。

Webシステムはビルド&リリースしやすい特徴があるので、正式リリース後は、1ヶ月に最低1回のペースでバグ修正や機能追加していくのが最近の流れだと思います。

だからこそ、プロジェクト管理の敷居が高くなっているように思います。

投稿: あきぴー | 2008/06/09 20:45

不具合対応を入れれば、ウォータフォールでも致命的な場合はマメに更新すると思います。ウォータフォールでいう(つまり仕様の)バージョンアップはそんなにないのではないでしょうか?
でも、自動テストが可能なので、デグレテストは(アジャイル手法ではなく)アジャイル環境の方がリリース間隔は短くできるかもしれませんね。
もし、管理が難しいなら、機能追加してもユーザにはリリースしないという方法もあるかもしれませんね。

投稿: さかば | 2008/06/09 21:47

◆さかばさん

バグ修正と機能追加のバージョン管理の使い分けは今模索中です。
機能追加の頻度は少なくても、最近はリリース間隔が非常に短くなっています。

一つの解決策としては、リリースブランチでバグ修正しながら裏では、trunkで機能追加しながら品質を確保する2系統戦略があります。
例えば、奇数バージョンが保守ブランチ、偶数バージョンが大幅機能追加のブランチのような戦略です。

2つのバージョン管理とマージ作業、それらに伴うプロジェクト管理の手法は、Redmineのようにプロジェクト管理機能を持つBTSでないと、もはやプロジェクトを運営できなくなっているように思います。

投稿: あきぴー | 2008/06/11 22:20

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/41476155

この記事へのトラックバック一覧です: ウォーターフォール型開発はバージョンの概念が無い:

« TestLinkがExcelのテスト仕様書よりも素晴らしい点 | トップページ | Googleのアーキテクチャ »