「スプリント後に要件を変更する必要がある場合でも問題はありません」とチームに説明するにはどうすればよいですか。
私のチームは、マネージャーが私たちの唯一の仕事をする方法と、いくつかのタスクに費やすのに必要な時間について非常に経験がありません。クライアントが必要とするものを開発し、それをクライアントに示す（アジャイル手法など）など、非常に多くのサンプルが、一部のメンバーが推測しようとする退屈で不要な会議に変換されます単に基本バージョンを提供するのではなく、顧客が必要とするもの。
私たちにはリーダーがいないので、「ソフトウェア要件の仕様をたくさん作成するのをやめて、それをコーディングしましょう」と正確に言う方法がわかりません。
もちろん、すべてのソフトウェア仕様/要件を知ることは非常に重要ですが、すべての利害関係者とそれらがプロジェクトに与える影響を定義するなど、このステップ（プロジェクトは2か月で提供されます）に非常に多くの時間を費やしています（なぜ？クライアントが必要なのはなぜですか？承認）そして私は彼らがクラス図とUML図をやりたくないことを願っています。
私のチームに「スプリント後に要件を変更する必要がある場合は問題はなく、このプロセスで問題が発生した場合は正常です。コーディングしてください」とどのように説明しますか？
現実の世界には多くの利害関係者がいるかもしれませんが、開発者に関する限り、1つだけです。関係する企業によって作成された製品の責任を持つために選ばれた製品マネージャーは、利害関係者が必要とするものです。その人がそこにいないか、仕事を怠った場合、プロジェクトは失敗します。
プロダクトマネージャーは、達成可能で、受け入れ基準を持つ個々のタスクを作成し、それらに優先順位を付けます。チームは、優先順位と依存関係を考慮して、タスク期間の合理的な見積もりに基づいて、スプリント中に実行するタスクを決定します。そして、チームはスプリント中にこれらのタスクを実行するために最善を尽くします。
プロダクトマネージャーが気が変わって、求められたスプリントで行われた作業が役に立たなくなった場合、開発チームはそれが彼らのせいではないという意味で心配する必要はありません。プロジェクトに影響を与えるのはまだ時間の無駄です。
この作業を行うには、主要な利害関係者（「顧客担当者」）の緊密な関与が必要になります。理由は次のとおりです。
要件には、実行時に要件が満たされていることを明確に証明する受け入れテストを伴う必要があります。受け入れテストが伴わない場合、それは要件ではありません。それは願いです。
これを「アジャイル」な方法で行っている場合、プロジェクト全体で約6回のスプリントを行う時間しかありません。お客様からの緊密で継続的なフィードバックがなければ、それを行うことはできません。
あなたはほぼ間違いなく仕事の範囲を過小評価しています。 2ヶ月はそれほど時間ではありません。最後の段落である「スプリント後に要件を変更する必要がある場合でも問題はありません」は、2か月以内に要件が完了しないことをほぼ保証します。
利害関係者の関与により要件が変更された場合は、完了までの時間を延長するための承認を得る必要があります。
あなたはスプリントを使用していると言っています。これにより、スクラムなどのアジャイルアプローチを実装していると推測できます。この場合、プロダクトオーナー（PO）がチームと協力して、スプリントの計画中、およびスプリント全体で、時間の問題を明確にする必要があります。 POの役割の目的は、利害関係者/顧客およびチームと連絡を取ることです。いかなる状況においても、チームは顧客が何を望んでいるかについて仮定や決定を下すべきではありません。
POを配置している場合、チームのためにこれらの決定を下すことができるのはPOだけであり、それに応じてこれらの決定に優先順位を付ける必要があります。
次に、スプリント計画を実行するときは、POとチームからの入力を使用して、スプリントの目標に合意することが重要です。これにより、チームは重要なことに集中でき、チームが正接するのを防ぐことができます。 。
最後に、スプリントの目標はストーリーの分割方法に影響を与える可能性があります。チームの集中力を維持するのに苦労している場合は、ストーリーをサブタスクに分割して、チームとPOの両方が同じページにあることを確認してください。次に、チームがこれらのサブタスクにのみ取り組むように促すことができます。