誰が製品の所有者に異議を申し立てる責任がありますか？
私はスクラムに比較的慣れていないので、製品所有者の境界を明確にしていません。
私が現在一緒に働いている製品所有者は、開発者に要件を与える誰かよりもマネージャーのように振る舞うようです。チームのリーダーがいない状態で私またはチームの他のメンバーと話すとき、彼は別様に振る舞います。リクエストや質問の価値を質問することはできません。彼が彼のケースを本当にサポートすることができない間に何かの必要性または緊急性について質問すると、彼は主に開発者が彼より「低い」ランクであると考えているために動揺していることは明らかです。
私はチームリードでそれを引き受けることができますが、私がアジャイルでの経験がないので、それが製品所有者の通常の振る舞いであるかどうかを理解したいと思います。
スクラムで製品所有者に「挑戦」する責任があるのはチームリーダーだけですか？
スクラムには正式な役割としてのTLは存在しないため、まずスクラムの観点から質問に答えます。チームの全員がPOに「チャレンジ」して詳細情報を取得できますが、「何を」行うかを決定する責任があるのはPOです。チームがPOの「何を行う必要があるか」についての決定を信頼し、POがチームを「方法」を実行することについてチームを信頼することが重要です。矛盾がある場合は、スクラムマスターが登場します。彼は「プロセスの擁護者」であり、プロセスはほとんどの場合、対立が合意されたプロセスと事実に基づいて議論に変わることができるように定義されているので、そのような場合、スクラムマスターは一種のモデレーターとして行動します。
しかし、スクラムは、それが定義していない役割には一切権限がないとは言いません。 TL（チームリード）をお持ちの場合は、チームリードにサポートを依頼することもできます。どの方法が最適かは、状況とチームリードの実際の役割によって異なります。通常、私はまず自分自身を試し、次にチームのエキスパート開発者を介して、次にスクラムマスターを介して、次にチームリードを介して試します。
それはあなたの権利だけではありません。スクラム開発チームのメンバーとしてのあなたの義務は、要件/ユーザーストーリーの詳細と詳細、および価値について尋ねることです。製品バックログは、ユーザーストーリーごとのビジネスバリューでソートされます。これについて不明な点がある場合は、それはあなたの権利ではなく、それについて質問するのはあなたの義務です。
最初に、製品の所有者は、どのストーリーがより優先されるかを決定する人物であると言います。開発者として、リリースおよびスプリントの計画ミーティングで私たちに見込みを与えますが、それでも彼/彼女は、ユーザーストーリーの優先順位を決定する最終的な人物です。理由は簡単です、彼/彼女はビジネスをよく知っています。アジャイル開発者として、私たちはフィードバックを与え、私たち自身で作成したタスクに取り組む必要があります。
そうは言っても、ここではチーム全体がアジャイルに不慣れなようです。アジャイルは、従来の作業環境とは大きく異なることを理解することが重要です。まず、製品の所有者やスクラムマスターを含むすべてのチームメンバーは、自分の役割が何であるかを知り、アジャイルマニフェストとアジャイルの原則を理解する必要があります。問題の半分は、チームがアジャイルの本質を理解することで解決します。あなたの特定の状況では、次の原則を製品の所有者に思い出させる必要があると思います。
1）やる気のある個人を中心にプロジェクトを構築する。彼らに必要な環境とサポートを与え、仕事を成し遂げることを彼らに信頼してください。
2）定期的に、チームはどのようにしてより効果的になるかを振り返り、それに応じて動作を調整および調整します。
2つの原則の最初で述べたように、「必要な環境とサポートを提供する」ことは非常に重要です。現在、あなたは完全に献身的に取り組むことができ、製品所有者を含むチームとのより多くの相互作用が必要であることを解決する環境を手に入れていません。そこで第2原則が実行されます。
対立があることは悪いことではありません。アジャイルは定期的に遡及することによってこれらの問題を解決するのに役立ちます。あなたのチームがお互いをよりよく理解し始めることを願っています。
彼が動揺しているのは、主に開発者が彼よりも「低い」ランクであると考えているためだと思います
これが一番の問題だと思います。スクラムマスターに彼の立場について話してもらう必要があります。プロダクトオーナーを含むチームの全員が同じランクであり、誰よりも高い権限を持つ人はいません。
アジャイルの第一義は、ソフトウェアに取り組むすべての人が合理的な人間であり、事実に裏付けられた合理的な議論によって問題を解決できるということです。開発者として、私たちはビジネスに何が必要かについてそれほど良い考えを持っていないことを認めなければなりません。一方、私は、製品の所有者が、いくつかの機能が高い優先順位である本当の理由を持っていると期待します。この理由が存在しない場合、私は彼の決定に疑問を呈し、それについての実際の事実を要求します。