スパイラルモデル/アジャイル開発は、本質的にはより高速で圧縮されたウォーターフォールモデルではないのですか？
ソフトウェア開発の スパイラルモデル について学んだので、これまで関わってきたさまざまなプロジェクトに適用しようとしました。しかし、実際には圧縮しているだけで、従来の ウォーターフォールモデル を介してより迅速に反復します。
各スパイラルサイクルまたはアジャイルサイクルでも、スパイラルを完了するために完了する必要がある段階的なタスク/目的がまだあり、その段階的なプロセスは本当に似ています（ただし、総サイクルが短く、おそらくより少ない）手順）をウォーターフォールモデルに追加します。
主な違いは、フィードバックループが開発のプロセスの早い段階からプロセス全体に導入されることですか、それともタスクの実際の段階的な完了に根本的な違いがあるのですか？
スパイラルはサイクリングの滝です。それがスパイラルの定義です。それは、ベームや他の人たちがそれを発明したときに提案したものです。
スパイラルまたはアジャイルの各サイクルでも、完了する必要のあるステップバイステップのタスク/目標があります...
ほとんどが本当です。
フィードバックループが導入プロセスの初期およびプロセス全体に導入された主な違いは何ですか。
はい。
タスクの実際の段階的な完了に根本的な違いはありますか？
フィードバックループis基本的な違い。
ウォーターフォールには、事前に大きな要件（BRUF）が必要です。実際のコーディングを開始するには、Big Design Up Front（BDUF）が必要です。
スパイラルとアジャイルの方法は、この要求を緩和します。
本当に圧縮して繰り返すだけのように
それほどマイナーに聞こえないようにしてください。それは少し微調整ではありません。これは、要件（および設計）の量、およびそれらの要件（または設計）の使用方法における根本的な変化です。
滝では、すべての要件なしで実際に始めることはできません。多くの場合、これは知的に不可能です。新しいビジネスのやり方と、その新しいビジネスのやり方を強化するための新しいソフトウェアのすべての影響を視覚化することは困難です。
スパイラルやアジャイルでは、すべての情報を持っているわけではありません。始めるのに十分です。
多くの人々は「スパイラル」を「滝」にしたいと思っています。彼らは完全な理解に基づいて定義されたスケジュールを望んでいます。その愚かさを止めるために、多くの人々は「スパイラル」ワードを使用しないようにしています。なぜなら、それはソフトウェアの開始と提供を奨励していないからです今不完全な要件。
本質的に、スパイラルはリスクを軽減することによって推進され、ウォーターフォールはアーティファクトを生成することによって推進されます。
はい、でも...
スパイラルおよび高速アプリケーション開発（RAD）は、一般に、圧縮されたウォーターフォールサイクルです。
ただし、アジャイル/ TDDは、ドキュメントのアーティファクトを減らすことでさらに一歩進んでいます。機能、ストーリー、およびテストケースシナリオは、大量のウォーターフォールドキュメント（具体的には、機能仕様、要件仕様、設計仕様、および受け入れテスト計画）に置き換わります-冗長性なしで厳密になります