apeescape2.com
  • メイン
  • その他
  • 製品ライフサイクル
  • プロセスとツール
  • 分散チーム
製品の担当者とチーム

規模が大きすぎる–最適なスクラムチームサイズガイド

この記事の音声バージョンを聞く

あなたが小さなスタートアップで働いているか、大企業で新製品に取り組んでいるかにかかわらず、1つのチームにあまりにも多くの人がいるときにポイントに達する可能性があります。早い段階で兆候を特定することで、チームの最も非効率的な段階に到達するのを防ぐことができます。

すべての製品は異なり、それらに取り組んでいるチームも異なります。したがって、チームを分割するには、状況を反映したいくつかの決定を行う必要もあります。考慮すべきいくつかの事柄は次のとおりです。



  • チームメイトが協力しなくなったときにノウハウの整合性を維持する方法
  • 機能(フロントエンドチームとバックエンドチームなど)に沿って分割する必要がありますか?
  • 新しいチームには個別のバックログが必要ですか?
  • 製品管理チームはそれに応じて成長する必要がありますか?

いつ2番目のチームの作成を開始する必要がありますか?

チームの分割や新しいチームの追加について考え始める最も明白な兆候は、予算が増えたときです。これは、スタートアップへの新しい投資ラウンドや、企業における製品の新しい目標に発生する可能性があります。予算の増加が非常に大きく、チームが3倍以上に成長する場合は、ノウハウを配布するために現在のチームを分割する必要があるのは簡単です。ただし、予算の増加が段階的であり、最終的に数人の新しい人を名簿に追加する場合、決定はそれほど明確になりません。たとえば、チームを7人から11人に増やす計画がある場合、分割が必要ですか?アジャイルは小さなチームを促進しますが、プロセスやツールを介した個人や相互作用も促進します。 2つ以上のチームがあると、必然的に、同期して作業できるようになるプロセスが増えます。

専門家は何と言っていますか?

アマゾンの創設者であるジェフ・ベゾスは、 2つのピザのルール 会議とチームの両方に。つまり、それぞれの人は、2つのピザが昼食を食べられるのと同じくらいの人数でなければなりません。

スクラムチームのための2つのピザのルール

ザ・ スクラムガイド 実際にスプリントバックログを実行している3〜9人のチームメンバーがいることをお勧めします。つまり、どちらかがスプリントバックログアイテムを実装していない限り、製品の所有者またはスクラムマスターを合計に含めることはありません。

これらの数値は直感的に理解できるようですが、その背後にはいくつかの数学もあります。チームについて考えると、すべての人はノードのようなものであり、他のノードにリンクしています。これらは、チームメート間の対人関係です。彼らは友好的、競争的、意地悪、または思いやりのあることができます。二人の関係がどうであれ、それでも一人一人の精神的能力を必要とするつながりです。チームが成長するにつれて、これらのリンクのこれらの数は直線的に増加しません。ノード間のリンクの式は(n(n-1)/ 2 )です。リンクの成長チャートは次のとおりです。

チームメンバー間のリンクの数

このグラフは、チームが大きすぎないときにチームが最も効率的に動作する理由を数学的な観点から明確に示しています。スクラムガイドで提案されている3〜9人のチームメンバーを採用すると、3〜36のリンクになります。 15人に成長した場合、100を超えるリンクがあります。このチームは、職務が非常に明確に定義されており、重複することはめったにない場合、または非公式のサブグループがいくつかある場合にのみ、効率的に運用できます。アジャイルの原則に基づいて作業する場合、どちらも当てはまらず、望まれません。

チームが大きくなりすぎている兆候

デイリースクラム

デイリースタンドアップと呼ばれることもあるデイリースクラムは、スプリントの進捗状況と障害について話し合うためのチーム全体の集まりです。スクラムガイドは、これらの時間を15分に設定することを提案しており、これはチームサイズの優れたリトマス試験です。チームが15分のバーをオーバーランしていることに気づき始めた場合は、次の2つのいずれかを示している可能性があります。

コミュニケーションデザインvsグラフィックデザイン
  • 毎日のスクラムは効率的ではありません。 人々はあまりにも多くの詳細に入っています。または、明確な発言順序がなく、チームメートが発言するのに時間がかかります。おそらく、製品の所有者またはスクラムマスターは、スプリントに関係のないさまざまな更新を提供する機会として毎日のスクラムを使用しています。
  • チームが大きすぎます。 毎日のスクラムが効率的であるにもかかわらず、15分を超過している場合は、チームの人数が多すぎる可能性があります。また、取得できる情報量には制限があるため、人々が興味を失っていることにも注意する必要があります。更新を提供する人が多すぎると、全員の進捗状況を追跡してチームのステータスを理解することが難しくなります。 。これにより、人々は内向きになり、他の人を助ける機会を探すのではなく、自分の進歩だけを振り返ります。

