プロジェクトマネージャーはスクラムで役に立ちますか？

スクラムには、チーム、プロダクトオーナー、スクラムマスターの3つの役割が定義されています。プロジェクトマネージャーはいません。代わりに、プロジェクトマネージャーの仕事は3つの役割に分散しています。

例えば：

• スクラムマスター：プロセスの責任者。障害を取り除きます。
• プロダクトオーナー： ROIを最大化するために実行する作業のリストを管理および優先順位付けします。すべての利害関係者（顧客、利害関係者）を表します。
• チーム：自分自身で作業を見積もり、配布することにより、作業を自己管理します。自らのコミットメントを満たす責任があります。

したがって、スクラムでは、プロジェクトの成功を担当する責任者は一人もいません。コマンドとコントロールの構造はありません。それは多くの人々、特にアジャイル手法に慣れていない人々、そしてもちろんPMを困惑させているようです。

私はこれとスクラムの実装を壊す可能性があるものの1つだと思うので、これとあなたの経験に本当に興味があります。

プロジェクトマネージャーは必要ないという点でスクラムに同意しますか？そのような役割はまだ必要だと思いますか？どうして？

たぶん、あなたはこのようなものを提示する必要があります：

プロジェクトマネージャーはスクラムで消えませんでした。彼はまだそこにいます。あり3今それらの！

• スクラムマスター：彼はプロセスを管理し、障害を解決します。それは、以前はプロジェクトマネージャーの責任でした。

• プロダクトオーナー：彼はバックログを管理します。Microsoft Projectのすべてを予測する前に、それはプロジェクトマネージャーの責任でした。

• チーム：生産を自己管理します。特定のユーザーストーリーが誰とどのようにリリース可能な製品の増分に変換されるか。彼がタスクを割り当てたとき、それはプロジェクトマネージャーの責任でした。

私にとってこれは、プロジェクトマネージャーが何をするのか理解していないことと、PMタイトルのかなり一般的な性質から来ています。私はSCRUMの専門家ではありませんが、SCRUMマスターはプロジェクトマネージャーではなく開発マネージャー/チームリーダーに取って代わるものとして常に見てきました。

プロジェクトマネージャー（PRINCE2などの方法論で定義されている-これはアジャイルの方法論とほとんど互換性があります）は、実際には開発プロセスとは何の関係もありません。彼らは、ITだけでなく、ビルドします。プロジェクトマネージャーの役​​割には、スクラムの他の部分ではカバーされていないものがたくさんあります（ビジネスケースの管理と監視、ビジネスステークホルダーの管理、ビジネスプロセスのリワークなどのITビルド外のプロジェクトの要素、サポート、トレーニングなど）。

あなたのPMが開発者の面倒を見る人であり、それ以上のことをしなければ（たとえば、スコープがかなり明確に定義されているITのみのプロジェクトで）、彼は必要ないかもしれませんSCRUMプロジェクトで。

しかし、誰かがあなたがSCRUMのためにPMを必要としないと言う前に、プロジェクトの非IT要素がどのようにカバーされているか、特に誰がビジネスケースを管理しているのかについてかなり明確な説明が欲しいそして、それがなすべきことは異なることです）。

PMがプロジェクトのビジネス側により多く座ることになるかもしれません-プロダクトオーナーはスクラムマスターよりもPMの役割を引き受けるかもしれませんが、彼が完全に去る可能性は低いと思います。

プロジェクトマネージャーができることには、スクラムマスターやプロダクトオーナーにはできないことがいくつかあります。

