スクラムにおける製品所有者の境界は何ですか？
別の質問 で、スクラムがアクティブな開発者をパッシブな開発者に変えると感じる理由について尋ねました、そして全体的な問題はスクラムではなく（スクラムに関連して）いないようで、むしろそれはの悪い実装に関連していますスクラム。だから、ここで私はPO（製品所有者）の責任の範囲と彼/彼女が渡すべきではない制限についていくつか質問があります。
- スクラムチームにデザイナーがいる場合、POはUI設計に干渉する必要がありますか？ （私たちに起こったこの例は、チェックボックスをドロップダウンリストで2つの項目、つまり、yesとnoで置き換えることです。または、いくつかのボックスを大きくするか、一部のコンテンツを中央揃えではなく左揃えにします。ページ、またはそのようなもの）。もしそうなら、どの程度ですか？色？レイアウト？
- POはコーディングの設計とアーキテクチャに干渉する必要がありますか？これはまだ起こっていませんが、境界に本当に興味があります。たとえば、POはプラットフォームを変更する（ASP.NET MVCからPHPなどに移動する）か、サーバーの数（層アーキテクチャー）を選択するなどの権利を持っていますか？.
- POは検証メカニズムに干渉する必要がありますか？たとえば、このフィールドは必須ですが、ユーザーからこの情報を取得する必要はありません。アナライザーやデザイナーは、UIで要求するのではなく、別のソースからユーザープロファイル情報を抽出するなど、何かが裏で処理できることを確認する場合があります。
- POは分析と設計にどの程度きめ細かく対応できますか？たとえば、ユーザーストーリーは「顧客として、新しいドメインをオンラインで購入できるようにしたい」です。ただし、スクラムチームは、このユーザーストーリーを5つの手順のウィザードまたは1つのページに実装できます。どのレベルのPOが技術的な分析、設計、実装を監視、管理、または監督する必要がありますか？
これらの質問をして、実装が正しいかどうかを判断しましたか？
一般に、スプリント中のPOの役割は受動的である必要があります。つまり、求められたときにフィードバックを提供しますが、チームの作業を細かく管理するべきではありません。そのようなフィードバックから生じる変更は、他の優先事項と比較検討する必要があります。しかし、最終的に、POはプロジェクトの費用を負担する人を表し、ショットを呼び出します。特定の質問については：
- POが設計に関する詳細な期待を持っている場合、これらは、開発を開始する前にブランディング/ CIガイドとして提供する必要があります。開発中のUIを確認した後でのみ詳細な変更を要求することは理想的ではありませんが、POがこれらの変更が非常に重要であると感じ、結果を受け入れようとする場合、つまり、代わりに目的の変更を実装する必要があったため、機能が反復から削除されました、それも大丈夫です。
- アーキテクチャの特定の要素を選択することは確かにPOのドメインですが、開発が始まる前に行うべき非常に多くのことです。後で基本的な変更を行うと、大幅な遅延が発生します（現在のSprintを中止し、少なくとも次のSprintを主に使用してこれらの変更を実装する必要があることはほぼ保証されています）。繰り返しになりますが、POが結果を受け入れる場合、それは彼の決定です。いいえの場合、プロジェクトにはスクラムの主要な基盤が欠けているように見え始めます。つまり、全員が共通の目標に取り組み、そこに到達するための合理的な決定を下しているという仮定です。
- 繰り返しますが、それは最終的にPOの決定です。この種のことは、アナリストが持っていないドメイン知識を持っている可能性があるため、未解決の質問がある場合はPOと話し合うことは完全に問題ありません。しかし、問題を研究した人が推奨する理論的根拠とは異なる方法で行動することを主張した場合、理論的根拠がなければ、それは仕事に適さない人を強く示唆します。
- 何かをウィザードとして実装するか、単一の複雑なページとして実装するかは、チームがPOに決定を求めることができるものの非常に良い例です。しかし、彼に詳細について常にフィードバックを与えることは効率的ではありません。基本的には、チームに完全なユースケースを実装させ、確信が持てないことや重要な作業を完了したときにたまにしかフィードバックを得られないようにするというアイデアです。例に戻ると、POの決定を取得した後、チームはウィザードまたはページ全体のGUIモックアップを作成し、それをPOに表示してフィードバックを取得し、1つまたは2つの変更を加えて実装し、次にスプリントレビューの完全な実装。
1.スクラムチームにデザイナーがいる場合、POはUIデザインに干渉する必要がありますか？
そうだと思います。POはUI /ユーザビリティの問題において究極の世界を持っています。もちろん、技術的な観点から可能なオプションを評価し、潜在的なユーザビリティやあらゆる種類の問題を指摘することさえ、開発者の責任です。しかし、最終的に、POが代金を支払う意思がある場合（現金、開発/ユーザー時間の損失、生産性の低下など）は、POが選択する権利です。
開発者は、迅速なプロトタイプを使用したアプローチの実行不可能性を実証したり、初期リリースや定期リリースのフィードバックサイクルを使用したりすることもできます。そしてもちろん、理解しようとすることは常に役に立ちますなぜ POは特定のソリューションを好む-それは彼がそれのための正当な理由を持っているかもしれません。コミュニケーションは常にアジャイルであるための主要な要素です。
しかし最終的には、（時々または定期的に）愚かな決定を下すPOがいます。プロセス自体の問題ではないと思います。実際、スクラム/アジャイルは、特定のアプローチの長所と短所を議論するための多くの可能性を提供し、POが比較的簡単に彼/彼女の心を変えることを可能にします。これは、従来のプロセスを多用するアプローチが提供するものよりもはるかに優れています。
2.POはコーディングの設計とアーキテクチャに干渉する必要がありますか？
「干渉」の定義に依存します:-)すべての可能なアーキテクチャの選択（たとえば、Oracleを使用するかMySQLを使用するか）を評価し、すべての潜在的なコスト、リスク、および利点を明らかにするのは開発者の責任です。その後-開発者が提案/設定を行いますが、それは通常真剣に受け止められるべきです-最終的にはPOが選択する権利です。例えば。 OracleはMySQLよりもはるかに高価であり、技術的には目前のタスクよりも優れていませんが、既存のインフラストラクチャはすべてOracleベースであるため、POはOracleを選択している可能性があります。
3. POは検証メカニズムに干渉する必要がありますか？たとえば、このフィールドは必須ですが、ユーザーからこの情報を取得する必要はありません。
これは基本的にユーザビリティの問題だと思うので、質問1のサブケースです。
4.POはどの程度きめ細かくPOを分析および設計できますか？
ここで取り上げる例は、UI設計の問題であり、プログラム設計の問題ではありません。再び、ケース1が適用されます。ただし、POには通常、専門知識も関与する必要もないため、プログラム設計は開発者の領域である必要があります。
更新
結論として、私はあなたがここで人々の問題を抱えていると感じています：あなたの特定のPOはプロジェクトをマイクロマネージメントしているかもしれません。私は、先の質問への回答に同意する傾向があります。これは歪んだ「スクラムですが」プロセスを作成したようですが、イニシアチブを取り、チームメイトとPOとの通信を開始すると修正される可能性があります。 POがあなたの懸念を受け入れない場合でも、より良いプロジェクト/職場を探し始める方が良いかもしれません...？
製品の所有者は製品の金銭的責任を負います。
それはすべてを言います。これは、次の場合に非難される最初の人物が製品の所有者であることを意味します。
- 製品はお金を稼ぐことはありません
- 製品は要件を満たしません
- 製品は期待に応えません
- 製品は利害関係者を満足させません
- 製品はエンドユーザーを満足させません
それであなたは今どう思いますか？
- はい、製品の所有者はデザインに干渉する可能性があります。 POは、エンドユーザーが何を期待しているかを知っている必要があります。おそらく、エンドユーザーは他のアプリケーションで同様のUIを使用しており、同じユーザーエクスペリエンスを持つ新しいアプリケーションを期待しているだけです。
- はい、製品の所有者は技術を要求できます。これは非機能要件と呼ばれ、スクラムにも存在します。 ASP.NETにLinuxサーバーアプリケーションしかない場合、MVCは役に立たなくなります。
- はい、おそらく顧客は背後で魔法を望んでいません。
- ユーザーストーリーについてさらに議論するための情報を維持するために必要なレベルまで。これは通常、プロジェクトのタイプとそのサイズによって異なります。いくつかのノートで十分な場合もあれば、もう少し必要な場合もあります。
とにかく、スクラムとアジャイル方法論はコミュニケーションについてです。製品の所有者と戦争をしてはならず、製品の所有者は顧客の基準を満たすために必要な干渉のみを行う必要があります。彼は個人的な関与を開発者の仕事に入れるべきではありません。それは彼らの責任です。チームが製品の所有者に乗っ取られないように制御する責任があるのは誰ですか？スクラムマスター-彼の役割を超えるのは、製品の所有者に対してさえチームを守ることです。
あなたが言及した質問への回答の1つに対する優れたコメントがあります。クレジット @ StevenV 誰が書いたか：
（すべてのアジャイル手法と同様に）スクラムは、指示よりも会話に重点を置きます。 POは、最終結果を達成するために何が必要かを説明し、そこに到達する方法について設計者と開発者を関与させる必要があります。 – StevenV 2011年8月16日12:17
製品の所有者は要件を述べる必要があります。要件は、要件が満たされているか満たされていないかを客観的に判断できるように、十分正確に記述する必要があります。上記の例では、要件に「ドロップダウンリストに2つの選択肢yesまたはnoがあるはず」という文言があるか、または「ユーザーが選択できるオプションがあるかどうか」という文言があるかもしれません。 「」。最初のケースでは、チェックボックスが表示されたPOは「要件を満たしていません」と言うことができます。 2番目のケースでは、チェックボックスが表示されたPOがシャットダウンするか、要件を変更します（遅延の責任を負います）。 POは、要件を実装する方法を設計者に伝えてはなりません。
一般に、POは顧客が何を望んで何を支払う意思があるかを知っているはずであり、実装コストについてある程度の知識を持っている必要があります（開発者は確かに要件を実装するのがいかに難しいかフィードバックを提供でき、要件をわずかに変更したことをアドバイスできます大幅なコスト削減につながります）。開発者と設計者は、ソフトウェアの開発方法とユーザーインターフェイスの設計方法を知っているはずであり、POよりも優れているはずです。
プロダクトオーナーが要件を満たし、インプリメンターが要件を満たせば、POなしでインプリメンターが会い、設計し、提供方法（アーキテクチャ、デザイン、コード）を確認できないのはなぜですか？プロダクトオーナーが立ち会う必要がある場合、そのアーキテクト/デザイナー/コーダーが仕事をするために、要件を十分に明確に説明していないことを意味します。プロダクトオーナーは、コードの実行方法の長所/短所、または詳細も知りません。彼らは顧客との話し合い、要件の収集で忙しいです。
プロダクトオーナーによる被害を確認しました–アーキテクチャ/設計/コーディングを知っていると想定して...主な仕事は何であるか（顧客、要件）に固執し、それを上手く行います...設計とコーディング）–私たちの専門知識–「私たちは補完的なチームです（矛盾したり、採用された責任が重複したりすることはありません）」