グルーミングとスプリントの計画

グルーミングとスプリント計画はどちらも、ユーザーストーリーを分析し、配信時間またはサイズを見積もることに関連するアクティビティです。より多くの人がいるとチームはより良い決定に到達するのに役立ちますが、人が多すぎるとチームが行き詰まる可能性があります。同じタスクを実行するには常にさまざまな方法があり、チームの人数に応じて両側の議論の数が増えます。

毎日のスクラムと同様に、非効率的な計画セッションとチームが大きすぎることを混同しないでください。最終的には、スクラムセレモニーを効率的かつ効果的にすることがスクラムマスターの仕事です。

回顧展

ふりかえりの間に、チームメンバーは議論や対立を解決し、作業プロセスを改善する方法を考え出すことができます。回顧展は、私たちに妥協の芸術を教えてくれます。それは、私たちが異なる当事者間の共通の基盤を探求するようにするからです。チームは、メンバーが彼らの違いについて妥協することをいとわないのと同じくらい強力です。

ただし、スプリント計画と同様に、チームメンバーが多すぎると、リンクが多すぎます。これらはすべて、潜在的な競合ポイントです。ふりかえりの間にますます一般的な根拠を見つけていないかどうかに気づき始めます。チームが大きすぎて、分割することでメリットが得られることを示している可能性があります。

チームを分割する方法

一見すると、チームの分割は比較的簡単な作業です。チームメンバーを2つのグループに分け、それぞれが同じように経験豊富な人々を持っていることを確認し、新しいチームの目標を定義します。ただし、新しいチームの将来の成功に大きな影響を与える可能性のある考慮事項がかなりあります。

チームを分割する際の考慮事項

チーム士気

おそらく心に留めておくべき最も重要なことの1つはチームの士気です。結局のところ、新しい構成で作業する必要があるのはチームのメンバーです。チームがアジャイルの原則に関して成熟している場合、チームは自分たちで分割できるはずです。チームメンバーは内部の関係を最もよく知っているため、これが最も望ましい結果です。誰が誰と最もよく連携し、誰が別々のチームに所属することで利益を得ることができるかです。

クロスファンクショナルチーム

スクラムは、「製品の増分を作成するために必要なチームとしてのすべてのスキルを備えた」部門横断的なチームを促進します。これは、2つ以上のチームにスケーリングする場合にも当てはまります。多くの開発者にとって、特にアジャイルに不慣れな場合、自然な傾向は技術的な線と一緒に考えることです。たとえば、チームは多くの場合、バックエンドチームとフロントエンドチームに分割したいと考えています。これはまれに意味があるかもしれませんが、 プロダクトマネージャー 、ほとんどの場合、それに対してアドバイスする必要があります。フロントエンダーでいっぱいのチームは、自分たちで製品の増分を提供することはできず、当然、彼らを結び付けるものである技術的能力についてもっと考え始めるでしょう。代わりに、彼らは顧客と彼らのニーズを満たす方法に焦点を合わせる必要があります。

もう1つの興味深い考慮事項は、チーム内の非開発の役割です。さまざまな状況で、チームには設計者、ビジネスアナリスト、またはQAスペシャリストが含まれる場合があります。チームを分割すると、特に多くの新しい人を採用していない場合は、これらの役割をどうするかに関してジレンマが発生します。彼らはチーム間で時間を分割する必要がありますか? 1つのチームだけに専念する新しい人を雇うべきですか?彼らは開発チームと協力するべきですか、それとも製品チームの一員になるべきですか?

各製品は非常に異なるため、これについての良い単一のアドバイスは実際にはありません。これらの決定は、途中でコースを修正する必要があるかもしれないことを念頭に置いて、チームと一緒に行うのが最善です。

チームには個別のバックログが必要ですか?

チームが分割されている場合、自然な問題は、チームが同じバックログで作業する必要があるのか​​、それとも別々のバックログを持つべきかということです。私たちは見ることができます スケーリングされたアジャイルフレームワーク ガイダンスのため。

[メール保護]

[メール保護] スクラムガイドの作成者によって開発された方法論です。 [メール保護] あまり規範的ではなく、製品のバックログを処理する方法を具体的に概説していません。ただし、次の2つの点に注意してください。

  • チームレベルのプロセスは、スクラムガイドに記載されているものと同じです。
  • 製品所有者は製品所有者チームを形成し、そこで単一の統合されたバックログを作成します。これは、作業の重複を回避し、社内の可視性を高めるために行われます。同時に、チームには、統合されたバックログからアイテムをフィードする個別のバックログがあります。

