Waterfallは、設計、コードの記述、テスト、そして最後にリリースに時間を費やしています。しかし、アジャイルはまったく同じ一連のステップを実行します。つまり、それぞれが小さいというだけです。
アジャイルは単一のエンティティではありませんが、さまざまな方法論の傘です。
他の人が指摘しているように、少なくともそれらのいくつかでは、これらの「フェーズ」ははるかに重なり合い、通常の順序が多少異なります。
実際、XPでは、順序は多かれ少なかれ次のとおりです。
- テスト（TDD /テストファースト）
- コード
- デザイン（リファクタリング）
- 繰り返して最終的にリリース
これは、シーケンスの大部分を反転させます。
また、テスト、コード、および設計は、リリースよりも細かいグレードで行われます。
アジャイルアプローチの重要な部分は、各リリースから学習し、それを使用して、最初に予測しようとするのではなく、より大きなデザインを出現させることです。
しかし、Waterfallもこれを行います。ウォーターフォールチームは、3週間または4週間ごとに学習するのではなく、6か月または9か月ごとにしか学習しません。しかし、ウォーターフォールのデザインはまだ現れています。つまり、ウォーターフォールリリース2は、リリース1で学習した内容を反映します。したがって、プロセスに違いはなく、実行速度が異なるだけです。
これは練習に大きく依存します。DOD-STD-2167A （セクション4.1.1）で説明されているように、ウォーターフォールモデルでは、開発プロセスのフェーズをオーバーラップさせて反復することができます（つまり、ある程度アジャイルにすることができます）。しかし、ほとんどの実際の実践はそれを見逃し、プロジェクトが終了するまで学習はありませんでした。
アジャイルは、顧客との緊密なコラボレーションに重点を置いています。しかし、Waterfallもこれを行います。ウォーターフォールの反復時間が長いため、長期間にわたって全員を同じページに維持するには、契約の形式で要件の列挙リストがより必要になります。しかし、繰り返しになりますが、これは単なる周波数のアーティファクトです。配達の頻度が高いほど、契約の必要性は低くなります。
再び練習に依存します。上記の仕様には、継続的に言うまでもなく、顧客の責任についての多くの言及はまったくありません。
Jerry Coffinがコメントで述べたように、Waterfallは確かにアジャイルを支持して議論するために使用されるストローマンです（実際に私は今それを使用しています...）が、このドキュメントを見て、それが何を意味し、どのようになっているのかを考える価値があります適用されました。
この仕様が示しているのは、契約、計画とドキュメントの配信と保守、および計画の順守に重点を置いていることです。そして、それは実際に引き継がれたと私は信じています。
アジャイルとの対比は、タイムボックスではなく、値の変化です。
アジャイルマニフェストが宣言しているように：
私たちは、ソフトウェアを開発し、他の人がそれを行うのを助けることによって、ソフトウェアを開発するより良い方法を発見しています。この作業を通じて、私たちは価値を得るようになりました。
プロセスとツールを介した個人と相互作用
包括的なドキュメントで動作するソフトウェア
契約交渉を通じた顧客のコラボレーション
計画に従った切り替えへの対応
つまり、右側のアイテムには価値がありますが、左側のアイテムにはもっと価値があります。
不思議なことに、この値のステートメントは、配信の頻度については何も述べていません（ただし、次の「原則」セクションでは説明しています）。ただし、実際に機能するソフトウェアを提供することで、価値システムを計画、文書、契約から離れ、元の場所に戻すことはできません。
頻繁なリリースは、これらの値を満たすためのメカニズムです。
「ミニウォーターフォール」で作業した場合、ストローマンBDUFウォーターフォールよりも少し機敏になります。しかし、配達の頻度は確かにすべてではありません。