ウォーターフォール・モデルの崩壊とアジャイルソフトウェア開発

ウォーターフォール・モデルはだいぶ前から崩壊している。

実際に現場で働くとよく分かるのだが、顧客の要求はどんどん変わる。
とどまるところを知らない。

ウォーターフォール・モデルを用いた場合には何回逆流することになるのやら。
そこでアジャイルソフトウェア開発である。

詳細は下記参考サイトに譲るが、画期的なアイデアである。
もっと深く勉強したいと思った。

大事なのは開発手法の特性である。

下記に
アジャイル開発が有効である条件と
計画重視開発(ウォーターフォール・モデル)が有効である条件を引用した

アジャイル開発の得意とする状況
================================================================
クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性がなく、人命に関わらないシステム)
熟練した開発者が参加する場合
開発中に頻繁に要件が変わる場合
開発者が少ない場合
混沌とした状況に意欲をもって取り組む組織的文化
================================================================

計画重視開発の得意とする状況
================================================================
クリティカルなシステム (顧客の業務に重大な支障をきたす可能性がある、もしくは人命に関わるシステム)
経験の少ない開発者が多い場合
開発中に要件がほとんど変わらない場合
開発者が多い場合
秩序を重視する組織的文化
================================================================

小規模な開発やクリティカルでない開発には有効であろう。
是非現場でも使ってみたいと思った。


アジャイルソフトウェア宣言の最初の数行である。

================================================================
我々は、自らソフトウェアを開発し、あるいはソフトウェア開発の支援を通じて、より優れたソフトウェア開発方法を見つけ出そうとしている。この研究を通じて、我々は次のようなものを重視するようになった。

プロセスとツールより、個人とその交流（対話）
広範囲にわたるドキュメントより、正常に動くソフトウェア
契約交渉より、顧客との協調
計画どおりに進めることより、変化に対応すること
================================================================

＞広範囲にわたるドキュメントより、正常に動くソフトウェア
特にこの一文に感銘を受けた。
無駄なドキュメントを大量に作るのとてもモチベーションの下がる作業である。
それよりもソフトウェアの精度を高めた方が有益だと思う。

参考URL
アジャイル http://www.t-doi.org/agile/index.html

Principles: The Agile Alliance(アジャイル･アライアンスの原則)
http://www.metabolics.co.jp/XP/AgilePrinciples.html

アジャイルソフトウェア開発 - Wikipedia http://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA

エクストリーム・プログラミング - Wikipedia http://ja.wikipedia.org/wiki/%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%A0%E3%83%BB%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

ソフトウェア開発におけるパラダイムシフト : Hotwired http://hotwired.goo.ne.jp/original/maegawa/041130/02.html