つまり、本質的には、 [メール保護] 新しいチームをそれぞれのPOとバックログでイメージします。チーム間の作業を調整するために、いくつかの追加の構造を追加するだけです。 [メール保護] 数、数十、または数百のチームで最適に機能しますが、2つのチームで作業している場合でも、いくつかの貴重な洞察を提供できます。

大規模スクラム(LeSS)

もっと少なく 製品バックログへの興味深いアプローチを促進します。 LeSSでは、製品の所有者は2〜8チームで作業します。 1つのPOがこれほど多くのチームと連携することは不可能に思えるかもしれません。 LeSSの哲学は、POが抽象的なレベルで機能し、製品バックログアイテムの改良責任をチームに委任することです。この場合、クロスファンクショナル開発チームは、製品の増分を提供できるようにするために、ビジネスドメインの知識も含める必要があります。 LeSSでは、バックログは1つだけです。

最新の状態に保つ方法

プロダクトマネージャーにとって、複数のチームは、進捗状況を追跡し、クエリに応答する作業が増えることを意味します。

チームを分割した後も最新の状態に保つ

会議に優先順位を付ける

単一のチームの毎日のスクラムに参加している場合、この習慣を続けることはおそらく非生産的です。毎日のスクラムを立ち寄ってチームの動向を把握し、話し合いができることをチームに思い出させるチャンスと考えてください。

スプリント計画セッションへの参加は、チームの成熟度によって異なります。チームに多くの新人が含まれている場合、またはチームがアジャイルと長い間協力していない場合は、あなたの側からのガイダンスが必要になります。出席せずにチームの計画を立てることに自信がある場合でも、質問が発生した場合は、計画中にチームに立ち寄ったり、チームとボイスチャットしたりできるようにしてください。

スプリントレビューは引き続き最優先事項であり、すべてのレビューに参加する必要があります。スプリントレビューは、現在の利害関係者やチーム自体から直接フィードバックを得るチャンスです。仮定が検証される時期であり、見逃してはなりません。

スクラムマスターとの関わりを深める

いくつかのスクラムセレモニーへの関与を減らしているかもしれませんが、スクラムマスターとのパートナーシップを倍増する必要があります。チームが分割された後、現在は複数ある可能性があります。その場合は、すべてのチームと緊密に連携する必要があります。

購入者の力は

チームの進捗状況やスプリント中に発生する問題を正直に把握できるように、彼らを信頼できることを確認してください。これらの関係により、すべてのスクラムセレモニーに参加しなくても最新の状態を保つことができます。

スクラムのスクラムを紹介する

メタスクラムと呼ばれることもあるスクラムのスクラムは、スクラムプロセスの規模に応じて通常導入される新しいセレモニーです。これは、より高いレベルでの毎日のスクラムのレプリカです。各チームはアンバサダーを指名し、その全員が毎日スクラムのスクラムに集まり、進捗状況と障害について話し合います。このセレモニーは、解決する必要のあるチーム間の技術的な問題を強調するためにも使用されます。

製品チームの拡大を検討してください

スクラムの設定で製品マネージャーがチームと積極的に関わる必要がある場合は、製品側に人を追加することを検討してください。これにアプローチする方法はいくつかあります。

ジュニアプロダクトマネージャー。 1つの方法は、日常の雑用の一部を処理するためにジュニアプロダクトマネージャーを追加しながら、自分自身のためにより戦略的な役割を担うことです。彼らは、品質保証(QA)、ユーザーストーリーの仕様書の作成、新機能の高レベルのモックアップの作成などのタスクを引き受けることができます。

ビジネスアナリスト。 もう1つの方法は、1人以上のビジネスアナリストをチーム内またはチームと一緒に作業させることです。プロダクトマネージャーは、ビジネスアナリストと協力して製品の前提条件を特定し、ビジネスアナリストに調査または新機能を通じてそれらを検証する方法を見つけさせることができます。

結論

チームが成長するにつれて、特に次の場合に、チームが大きくなりすぎている兆候に気付く可能性があります。

  • 毎日のスクラム。 毎日のスクラム中に15分の時間枠を超過していて、人々が興味を失い始めているのを確認した場合。
  • スプリント計画。 スプリント計画中にデッドロックが発生することがますます頻繁になっている場合。
  • ふりかえり。 ふりかえりの間に妥協点に到達することが難しくなっていることに気づき始めたら。

