クライアントの要件がまったく変わらないときにアジャイルを使用するのは間違っていますか？

最近、アジャイルが使用される主な理由の1つは、クライアントが要件を頻繁に変更するためだと言っている多くの投稿を見てきました。

ただし、クライアントが要件を頻繁に変更しないとしましょう。実際、クライアントには多少あいまいな要件もありますが（不当にあいまいなものはありません）、要件はしっかりしていますが、とにかくアジャイルを使用しています。

私がアジャイルを採用する理由は、ソフトウェアが非常に複雑であるため、実際にそれらに直面するまで認識できない問題や詳細が存在するためです。ウォーターフォールのような本格的な重度の計画アプローチを行うこともできますが、その後、すべての高レベル設計と低レベルコーディングシグネチャを完成させるのに数か月かかります。ただし、システムには非常に具体的な固定アーキテクチャ設計があります。

私の質問は、これは悪い、カウボーイコーディング、アンチパターンなどと見なされますか？アジャイルでの「やろう」という考え方ではなく、要件が安定しているときにコーディングを開始する前に、ウォーターフォールを使用し、可能な限り詳細に計画する必要がありますか？

編集：ここでの主要なポイントは、次のとおりです。要件の変更についてクライアントを責めることはできません。クライアントが私たちに非常に具体的な問題を指摘し、非常に合理的な詳細でウィッシュリストを提供し、私たちをそのままにしておくと仮定します最小のプロトタイプが完成したら終了します）。このシナリオでアジャイルを使用するのは間違っていますか？

これは悪い、カウボーイコーディング、アンチパターンと見なされますか。

短い答え：いいえ。「アジャイル」を正しく行うことは「計画なし」を意味するのではなく、物事を過度に分析しないことを意味します。

アジャイルが使用される主な理由の1つは、クライアントが要件を変更することが多いためです。

それは単純化しすぎの声明です。「要件の変更」とは、要件に対するチームの理解がどのように変化するかに関することでもあります。そして、ソフトウェアのいくつかのリリースを実際に見たときに、要件に関する顧客の優先順位がどのように変化するかについてです。

実際、「アジャイル」はあなたが説明する状況で最も正確に私見的に機能します -クライアントは彼の全体的な要件について十分な知識があり、そこから一般的な計画を書き、バックログをたくさんの「ユーザーストーリー」で満たし、適切なシステムアーキテクチャを選択するのに十分な情報。アジャイル開発戦略の短いイテレーションは、「曖昧な要件」をより正確にするのに役立ちます。まだ正しい方向に進んでいる場合、多くのフィードバックがあります。また、実際の労力とコストに関する早期のフィードバックを提供します（要件の詳細をすべて把握していても、ウォーターフォールアプローチでは失敗する可能性があります）。

この状況でアジャイルを使用することは依然として非常に良い考えです。アジャイルには多くの利点がありますが、そのうちの1つだけが、顧客からの定期的なフィードバックと、ご指摘のように変化する要件に対応できることです。

ウォーターフォールプロジェクトが失敗することで有名な主な理由の1つは、「ほぼ完了した」問題です。テストでは最後に大量のバグが発生し、リリースできない製品が残り、未解決のバグを修正するのにさらに2日または2年必要かどうかはわかりません。アジャイルはこのリスクを完全に取り除きます。アジャイルプロジェクトが過剰に実行されている場合でも、次の機能バージョンを提供できます。

A）デモを通して実際にそこにいる顧客に証明し（「これらのストーリーはすべて完了し、必要に応じて最後のいくつかを行うことができます）」、さらに多くの時間が彼らが望むものを正確に得るでしょう。

B）彼らがとにかく幸せで解放するのに十分な可能性がある。

私にとって、この完全な失敗のリスクを取り除くことは、ビジネスがアジャイル開発プロセスに移行するための十分な理由だけであり、当初の計画よりも優れたソフトウェアを構築する能力が重要です。他の回答で述べたように、それらの「具体的な」要件は、依然として驚くほど柔軟です。

クライアントとの頻繁なフィードバックループが必要な場合は、アジャイルが理想的です。これは、要件が頻繁に変更されるためですが、他の理由も考えられます。

一方、要件が完全に安定しており、クライアントが単一のビッグバン配信のみを期待している場合、アジャイルは同じようにうまく機能しますが、事業。これは、製品所有者の役割はあなた自身の組織内で満たされなければならず、その人は決定を下すために顧客からの十分な権限を持たなければならないことを意味します。

いつでも大きなリリースを小さなリリース（スプリント）に分割し、クライアントにフィードバックを求めることができます。このようにして、あなたはあなたが正しいことをしていると確信し、クライアントはあなたの進歩を追跡することができます。

何か問題がある場合は、クライアントに早く修正する機会を提供できます。これは非常に良いことです。最後にでたらめを見せて、どこから始めてもわからないときに修正しようとするよりも、できるだけ早く間違いを修正する方が良いでしょう。