Waterfallソフトウェア開発方法論はまだ実行可能ですか？

私の経験では、Waterfallモデルは柔軟性に欠け、要件の変更に無反応であることが証明されており、ソフトウェア開発の現代世界で実行可能な方法と見なされているようです。より俊敏で反復的な方法の成長と実証済みの実績は、プロジェクトの開始から製品の提供までほとんど変わらないことを前提とするリジッドブロックのプロセスに従う必要がある理由がないことを示しているようです。

ウォーターフォール開発方法論は、時間、コスト、および品質に関して、ソフトウェアシステムを提供するためにまだ実行可能ですか？

参照しているウォーターフォールモデルは、実際のプロジェクトで使用されるプロセスモデルを意図したものではありませんでした。代わりに、それはストローマンです。ソフトウェアプロジェクトに存在する主要なフェーズとアクティビティ、およびそれらの間の最も基本的なフローを特定します。ソフトウェアを開発する方法のこの単純化は欠陥があり、そのように提示されました。

ウィキペディアの記事から：

ウォーターフォールモデルの最初の正式な説明は、Winston W. Royceによる1970年の記事としてよく引用されますが、この記事では「ウォーターフォール」という用語を使用しませんでした。Royceは、このモデルを欠陥のある非稼働モデルの例として提示しました。

議論された論文のタイトルは、「大規模ソフトウェアシステムの開発の管理」です。その中で、Royceは2ページ目にそのモデルを提示しています。ただし、画像表現のすぐ下のテキストは読み続けます。

私はこの概念を信じていますが、上記の実装は危険であり、失敗を招きます。

彼はこれに続いて、開発フェーズの「完了」に続くテストの問題、ここでの失敗がどのように大幅な再設計とコード変更につながるか、これらがどのようにコストとスケジュールの大幅なオーバーランにつながるかについて議論します。論文全体を通して、彼は元のモデルをプロジェクトで実際に実行可能なものに改良します。最終的に、彼はプロトタイピング、顧客との対話、および成果物の洗練を導入するモデルになります。最終的には、1990年代後半から2000年代初頭に始まったアジャイルムーブメントに不可欠なアイデアになります。

あなたの質問に答えるために：あなたが尋ねているウォーターフォールは、時間と予算で合理的な量の品質でソフトウェアプロジェクトを提供するための実行可能な方法ではありません。ただし、プロジェクトで作業を実行できるアジャイルとは反対の、計画主導型の方法論が他にもあります。

人々は教科書のウォーターフォールモデルを使用せず、おそらく使用しないでしょう。

これは、システム開発の手順について考えることを目的とする理想的な理論上の構成要素です。大きなポイントは、できるだけ多くの変更をできるだけ早く行うことです。多くのコードが作成されると、大きな変更を行う時間もお金もなくなるからです。

プロセスというよりも思考の方法であるという事実にもかかわらず、それは多くの人がまだソフトウェア（または家、潜水艦、その他何でも...）を構築しようとしている多くの方法と同じです。

現実の世界では、フェーズ間の完全に厳密なカットオフはありません。また、小さなサブプロジェクトの場合、前のフェーズにループバックすることがあります。方法論があなたに言うことは、「これらのことは許されない」ということではありません。それはあなたに「これらのことはあなたにお金や時間を要します」と言っているので、将来はそれを避けるようにしてください。

Agile Snobs（TM）が「昔ながらの」開発者と彼らの趣のある、機能しないウォーターフォールの方法論に目を向けるのは、すべてうまくいきますが、問題の事実は、アジャイルも万能薬ではないということです。一部のプロジェクトはアジャイルを使用して構築することができず、アジャイルであると考える多くのチームは実際には単にずさんで組織化されていません。

方法論はポイントではありません。ポイントは、あなたが何をしているのか、なぜそうするのかを考え、最短時間で顧客に最大限の価値をもたらすことです。

最も頻繁にアジャイルと比較される神話上の滝のプロセスは存在しなかったため、死んでいると見なすことはできません。実際のウォーターフォールプロセスはまだ健在であり、ユーザーの期待に応える予算のあるソフトウェアを期日どおりに提供することに優れています。

おそらく、あなたが何を得ているのかを尋ねるより良い方法は、「反復性が少なく、よりフォーマルな方が良いとき」です。

これが当てはまる状況があります：

• 要件が変更されない場合。

• 新しい要件を満たすことは、元の要件を100％満たすよりも重要ではありません。

• すべてのテクノロジーコンポーネントが成熟し、十分に理解されている場合。

ある意味で、あなたはアジャイルに駆り立てられるかもしれないものの反対をとることができます。

どこでも適用できる技術はほとんどありません。役に立たないものはほとんどありません。

はい、非常に生きていますが、今日ではより一般的な「Vモデル」が使用されています。

どちらの場合でも、アジャイルにある問題は、ソリューションがほとんど終わらないことであり、顧客は変更を要求し続けることができ、開発はそれらを繰り返し解決し続けます。時間と材料のコストに基づいたプロジェクトの場合、これは非常に効果的です。固定費のプロジェクトの場合、そうではありません。

これらの固定費プロジェクトでは、顧客はほぼ常に事前に定義されたマイルストーンが進捗を示すことを期待しますが、これらは実際のコードではなく、正式に書かれたものです。このような顧客の場合、仕様書はプロジェクトになり、ソフトウェア開発が二次的な考慮事項になります（明確に定義されたプロジェクトがある場合、ソフトウェアは簡単に開発できるはずです）。これらの企業は、安価で外部委託された開発リソースを多用している企業でもあります。

そのため、お金や時間を固定している場合、要件の変更を期待したり、要件の変更を許可したりせず、文書の強力なセットを提供することが期待されている場合、ウォーターフォールモデルのみが理にかなっています。

これらのプロジェクトの途中でアジャイルを導入して開発を行うことはできますが、要件から仕様を作成する立ち上げ段階と、ソフトウェアをその場でインストールしてテストする立ち下がり段階がまだあります。アジャイルはこれらのケースにうまく反応しません。

どなた宛？私が対処したマネージャーのほとんどは、まだスケジューリングにWaterfall Software Dev Processを使用しており、アップレベルはスケジューリングを容易にするためにそれを好むようです。

実際、私が知っている開発者はごくわずかであり、それが機能する、または有効であるとさえ信じています。