スクラムでプロジェクトマネージャーは役に立ちますか？
スクラムには、チーム、プロダクトオーナー、スクラムマスターの3つの役割が定義されています。プロジェクトマネージャーは存在せず、代わりにプロジェクトマネージャーのジョブは3つの役割に分散されます。
例えば：
- スクラムマスター：プロセスを担当します。障害を取り除きます。
- 製品オーナー： ROIを最大化するために実行する作業のリストを管理および優先順位付けします。すべての利害関係者（顧客、利害関係者）を表します。
- The Team：自分自身で作業を見積もり、配布することで作業を管理します。自分の責任を果たす責任があります。
したがって、スクラムでは、プロジェクトの成功に責任を持つ人が一人ではなくなりました。コマンドと制御の構造はありません。それは多くの人々、特にアジャイル手法に慣れていない人々、そしてもちろんPMを困惑させるようです。
これはスクラムの実装を成功または失敗させる可能性があることの1つだと思うので、これとあなたの経験が本当に興味深いです。
プロジェクトマネージャーは必要ないということでスクラムに同意しますか？そのような役割はまだ必要だと思いますか？なぜですか？
多分あなたはこのようなものを提示するべきです：
プロジェクトマネージャーはScrumで消えませんでした。彼はまだそこにいます。 があります。
The Scrum Master：プロセスを管理し、障害を解決します。それは以前のプロジェクトマネージャーの責任でした。
製品オーナー：彼はバックログを管理します。彼がMicrosoft Projectのすべてを予測する前に、それはプロジェクトマネージャーの責任でした。
チーム：自分で制作を管理します。特定のユーザーストーリーを誰がどのようにしてリリース可能な製品の増分に変換するか。彼がタスクを割り当てたとき、それはプロジェクトマネージャーの責任でした。
私にとってこれは、プロジェクトマネージャーが何をしているか、PMタイトルの一般的な性質）を理解していないことが原因です。私はSCRUMの専門家ではありませんが、SCRUMプロジェクトマネージャーではなく、開発マネージャー/チームリーダーに取って代わる。
プロジェクトマネージャー（PRINCE2などの方法論で定義されているように、アジャイルの方法論とほぼ互換性があります）は、開発プロセスとは何の関係もありません。ITだけでなく、より広範な提供の観点からプロジェクトの世話をしていますビルド。プロジェクトマネージャーの役割には、スクラムの他の部分ではカバーされていないものがたくさんあります（ビジネスケースの管理と監視、ビジネス関係者の管理、ビジネスプロセスの再構築、サポートなど、ITビルド外のプロジェクトの要素）トレーニングなど）。
PMが開発者の面倒を見て、それ以上のことをしない人である場合（たとえば、スコープがかなり明確に定義されているITのみのプロジェクトの場合など）は、彼がSCRUMプロジェクトで必要になることはないでしょう。
しかし、PM SCRUMは必要ないと言う前に、プロジェクトのIT以外の要素がどのようにカバーされているか、特に誰が管理しているかについて、かなり明確な説明が必要です。ビジネスケース（ユーザーがそれを望んでいることと、実行する必要があることは異なるため）.
PMは、プロジェクトのビジネス側に座っていることになるかもしれません-プロダクトオーナーは、スクラムマスターよりもPMの役割を引き受けるかもしれませんが、彼が完全に消えてしまいます。
スクラムマスターまたはプロダクトオーナーができない場合があるため、プロジェクトマネージャーが実行できることがいくつかあります。
- プロジェクトマネージャーは通常、プロジェクトの実行に豊富な経験を持っています（サプライズ！）。
- 彼らは一般的な落とし穴を認識しており、それらを発見し、発生する前にそれらを回避するのを助けることができます。
- 彼らは通常、経験豊富な交渉担当者であり、期限、範囲、競合する要件（POが役割でかなり新しい場合は非常に重要です）に関する議論で他のチームメンバーをサポートできます。
- 彼らはお金を管理することができます。彼らには雇用と解雇の権限があり、チームの誰かが自分の役割を演じることができない場合に（トレーニングの手配、カウンセリングなどを通じて）支援することができます。
- それらは、プロジェクトがより大きな作業プログラムに効果的に適合することを保証するのに役立ちます。
- 彼らはチームの邪魔にならないものを手に入れることができます。
- それらは、スクラムと並んで効果的な会社のポリシーを導くのに役立ちます（たとえば、テスターがまだ見つかったバグの数で測定されている場合）。
- 彼らはガバナンスを管理できます。
- 彼らは家具を動かすことができます。
- 彼らの語彙は大企業の語彙であり、リスク、影響、ROI、オプション、差別化の観点からプロジェクトとスクラムアプローチについて話し合うことができます。
- 彼らは、グリーンレポートの海を通過する突然の透明性と失敗の時折のニュースが、なぜ知っておくと良いと役立つのかを理事会に説明することができます。
- 良いPMは、安全に感じ、クールに聞こえ、見栄えを良くするのに役立ちます。
スクラムはPMを持つことを義務付けていません。しかし、とにかく1つ用意したい場合があります。
私が取り組んだプロジェクトの1つで、それがスクラムになったとき、以前のプロジェクトマネージャーは代わりにプロダクトオーナーとスクラムマスターの役割を果たしました。それは（私にとって）理想的ではありませんでしたが、私がそのチームと過ごした6か月間はある程度うまくいきました。彼は、物事を厳重に管理したいと思っていたような人でしたが、それはかなりうまくいきました（つまり、チームに仕事を任せ、適切なときに決定を下させる）。
この背景には、私たち（チーム）がそれを知ったのはしばらくしてからですが、会社は悲惨な財政状況にありました。したがって、絶対に必要なものだけが構築され、製品の最初のバージョンが予定どおりに納品されるように、すべてを厳重に管理する理由がありました。
この質問は Scrumbut のにおいがします。
スクラムは、プロジェクト管理メソッド（Prince2/PMPなど）に含まれるもののサブセットです。実際、Prince2プロセスMP（製品配信の管理））を見ると、スクラムのすべての要素をそこに含めることができます。
スクラムマスターは、ベンダー、人事、法務、財務、サプライヤー、幹部、または [〜＃〜] bau [〜＃〜] アクティビティとの会議で行き詰まることを望んでいません。彼らは、現在のスプリントでチームから障害を取り除くことに集中する必要があり、2011/12会計年度に請負業者のレートをどの程度削減できるかを交渉したり、ベンダーxとのエスクロー契約を検証したりしない。
スクラムマスターが上記を実行している場合、スクラムを実行しておらず、スクラムバットを実行しています。
経験上、最良の組み合わせは、チームリーダーごとのスクラムマスターとプロジェクトマネージャーがスクラムマスターをスクラムスクラム形式で調整することです。上記の理由と経験の深さにより、この役割のプロジェクトマネージャーをより効果的にすることができます。次に、これらのプロジェクトマネージャーはポートフォリオ/プログラムマネージャーなどに報告し、指揮系統のすべてが少なくとも認定されたスクラムマスターです。
スクラムは製品の配信を管理するためのツールであり、抽象化の層では、プロジェクトの実行に使用できますが、そのための優れたプロセスはすでに存在しています。
私の見解では、私にとってうまくいくのは、プロジェクトマネージャーとしても機能するスクラムマスターでもあると思います。スクラムマスターであることはフルタイムの仕事ではありません-チームが成熟すると、スクラムマスターは毎日のスタンドアップに参加する必要すらありません。
企業がこれらの役割を区別したくない、つまり同じ人物が両方の役割を処理したい、つまりアジャイルプロジェクトマネージャーであるプロジェクトマネージャー/スクラムマスターに、ますます欠員が見られます。
スクラムの役割は非常に明確に定義されており（あいまいな場合は、さまざまな種類の組織に適用できるようになっているためです）、スクラムチームは常に（よく、一般的に）ほぼ同じサイズです（つまり、それほど大きくありません）。たとえそれが基礎となる組織によって異なるとしても、それらが包含するものについて合意することは比較的簡単です。
上記の質問、回答、コメントを読むと、プロジェクトマネージャーの役割の定義を特定するのがはるかに難しいことは明らかです。私はあなたが首相の役割の見事で一般的な定義を見つけることができると確信していますが、実際にそれが実際の生活の中で意味することは全く別の話です。
とにかく、私の仕事ではうまくいくので、プロジェクトマネージャーが実際の「スクラム」に関わることはほとんどありません。彼らはスクラムマスターになることは許可されておらず（私たち全員が非常に満足しているローカルの利益相反ルール）、例外的なケースでは製品所有者のみです。
だから私が働いているところでは、プロジェクトマネージャーはまだそこにいて、彼らがいつもやってきたことのほとんどをやっています。彼らがプロジェクトを軌道に乗せ続けること、過度のパラノイアや「上」からのマイクロマネジメントの傾向に対するフィルターとして機能すること、私たちが解決するよりも強い影響力を必要とする問題を解決することなどを意味します。
これは他の場所ではかなり異なると私は確信していますが、私たちにとってそれは素晴らしい働きをします。
編集：多分私は私たちのために、スクラムチームがプロジェクトチームを置換しないことを明確にする必要があります。実際の開発作業for（および通常はプロジェクト）を実行するために、1つ以上のスクラムチームが開始されます。スクラムチームは、プロジェクトリーダーを除いて、古いチームメンバーで構成できます（おそらく常にそうです）。
従来のプロジェクトマネージャーの役割の主な問題の1つは、権限と責任を分離することです。 PMはプロジェクト組織に対して完全な権限を持っています s）彼は、どのタスクを誰が、どの順序で実行する必要があるかなどを決定します。しかし、（s）彼は責任を負いませんこれらのタスクの完了または生成されるソフトウェアの品質。チームメンバーのみが責任を負います。これにより、権限と決定を運用作業と同期して戻すために、チームメンバーは常にすべてのことを報告する必要があります。 PMはチームの他のメンバーに加えて行われます。また、チームメンバーとの没収感、無力感、目的の喪失を引き起こします。これは、フラストレーションの大きな原因であり、落胆。
アジャイルはどういうわけかこれらの概念を元に戻します-作業組織に対する権限はチーム全体で（リリース、反復、毎日のミーティングを通じて）保持されるため、誰もがそれぞれの問題について発言できるように感じますチームメンバーは、機能する高品質のソフトウェアを作成する責任を負い、その目標に向けて強力に取り組む必要があります。したがって、理論的にはプロジェクトマネージャーを取り除くことができます。
あなたがそれを言った後でも、伝統的にPMに割り当てられている義務はまだありますが、それでもなお注意する必要があります-lunivoreはそれらを非常に正確に説明しました。
---（この記事 が示唆しているように、本当にマルチスキルのチームでは、プロジェクトマネージャーの役割を破棄し、チームメンバー間でその職務を再分配し、元のPMを通常のチームメンバーにすることができます。