スクラムでのプロジェクトマネージャーの役割は何ですか？
スクラムでのプロジェクトマネージャーの役割は何ですか？
PMをSCRUMマスターにすることは、PMがプロジェクトを監督するのと同じように、マスターは、ワークパッケージの管理により関心があります。
私の考えでは、PM SCRUM MasterがPRINCE2の原則の1つである例外によってマナギンに反対するため、.
PMは次のことにもっと注意する必要があります：
プロジェクトの範囲を確立し、プロジェクトのビジネスケースが有効であることを保証する
反復回数の計画
ソフトウェアのリリース日を含むプロジェクト全体の計画を維持する
スクラムチームが必要とする外部リソースの取得。ユーザー受け入れテストのユーザー
スクラムチームによってエスカレートされるリスクと問題の管理
進捗状況の報告を含む役員とのコミュニケーション
SCRUMを使用してアジャイルプロジェクトを管理した経験のあるPM（またはSCRUMマスター）は、2つの役割を組み合わせることができるか、または組み合わせる必要があるかどうかについて、経験/意見を述べることができますか？
スクラムでは、PMの従来の役割は、実際にはプロダクトオーナーとスクラムマスターの役割に分けられます。責任もスクラムチームの全員にあります。
プロダクトオーナーは、プロジェクトの範囲を定義し、プロダクトのバックログを維持することで作業に優先順位を付け、作業を将来のイテレーションに継続するかどうかを決定し、ユーザーと顧客の代表としてリスク管理と軽減戦略に関与する責任があります。つまり、プロダクトオーナーは、ユーザーと顧客に関してチーム外で発生することを扱い、この情報の単一の焦点を提供します。
スクラムマスターは、よりプロセスとチーム指向です。この担当者は、リソースを管理し、リスク管理と軽減戦略を頻繁に取り上げ、プロセスを処理し、情報を必要とするがスクラムチームに参加していない人々が情報にアクセスできるようにし、実行中の作業とすべての作業を可視化します。チームの成功と失敗。
一部の作業は全体としてチームに委任されます。たとえば、単一の個人が組織と指示を提供することはありません。チームは全体として、製品のバックログと以前のデータを使用して、スプリントで実行する作業量を決定します。また、リスク管理はチーム全体に当てはまるもう1つのアクティビティであり、スクラムマスターがプロセスを促進します。
最後に、いくつかのコンセプトはスクラムにまったく対応していません。
必要な反復の合計数についての事前の考えはありません。アイデアは、イテレーション（多くの場合2〜4週間）にタイムボックスを設定し、価値を追加する潜在的に出荷可能な成果物を持つことです。バックログが空になるか、顧客のニーズが変化してプロジェクトが終了すると、別のイテレーションへの資金提供は、実行可能な作業によって付加される価値よりも高くなります。もちろん、それは盲目的な考えではありません。プロジェクトが終了状態に近づいたときに、バックログを監視し、プロダクトオーナーと協力することでわかります。
さらに、リリース可能なソフトウェアは、すべてのスプリントの完了時と同じくらい頻繁に作成されます。アイデアは、すべての反復の終わりに付加価値製品があるということです。この製品は、内部で設計、実装、テストされ、受け入れテストを受けています。製品に関連するすべてのドキュメントとガイドも最新です。つまり、顧客がそれを望めば、彼らはそれを手に入れることができます。ただし、すべてのスプリントの最後に製品を展開する努力を望まないかもしれませんが、それはオプションです。変化に敏感であるため、スプリント計画会議で実際に出荷された製品を示すことができるはずです。
プロダクトオーナーとスクラムマスターの役割を組み合わせることは、異なることに関心があるためお勧めできません。プロダクトオーナーは、エンドユーザーと顧客の観点から取り組んでいます。可能な限り短い時間で最大の価値を提供し、高品質の製品を要求します。スクラムマスターはチーム中心であり、チームが過労状態にならないようにし、最高の仕事をするために必要なリソースを確保し、一般に幸せで生産的な人々であることを保証するカウンターバランスを提供します。個人的には、十分なスキルを持った人なら、おそらく両方の役割を果たすことができると思います。ただし、そのためには熟練したマネージャーとリーダーが必要です。 スクラムマスターとプロダクトオーナーの役割の組み合わせに関するProject Management Stack Exchangeの質問 には、これに関する多くの情報があります。
@Thomas Owensの回答に完全に同意しますが、自分の経験を追加しています。
典型的なスクラムプロジェクトでは、PMはありません。 PMロールは、プロジェクトのすべての参加者-PO、スクラムマスター、チームに分割されます。スクラムプロジェクトをスケーリングするとき、または企業環境でスクラムを適用しようとするとき、= PMは便利です。
アジャイルのスケーリングは一般に困難な作業であり、通常、スケーリングを成功させるには、計画に基づく追加が必要です。 PMプロジェクト全体の一番上にいて、チームのスクラムマスターとプロダクトオーナーの助けを借りてプロジェクトを調整できます。
スケーリングに取り組む必要はありません。アジャイル方法論を使用しない別のチームと作業を統合する必要がある場合はそれで十分です。そのような場合、多くの追加の調整が必要です。通常、非アジャイルチームを調整する負担をスクラムマスターまたはプロダクトオーナーに課すことはできませんが、従来のPM両方のチームを調整し、スクラムマスターおよびプロダクトオーナーと協力することはできます。
全体の話は、企業/企業環境と官僚制です。会社自体がアジャイルな考え方に移行しなかった場合は、PMが必要であり、おそらく彼はあなたのアジャイルな世界と会社の官僚の間の「アダプター」になるでしょう。
開発者としての私の見方では、プロジェクトマネージャーがいるような組織であれば、プロジェクトマネージャーがスクラムに参加するのは良いことです。スクラムにおけるこの人物の役割は、ビジネスの残りの部分がスクラムを理解できるよう支援し、スクラムと組織の一般的なソフトウェア開発プロセスとの調整で問題が発生した場合にスクラムマスターとプロダクトオーナーが行くことができる誰かとして行動することです。したがって、彼女はスクラムと組織の典型的なプロセスの両方を深く理解して、両者の間のバッファーとして機能できるようにする必要があります。
ビジネスが全体としてスクラムをより完全に受け入れるようになると、プロジェクトマネージャーがおそらくプロダクトオーナー、スクラムマスター、またはアジャイルコーチへの移行に集中できるようになるまで、これらの問題が少なくなるため、役割はますます重要でなくなると思います役割。