要件が明確に定義されていない場合に、厳密なウォーターフォールプロジェクトが成功する可能性がある状況はありますか？
要件を最初から明確に述べることができない場合、ウォーターフォール手法の下でソフトウェアプロジェクトがどのように意味のある進歩を遂げることができるのかわかりません。私は何かが足りませんか？
私たちはウォーターフォールを使用し、要件が変化する多くのプロジェクトを完了しました。ウォーターフォールは、それがそうであるように作られたほど悪くはなく、アジャイルはすべてを修正する特効薬ではありません（私が見る限り、ウォーターフォールプロジェクトと同じくらい多くの悪いアジャイルプロジェクトがあります）。どちらの方法論も特に高い成功率を持っていません、一部にはユーザーが必要なものを定義する方法がわからないため、一部には私たちの分野に無能な人がたくさんいるためです。
上記の「アンドリュー」によるコメントは有効です。また、要件のどの部分が欠落しています。ウォーターフォールの方法論は、一部の人が考えるほど厳格ではありません。ウォーターフォールは、十分な情報と事実が収集された後、主要な段階間を移動することに焦点を当てています。分析の大部分をやり直さない限り、分析を洗練することを妨げるものは何もありません。
たとえば、必要なすべてのレポートを知らなくても設計を開始でき、すべての検証ルールを知らなくても設計を開始できます。これらはすべて、後でいつでも追加できます。
ただし、データベース内の列の3分の1だけを特定して設計を開始することは望ましくありません。ウォーターフォールは優れた方法論であり、ビジネスがゼロから発明されておらず、ユーザーがビジネスを知っているほとんどのアプリケーションに非常に適しています。
データベースの設計、画面の設計、システムアーキテクチャ、ユースケースなど、すべての詳細を事前に知らなくても進歩を遂げることができます。
ここでの芸術は、他の灰色の領域への依存を最小限に抑えて開始および進行できる部分に問題を分割しています。これは、採用されている方法に関係なく、一般的に優れたアプローチです。
それは、コーダーがどれだけ優れているかに依存します。
コーダーが取り組んでいるビジネスを十分に理解していて、疎結合の方法でコードを書くのに十分賢い場合は、ウォーターフォールの終わりに向かって、顧客が製品を見るときに次のことを行う必要があります。
a）文句を言うほど多くはありません
そして
b）彼らが不満を言っていることは簡単に変更して修正することができます
あなたはそれを機能させるために良い必要があります！
変更要求を組み込んでいないウォーターフォール手法を使用したプロジェクトについて聞いたことがありません。したがって、実際には、初期要件が間違っている場合（おそらく小さなプロジェクトを除いて、常にある程度間違っています-私はそれらが100％完璧であるとは見たことがありません）、変更要求があり、必要なことをやり直します。それは本当に滝ではないという意味ですか？それは本当に哲学的な質問です。
それは成功できますか？それは可能ですが、方法論は変化する要件に対処することに焦点を合わせていないため、それに対処できない可能性があります。
実際、私がよく目にしたのは、要件が正確でない場合、ウォーターフォールはソフトウェア開発者にとってはかなりうまくいくが、クライアントにとってはうまくいかないということです。その理由は、クライアントがかなり合理的に、プロジェクトの費用を正確に前もって知りたがっていたため、ほとんどの場合、ウォーターフォール手法が最初に採用されたためです。残念ながら、ソフトウェアプロジェクトの費用は誰にもわかりません。時々、クライアントはそれを理解せず、固定価格を与えない人を雇うことを拒否します。その時点で、クライアントのビジネスを獲得しようとしている開発者は、主に低価格の見積もりに基づいて競争しているため、初期要件を超えて通常は高い時給を運ぶ変更注文で低価格で利益を上げたいと考えています。
したがって、要件が悪い場合、開発者は契約の収益性の高い部分（注文変更）をより多く取得し、収益性の低い部分（これがすべて開始されたときにクライアントが望んでいたと考えた要件のリスト）をより少なく取得することを意味します。
しかし、最終的には真の要件が明らかになり、変更が加えられるため、クライアントにとっては、要件が最初に正しかった場合よりも時間と費用がかかりますが、完了するという意味で「成功」します。
ですから、私は2つの主な理由から、個人的にアジャイルが好きです。まず、「これは変更要求ですか？」よりも、クライアントと開発者の利益を一致させます。滝の戦いは、リスクを軽減するのに役立つ頻繁な成果物につながる可能性があります。しかし、「私たちにお金を払って、私たちはあなたにいくつかのソフトウェアを書こうとしますが、あなたがあなたのお金のためにどれだけ得るかはまだわかりません」は、それが実際に状況の根本的な現実を認めているだけであっても、時には難しい販売です。
要件が明確に定義されていなくても、プロジェクト、IMOが自動的に破滅することはありません。失敗する可能性は高いですが、それでも成功する場合もありますが、認めます。
できる。最初の見積もりに不測の事態を組み込み、要件が不確実な場合は見積もりも不確実であることを説明する必要があります。開発が進んでいるのと同じペースで要件が発生している場合は、問題なく機能します。
ウォーターフォールはアジャイルの反対ではないことを忘れないでください。あなたが言っているのは、コンポーネントを段階的に提供しないということだけです。それは、「できるだけ早く要件を提供していただければ、コーディングして、最後に製品をお届けします。ただし、要件を十分に迅速に提供しないと、製品が遅れてしまいます。」
ただし、スクラムは不確実性と変化を管理するように設計されており、それが最善の方法だと思います。私は、クライアントが興味を持っていない場合、それはあなたが確実に失敗するという意味ではないと言っているだけです。
エド・ヨードンの「DeathMarch」を読むことをお勧めします。理想的とは言えない状況で働いているのは自分だけではないことに気づいたら、それは本当に役に立ち、やる気を起こさせます。とはいえ、それは私が不快な質問をすることを思いとどまらせませんでした-なぜ私たちは明確に定義された要件なしでコーディングしているのですか？
あなたもクライアントも理解できない何かを構築するのにどれくらいの時間がかかるかという質問に答えるときの成功の状況は、あなたが思っているよりもずっと長くかかると言うことです。必要に応じて、数か月、または数年の余裕を持たせます。