• 通常、プロジェクトマネージャーは、プロジェクトの実行に豊富な経験を持っています（驚き！）。
• 彼らはよくある落とし穴を知っており、それらを発見し、発生する前に立ち向かう手助けをします。
• 彼らは通常、経験豊富な交渉担当者であり、期限、範囲、矛盾する要件に関する議論で他のチームメンバーをサポートできます（POの役割がかなり新しい場合は非常に重要です）。
• 彼らはお金を管理できます。彼らには雇用と解雇の権限があり、チームの誰かが自分の役割を果たせない場合（トレーニングの手配、カウンセリングなど）に役立ちます。
• それらは、プロジェクトがより大きな作業プログラムに効果的に適合することを保証するのに役立ちます。
• チームの邪魔にならないようにすることができます。
• それらは、会社のポリシーがスクラムとともに効果的であるように導くのに役立ちます（たとえば、見つかったバグの数によってテスターがまだ測定されている場合）。
• ガバナンスを管理できます。
• 彼らは家具を動かすことができます。
• 彼らの語彙は大企業のものであり、リスク、影響、ROI、オプション、差別化の観点からプロジェクト（およびスクラムアプローチ）について議論できます。
• 彼らは、なぜ突然の透明性と時折の失敗のニュースが、大量の緑の報告書を通して出てくるのかを知っておくと有益である理由を取締役会に説明できます。
• 優れたPMを使用すると、安全で、かっこよく、見栄えがよくなります。

スクラムはPMを義務付けていません。とにかく、あなたはそれを持ちたいかもしれません。

私が取り組んだプロジェクトの1つで、スクラムになったときに、以前のプロジェクトマネージャーがプロダクトオーナーとスクラムマスターの役割を代わりに引き受けました。私にとっては理想的ではありませんでしたが、そのチームで過ごした6か月間はうまくいきました。彼は物事を厳しく管理したいと思っていたが、かなりうまくやっていた（つまり、チームに仕事をさせ、適切なときに決定を下す）人のような人でした。

この背景には、会社がひどい財政状況にあったということがありましたが、私たち（チーム）はしばらくしてからそれについて知りました。そのため、絶対に必要なものだけがビルドされ、製品の最初のバージョンが時間通りに配信されるように、すべてを厳重に管理する理由がありました。

私は公平であり、私の考えでは、私にとって有効なのは、プロジェクトマネージャーとしても活動しているスクラムマスターです。スクラムマスターになることはフルタイムの仕事ではありません。チームが成熟したら、スクラムマスターは毎日のスタンドアップに参加する必要さえありません。
企業がこれらの役割を区別したくない-プロジェクトアジャイルプロジェクトマネージャーなど、両方の役割を担当するプロジェクトマネージャー/スクラムマスターには、空席が増えています。

プロジェクトマネージャー：従来の組織または企業内の役割。

スクラムマスター：スクラム手法を使用したソフトウェア開発チーム内の役割。

プロジェクトマネージャーとスクラムマスターについて話すのは、役割が異なるコンテキストを持っているため、実際にはリンゴとオレンジについて話している。「スクラムマスター」を正式な称号または給与等級として持っている組織について聞いたことがありません。また、スクラムなどのあらゆるプロジェクトのプロジェクトマネージャーは、日々のソフトウェア開発活動から幾分削除されます。

プロジェクトマネージャーが行うこと、およびその役割がスクラムマスターまたはプロジェクトオーナーの役割とどの程度重複するかは、プロジェクトの規模と性質に大きく依存しますが、通常は具体的にプロジェクトマネージャーに起因するタスクはありませんスクラムマスターまたはプロジェクトオーナーの役割の一部。小さなプロジェクトでは、スクラムマスターまたはプロジェクトオーナーの役割の職務を拡張して、それらのタスク（雇用、解雇、購入、契約管理、上級管理職とのやり取りなど）を含めることができます。大規模なプロジェクトでは、ソフトウェア開発はプロジェクト管理の一部に過ぎず、プロジェクトマネージャーとスクラムマスターの職務が重なることはほとんどありません。

プロジェクトマネージャーは、組織に対するスクラムマスターのインターフェイスである必要があります。スクラムマスターは、プロジェクトマネージャーのチームへのインターフェイスである必要があります。

では、プロジェクトマネージャーはスクラムで役に立ちますか？いいえ、プロジェクトマネージャーはスクラム以外では役に立ちます。これらはスクラムソフトウェア開発方法論の一部ではありませんが、スクラムを機能させるリソースを提供します。

この質問はScrumbutのにおいがします。

スクラムは、プロジェクト管理方法（Prince2 / PMPなど）に含まれるもののサブセットです。実際、Prince2プロセスMP（製品配信の管理）を見ると、スクラムのすべての要素をそこに含めることができます。

