ウォーターフォールのソフトウェア開発方法論はまだ実行可能ですか？
私の経験では、 Waterfallモデル は柔軟性が低く、要件の変更に応答しないことが、ソフトウェア開発の現代の世界で実行可能な方法と見なされるように見えます。より俊敏で反復的な方法の成長と実証済みの実績は、プロジェクトの開始から製品の提供までほとんどまたはまったく変化がないと想定する厳格なブロックのプロセスに従う必要がある理由がないことを示しているようです。
時間、コスト、品質に関して、ウォーターフォール開発方法論はソフトウェアシステムを提供するためにまだ実行可能ですか？
あなたが参照しているウォーターフォールモデルは、実際のプロジェクトで使用されるプロセスモデルを意図したものではありません。代わりに、それはストローマンです。ソフトウェアプロジェクトに存在する主要なフェーズとアクティビティ、およびそれらの間の最も基本的なフローを識別します。ソフトウェアの開発方法のこの単純化は欠陥のあるものであり、そのように示されさえしました。
ウィキペディアの記事から：
Royceはこの記事で「ウォーターフォール」という用語を使用していませんが、ウォーターフォールモデルの最初の正式な説明は、Winston W. Royceによる1970年の記事としてしばしば引用されています。 Royceは、このモデルを欠陥のある機能しないモデルの例として提示しました。
議論されている論文のタイトルは 大規模ソフトウェアシステムの開発の管理 です。その中で、Royceは2ページ目にそのモデルを示しています。ただし、絵画表現のすぐ下のテキストは次のようになります。
私はこの概念を信じていますが、上記の実装は危険で失敗を招きます。
彼はこれに続いて、開発フェーズの「完了」に続くテストの問題について議論し、ここでの失敗がどのようにして大幅な再設計とコードの変更につながるのか、そしてこれらがどのようにしてコストとスケジュールの大幅な超過につながるのかについて説明します。論文全体を通して、彼は元のモデルをプロジェクトで実際に実行可能なモデルに洗練させています。最終的に、彼はプロトタイピング、顧客との対話、およびアーティファクトの改良を導入するモデルに終わります-最終的には、1990年代後半から2000年代初頭に始まったアジャイルムーブメントにとって最終的に重要になるアイデア。
あなたの質問に答えるために：あなたが求めているウォーターフォールは、ソフトウェアプロジェクトを妥当な量の時間と予算で提供するための実行可能な方法ではありません。ただし、アジャイルの反対側にある、プロジェクトに取り組むことができる、また取り組むことができる他の計画主導の方法論があります。
人々は教科書 waterfall model を使用せず、おそらく決して使用しません。
これは、システム開発のステップについて考えてもらうことを目的とする、理想的で理論的な構造です。重要なのは、多くのコードがビルドされると、大きな変更を行う時間やお金がなくなるため、できるだけ大きな変更をできるだけ早く発生させたいということです。
それはプロセスというよりも考え方の方法であるという事実にもかかわらず、それは多くの人が（おそらくほとんどの組織がソフトウェア（または家、潜水艦、その他何でも...）.
現実の世界では、フェーズ間の完全に厳密なカットオフはなく、小規模なサブプロジェクトでは前のフェーズにループバックすることがあります。方法論があなたに言うことは、「これらのことが許されない」ということではありません。それはあなたに「これらのものはあなたにお金や時間を要します」と言っています-それで将来それを避けるようにしてください。
アジャイルSnobs（TM）が「古風な」開発者たちと彼らの趣のある、機能しないウォーターフォールの方法論に目を向けるのは、すべてうまくいきますが、問題は、アジャイルも万能薬ではないということです。一部のプロジェクトはアジャイルを使用して構築することができず、アジャイルであると考える多くのチームは、実際にはずさんで組織化されていません。
方法論は重要ではありません。重要なのは、何をしているのかを考えることと、なぜそうしているのか-そして、最短の妥当な時間で顧客に最大の価値を提供します。
アジャイルと最もよく比較される神話の滝のプロセスは存在しなかったため、死んだと見なすことはできません。実際のウォーターフォールプロセスは今も健在で、ユーザーの期待に応える予算内のソフトウェアを予定どおりに納品できます。
おそらく、あなたが何をしているのかを尋ねるより良い方法は、「いつ反復性が低く、形式がより適切なのか」です。
これが当てはまる状況があります。
要件が変更されない場合。
新しい要件を満たすことは、元の要件を100％達成することほど重要ではありません。
すべてのテクノロジーコンポーネントが成熟し、十分に理解されている場合。
ある意味では、アジャイルになるためにあなたを駆り立てるものの反対をとることができます。
どこでも適用できるテクニックはほとんどありません。役に立たない人はほとんどいません。
はい、それは非常に生きていますが、今日ではより一般的な「 Vモデル 」が使用されています。
どちらの場合でも、アジャイルの問題は、ソリューションがほとんど終わらないことであり、顧客は変更を要求し続けることができ、開発はそれらを繰り返し解決し続けます。時間と材料費に基づくプロジェクトの場合、これは非常にうまく機能します。固定費のあるプロジェクトの場合はありません。
これらの固定コストプロジェクトの場合、顧客はほとんどの場合、事前に定義されたマイルストーンが進捗を示すことを期待していますが、これらは実際のコードではなく、正式に記述されたさまざまなものです。このようなお客様にとって、記述された仕様はプロジェクトになり、ソフトウェア開発は二次的な考慮事項になります（明確に定義されたプロジェクトがある場合、ソフトウェアは簡単に開発できるはずです）。これらの企業は、安価な外部委託された開発リソースを多用している企業でもあります。
したがって、一定のお金や時間がある場合、要件の変更を期待したり、要件の変更を許可したりせず、文書の強力なセットを提供することが期待される場合は、ウォーターフォールモデルのみが理にかなっています。
これらのプロジェクトの途中でアジャイルを導入して開発を行うこともできますが、要件から仕様を作成する立ち上げ段階と、ソフトウェアをインストールして現場でテストする立ち下がり段階があります。アジャイルはこれらのケースにはうまく対応しません。
どなた宛？私が扱ってきたほとんどのマネージャーは、スケジューリングにウォーターフォールソフトウェア開発プロセスをまだ使用しており、簡単にスケジューリングできるように、上位レベルがそれを気に入っているようです。
実際には、私が知っているほとんどの開発者は、それが機能する、または有効であるとさえ信じています。