これらはすべて、チームを分割する必要があるかもしれないという事実を示しています。チームを分割することは一見簡単な作業のように見えますが、それはまた永続的な結果をもたらし、すべての製品マネージャーはそうするときに考慮すべきいくつかの事柄を持っています:

  • チームの士気。 理想的には、廃棄された良好な関係の数を最小限に抑えるために、チームに分割方法を決定させる必要があります。
  • クロスファンクショナルチーム。 チームは、製品の増分を作成するために必要なすべてのスキルを持っている必要があります。
  • 製品のバックログ。 チームに個別のバックログを作成するか、単一の統合バックログを作成するかを決定します。

2つ以上のチームを追跡するには、優先順位を付ける必要があります。効果的な製品マネージャーは、新しいチームをどのように最新の状態に保つかを計画する必要があります。

  • 会議に優先順位を付けます。 どのアジャイルセレモニーがあなたの時間の価値があり、どれが無視できるかを考えてください。
  • スクラムマスターと交流する。 チームプロキシとしてスクラムマスターを使用し、そこから情報を収集します。
  • 製品チームを拡大します。 あなたと一緒に働く人々を追加し、毎日の反復的なタスクを支援するか、ユーザー調査と市場分析を実施します。

これらの提案を利用することで、クリーンなチーム分割が可能になるはずです。チームが成長し続け、将来さらにチームを追加する場合は、次のことを読む必要があります。 スケーリングされたアジャイルフレームワーク 、アジャイルの構造とプロセスの提案を大規模に提供します。

基本を理解する

スクラムチームには何人の開発者がいますか?

スクラムガイドによると、開発チームは3〜9人で、製品の増分を提供するために必要なすべてのスキルを備えている必要があります。開発者の数は通常、製品のニーズによって決定され、通常、スクラムチームの2〜5人の開発者です。

スクラムチームのメンバーは誰ですか?

スクラムチームは部門の枠を超えており、製品の増分を提供するために必要なすべての人員が含まれています。ほとんどのスクラムチームには、専任の製品所有者とスクラムマスターがいます。チームの他のメンバーには、開発者、設計者、テスター、またはアナリストを含めることができます。

良いスクラムチームとは何ですか?

優れたスクラムチームは、製品の増分を作成するために必要なすべてのスキルを備えた部門の枠を超えています。開発者、設計者、テスター、アナリストなどを含める必要があります。

スクラムチームの推奨サイズはどれくらいですか?

スクラムガイドでは、1つのチームに3〜9人のチームメンバーを配置することを推奨しています。

サバイバルメトリクス:起動時のバーンレートを把握する

財務プロセス

サバイバルメトリクス:起動時のバーンレートを把握する
Adobe XD vs.スケッチ-どのUXツールがあなたに適していますか?

Adobe XD vs.スケッチ-どのUXツールがあなたに適していますか?

Uiデザイン

人気の投稿
ポストフラッシュ時代のWebアニメーション
ポストフラッシュ時代のWebアニメーション
Swiftプロパティのラッパーにアプローチする方法
Swiftプロパティのラッパーにアプローチする方法
42億ドルは合理的ですか?インスタカートの評価を評価する方法
42億ドルは合理的ですか?インスタカートの評価を評価する方法
スマートソフトウェアの価格戦略の究極のガイド
スマートソフトウェアの価格戦略の究極のガイド
ビジネスインテリジェンスの歴史を探る
ビジネスインテリジェンスの歴史を探る
 
ApeeScapeがフリーランサー向けの無料タイムトラッキングアプリTopTrackerをリリース
ApeeScapeがフリーランサー向けの無料タイムトラッキングアプリTopTrackerをリリース
シニアフルスタックエンジニア、タレントポストハイヤーチーム
シニアフルスタックエンジニア、タレントポストハイヤーチーム
いいねの予測:単純なレコメンデーションエンジンのアルゴリズムの内部
いいねの予測:単純なレコメンデーションエンジンのアルゴリズムの内部
ツリーカーネル:ツリー構造化データ間の類似性の定量化
ツリーカーネル:ツリー構造化データ間の類似性の定量化
Angular 4フォームの操作:ネストと入力の検証
Angular 4フォームの操作:ネストと入力の検証
人気の投稿
  • 多様性はデザインを________することができます。
  • 需要の価格弾力性は何を測定しますか?
  • モバイルアプリのプロトタイプテストは手動で行うことができますか、それとも何でしょうか?
  • 給与から請負業者のレートを計算する
  • さまざまな画面サイズのCSS
  • ダミーの暗号通貨とは何ですか
カテゴリー
ブランドデザイン モバイル Uiデザイン Kpiと分析 収益性と効率性 製品の担当者とチーム プロジェクト管理 収益と成長 トレンド 技術

© 2021 | 全著作権所有

apeescape2.com