スクラムマスターは、ベンダー、人事、法務、財務、サプライヤー、経営幹部、またはBAUの活動との会議で行き詰まることを望みません。彼らは、2011/12年度に雇用代理店が請負業者の料金をどの程度削減できるかを交渉したり、ベンダーxとのエスクロー契約を検証したりするのではなく、現在のスプリントでチームから障害を取り除くことに集中する必要があります。

スクラムマスターが上記を実行している場合、スクラムを実行しているのではなく、スクラムビュートを実行しています。

経験から、最良の組み合わせは、各チームリーダーのスクラムマスターと、スクラムスクラム形式でスクラムマスターを調整するプロジェクトマネージャーを持つことです。上記の理由と経験の深さにより、この役割のプロジェクトマネージャーがより効果的になる。次に、これらのプロジェクトマネージャーはポートフォリオ/プログラムマネージャーなどに報告し、指揮系統のすべてが少なくとも認定スクラムマスターです。

スクラムは製品の配信を管理するためのツールであり、抽象化のレイヤーではプロジェクトの実行に使用できることを忘れないでください。

従来のプロジェクトマネージャーの役​​割の主な問題の1つは、権限と責任を分離することです。PMはプロジェクト組織に対して完全な権限を持っています-（s）実行する必要があるタスク、誰、どの順序などを決定します。しかし、（s）これらのタスクの完了またはソフトウェアの品質について責任を負いませんそれが生産されます。チームメンバーのみが責任を負います。これにより、運用上の作業と同期して権限と意思決定を取り戻すために、チームメンバーはチームの他のメンバーに加えて行われたすべてをPMに常に報告しなければならないため、通信のオーバーヘッドが大きくなります。また、チームメンバーに没収感、無力感、目的の喪失をもたらします。これは、フラストレーションと落胆の大きな原因となります。

アジャイルはどういうわけかこれらの概念を元に戻します-作業組織に対する権限はチーム全体で（リリース、イテレーション、毎日の会議を通して）保持されるため、誰もがそれぞれの問題について発言できるように感じますチームのメンバーは、機能する高品質のソフトウェアを作成する責任を負い、その目標に向けて強力なコミットメントを行う必要があります。したがって、理論的にはプロジェクトマネージャーを取り除くことができます。

あなたがそれを言った後、まだ世話をする必要があるまだ伝統的にPMに割り当てられた義務があります-lunivoreはそれらを非常に正確に説明しました。

この記事は示唆して、真のマルチ熟練したチームで、あなたができる一つのことは、チームメンバー間でその職務を再配布し、旧PMが定期的にチームのメンバーになる必要があり、プロジェクトマネージャーの役割を破棄しています。

スクラムの役割は非常に明確に定義されており（漠然と思われる場合は、さまざまなタイプの組織に適用できるようになっているためです）、スクラムチームは常に（まあ、一般的に）ほぼ同じサイズです（つまり、あまり大きくありません）基盤となる組織によって異なる場合でも、それらが何を包含するかに同意するのは比較的簡単です。

上記の質問、回答、コメントを読むと、プロジェクトマネージャーの役​​割の定義を特定するのがはるかに難しいことは明らかです。PMの役割についてのすてきで一般的な定義を見つけることができると確信していますが、実際にそれが実際に意味することは、まったく異なる話です。

とにかく、私の仕事で働いているので、プロジェクトマネージャーが実際の「スクラミング」に関与することはほとんどありません。スクラムマスターになることは許可されていません（私たち全員が非常に満足している地域の利益相反ルール）。また、例外的なケースでは製品所有者のみです。

私が働いている場所では、プロジェクトマネージャーはまだそこにいて、いつもやっていることをほとんどやっています。つまり、プロジェクトを順調に進め、過剰な妄想や「上」からのミクロ管理傾向に対するフィルターとして機能し、解決するよりも影響力が必要な問題を解決します。

これは他の場所ではまったく異なると確信していますが、私たちにとってはうまく機能します。

編集：たぶん私たちにとって、スクラムチームはプロジェクトチームに取って代わるものではないことを明確にする必要があります。一つまたは複数のスクラムチームは、実際の開発作業を実行するために開始されたため、プロジェクト（および通常で）。スクラムチームは、プロジェクトリーダーを除き、古いチームメンバーで構成できます（おそらく常にそうです）。