スクラムチームメンバーまたはスクラムマスターの1人をプロダクトオーナーとして指名することは良い考えですか？
最近、私たちはクライアントがツアーで忙しいプロジェクトをしていました。通常のスクラムチームが結成されたため、クライアントは積極的に参加できないため、経営陣はアナリストをプロダクトオーナーとして指名することを決定しました。アナリストは、要件分析と仕様作成のためにクライアントと緊密に連携した人物でした。
クライアントには、最初の2つのリリースを確認する時間がありません。クライアントが3番目のリリースを見るまで、すべてが順調に進みました。彼はいくつかの機能に満足していなかった、そしてそれらはメイクシフトプロダクトオーナー（私たちのアナリスト）によって紹介されました。
設計チームがすべてのページのモックアップを終了し、クライアントが各ページをチェックして作業を続けることを承認するまで待つように言われました。スクラムチームは存在しますが、スプリントはありません。従来のウォーターフォール方式とほぼ同じように作業を完了しました。
スクラムチームのメンバーまたはマスターをプロダクトオーナーとして指名することは良い考えですか？クライアント/製品所有者の参加がない場合、スクラムに従う必要がありますか？
それはほんの数週間前のことです マイクコーンが彼のブログでスクラムマスターと製品所有者の役割の組み合わせについて書いています 私は彼よりもうまくいくとは思えませんが、私の短い要約彼の投稿はこれです：
- それは悪い考えです
- SMとPOは非常に異なる種類のタスクを実行します（コーンの言葉で「スタータスク」と「ガーディアンタスク」）
- 2つの役割を組み合わせる人は、両方の役割に関係するすべてのタスクに適しているとは考えられません。
- チームは、SM/POの組み合わせが得意ではないタスクを無視することによって傷つく可能性があります。
スクラムチームのメンバーを1人連れて、プロダクトオーナーに移動すること自体に問題はないと思います。しかし、それはプロモーションや内部転送のようなものであることを理解する必要があります。チームに穴ができ、穴を埋める必要があります。おそらく、チームは「自己再編成」して穴を埋めることができます。多分それは空いているポジションを満たすために新しい従業員を雇う必要がある。
あなたのプロセスは私には問題ないようです。あなたはそれを詳細に説明しませんでしたが、少なくとも、役割は尊重されます（これは重要です）。
しかし、私が持っているいくつかの詳細では、製品所有者レベルでいくつかの問題を見ることができます。
彼/彼女は顧客に進捗状況が適切に通知されることを確認する必要があります。彼は顧客と外部で「ウォーターフォール」を、内部で「スクラム」をあなたとやっているようです。
結果：顧客が王であるので滝が勝ちます。この場合でもお客様の責任は...
現在のチーム（スクラムマスターを含む）は、スプリントバックログの配信に集中する必要があります。ただし、製品の所有者（アナリスト）は、バックログの内容が顧客の希望を反映していることを確認する必要があります。彼女/彼はまた、コミュニケーションが良好であることと顧客が参加していることを確認する必要があります。
可能な解決策：製品の所有者（アナリスト）を スクラム製品の所有者コース に送信するか、または彼/彼女に読んでもらいます（そして理解してください）この本： スクラムによるアジャイル製品管理 。
スクラムは、実際のクライアントが適切に配置されている場合に最適に機能します。反復的な製品設計に慣れていないクライアントに対処するには、いくつかの真の課題があります。
- 白紙症候群
- 怖いクライアント症候群
空白のシートを使用したデザインステージは、非常に速く空を飛ぶ傾向があり、通常、いくつかの側面の問題では非常に深く入り、必要なコア機能には十分な深さがありません。クライアントが設計会議を成功させるためにバラバラにするためには、ストローマンが本当に必要です。一度に1つの側面のみに集中することで、クライアントが反復設計を学習するのを支援します。
怖がっているクライアント（経験にあったような）は、アジャイルプロジェクトがプロセスの一部として特定の（制御された）量のやり直しを予期していることを理解していません。彼らが把握するのに苦労しているのは、製品開発が進むにつれて、「オーマイゴッド」の瞬間が少なくなるということです。さらに重要なことに、ほとんどのクライアントが苦労しているのは、レビュー/計画サイクルの時間が短いため、「オーマイゴッド」の瞬間を修正するのに大量のお金を必要としないことです。
クライアントの期待を管理することは非常に困難です。これは、顧客教育、満足感、さらには「ノー」と言うことの学習のバランスが取れています。クライアントは、毎週または隔週で来ることができない場合があります。時々、彼らは月に一度しか来ることができません。それで大丈夫です。前月の懸念に対処するために何をしたかを彼らに示し、今月の仕事に集中する限り、プロジェクトをよりスムーズに進めるための長い道のりになります。結論としては、顧客が不在の場合、いくつかの質問に対して合理的な推奨を行う担当者がいます。クライアントが達成しようとしている目標に精通している必要があります。
投稿ありがとうございます。私はそれが古いことに気づきましたが、あなたは素晴らしい事件を提起したと思います、そしてここに私の$ .02があります：
問題1：あなたのケースで分析者をPOとして任命する真剣にスクラムフレームワークを短絡させます。どうして？ POだけが価値の判断、ROIの評価、優先順位付け、決定的な選択を行うことができるため、テクノロジーからではなく、製品の知識からでも、ビジネスから流れてきます。きっとあなたのシニアだ。アナリストは、POを模倣する素晴らしい仕事をしましたが、最終的にはPOから来る欲望、価値、選択を推測する必要がありました。 ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ 。アナリストがクライアントからPOAを付与されていない場合（そうでない場合）は、スプリントレビューで何も受け入れたり拒否したりすることはできません。
このアプローチはうまくいくでしょうか？はい。ただし、クライアントが不在の間に責任を全面的に移転する必要があります。クライアントのボスは、代理に同意する必要があり、合理的な決定が下されることはありません。聞こえそう？クライアントの組織から一時的なPOを取得する可能性が高くなります（これには確かに欠点があります！）。アナリストが一時POを使用して作業した場合、不正確な決定はビジネスから行われるため、チームの役割を明確に保つことができます。
問題2：「クライアントに確認する時間がない」。大きな問題（そして私が最近遭遇した問題）。製品を受け入れるには、POが存在している必要があります。他の誰も「小切手に署名」することはできません。 POの不在は、後で不満が生じ、潜在的にやり直しが増え、信頼が失われることを意味します。より基本的には、クライアントがプロジェクトに積極的に関与していないと感じています。毎日のスタンドアップの時間がない、質問に答える時間がないなどです。
問題3：「設計チームがモックアップを完了するまで待つように言われました」。そして今、完全にスクラムから外れています。モックアップを行う人々は、部署を超えたチームの一部である必要があります。これがスクラムに対する経営者の理解の欠如によるものか、3回目のリリースに対するショック反応によるものかはわかりません。
質問：これらすべての中であなたのスクラムマスターはどこにいましたか？ SMは通常、役割の競合の危険性とPOの参加の欠如を認識しますが、どちらも対処すべき障害/危険性です。
理想的には、製品の所有者は、プロジェクトに関するある程度の権限と知識を持っています。これと同じことが、クライアントがより低いレベルの従業員を割り当てた場合にも発生する可能性があります。