ウォーターフォールはガチガチで、
アジャイルはユルユルだという風説の流布はやめていただきたい。
(スクラムでいうところの)スプリントでやることは、
基本的にはウォーターフォールプロセスになります。
アジャイルは開発スコープを絞ってイテレーションし、
インクリメンタルに開発するプロセスだというだけです。
テンプレに当てはめれば、
要件定義→設計→開発→テスト(→リリース)と進めるのは変わりません。
※ちなみにテスト駆動という手法もありますが、あれは開発をドライブさせるためのものであり、テスト駆動だからテストしなくてよい、ということにはなりません。
もちろんアジャイルマニフェストにあるように、
アジャイル開発はドキュメントよりもソフトウェアを重視するのが基本思想です。
ただし、あくまで「より重視する」だけです。
そもそもドキュメントは成果物の話なので、
それは各プロジェクトごとに個別に定義していくものであるはず。
(アジャイル開発＝ドキュメントを作らない、ではない)
まぁ、言ってしまえばドキュメントが充実している＝ガチガチなプロジェクトっていう図式すら多くの場合成り立たないのですが
仕様変更への対応も同様で、イテレーションプロセスであるため、
「受け入れ(対応し)やすい」というメリットがアジャイルにはあります。
しかし、それと「受け入れるかどうか」はまた別の問題で、要望・変更管理の話です。
(一般的に優れたSEであれば、ウォーターフォールでもやっているはず)
ガチガチかユルユルかは品質の観点なので、
プロジェクトがQCDの優先度をどう置くかの話であって、
プロセスの話ではありません。
ではウォーターフォールのメリットは？
やりたいことが明確に定まっている場合は、
ウォーターフォールで一歩ずつ着実に進めたほうが効果あるかもしれません。
しかし、やりたいことが明確に定まっているエンドユーザーなど現実的には存在しません。
(もちろん、エンジニアが引き出していくのは前提に置いたとしても)
それこそ、単純に既存のものを移行するような場合くらいでしょうか。
(その場合でも、移行リスクの大きさによってはメリットとデメリットが逆転するでしょう)
上記の点を踏まえれば、
「アジャイル開発は儲からない」「赤字になりやすい」という批判が、
(少なくとも理論上は)成り立たないことが分かるはずです。
※導入にあたって、高いハードルを超えなければいけない現場が多いのは否定しません。
だから私はアジャイルに希望を見出しているのです。
