XP型やアジャイル型は概念と言葉が取っ付き難いためか、知らない設計者も結構います。
一方、スパイラル型開発は言葉だけは浸透しているようです。
しかし言葉を自己に都合のいいように解釈して仕事を進めている設計者がいたりします。
「機能部分が完成したら顧客に見せて要望と不具合の洗い出し、製造に差し戻して修正する。 これを繰り返すと最終的に完成度の高い製品が仕上がる」
本気でこのように信じている設計者がいました。
スパイラル型はウォーターフォール型と敵対するものではありません。プロトタイプを設計段階にフィードバックするループは有限で3回,4回が限度です。
スパイラルに入る前に要件を確定させることはウォーターフォール型と同一です。
不確定要素をプロトタイプ提示後に持ち越すことはOKなんですが、詰める事が可能なのに手を抜いて「顧客に見せた時に決めたらいいや」と思った時点でデスマーチ突入です。
業務アプリの処理は業務のルールをコーディングしているだけなので、開発開始時点でルールに不明な点がある筈は無いのです。
失敗プロジェクトをみると開発開始したもののルールが不明確であったり、プログラムの結果を見てからルールの変更が生じたりするので手戻りが発生しソースが汚く汚れてグチャグチャになったりしています。
極論な言い方をすれば、何を作るか不明なのに製造に入ったり、道を歩いていて、私はどこに行くのと聞いているようなものです。
製造物仕様をキチン詰めて製造に入れば、コーディング期間は短くて済みます。テスト計画もスムーズに進みます。
なぜこのようにならないで、製造開始を急ぐのか不思議でなりません。雇い入れたPGを遊ばすのは勿体無いなどとケチなことを言っていたら大きな赤字となって返ってきます。
その皺寄せを末端の PGに持ってくるのはお門違いも甚だしい。
要件の確定が遅れても納期が不変というのも良く聞くはなしですが、自覚して欲しいのはそれは自殺行為であるということです。
...これが現実だから 3K職場といわれるでしょうね。スマートな開発でハッピーなシステム納品を夢見て。合掌。