スクラム方法論チームの管理は、そのシンプルさと「そのまま」適用できるため、広く使用されています。 複数のチームが1つのプロジェクトのフレームワーク内で作業する場合、状況はより複雑になります。 この場合、階層型スクラムオンスクラムモデルが使用されます。 ただし、複数の開発チームと1つのテスターチームが存在する場合の対処方法は次のとおりです。
10人以上のプロジェクトを管理したプロジェクトマネージャーは、この問題に遭遇したと思います。
•複数のチームが1つのプロジェクトに取り組みます。 プロジェクトが大規模であり、クリーンスクラムは9人以上のチームでは機能しないという事実により、チームをいくつかのタイミングに分割する必要が生じます。
•テスターのグループは9人未満で、1つのグループにまとめることができます。
最も単純な解決策は、テスターをチームごとに分けて、プログラマーの各チームに1〜2人のテスターを与えることです。 ただし、テスターを1つのグループとして使用することが有益な場合の対処方法は次のとおりです。 これは、テスターの経験と能力が異質な場合に役立ちます。 原則として、これは常に存在します。
管理を必要としない最も簡単なソリューションはキュー方式です。以前にタスクを投稿した人は誰でも、一般プールからタスクを（優先順位を考慮して）抽出することでチェックを開始します。
しかし、ここに問題があります-ティムは部門の下で対立し始めます-「なぜ彼らは私たちをテストしていないのですか？」 テスターは、リソースの不足について不平を言い始め、テスターの数を増やすよう求めます。
実際、このタスクは一般的な性質を持っています。重要なリソースとこのリソースへの複数のアクセス権を持つチームを管理することが必要になるとすぐに、またはプロセスフローが純粋に線形ではない場合、2つ以上のブロックからタスクを受け入れるブロックがあります。
ここで、3人のチーム開発者と1人のチームテスターによる、プロジェクトに適用されたソリューションについて説明します。 ティムスは3日間のシフトでスプリントを開始します。 クラシックスプリントサイズ-2週間。 テスターは、スプリントの開始から4日目と、スプリントの最後の2日に、各個人のティムのタスクを取ります。 その結果、私たちはそのようなスケジュールを取得します。
1週間以内に、ティムのテスターには1つの予約日があります。 過去2日間、チームのティムは次のスプリントを計画し、バックログからバグを修正します。もちろん、現在のスプリントで見つかったバグを忘れません。 このような組織は、テスターからのストレスを軽減し、開発者の責任を高めるのに役立ちました。 複雑なタスクは最初のスプリントで行われ、スプリントの4日目に確認されます。 開発者は、スプリントの最後にテスト済みのソリューションを使用することをお勧めします。そうしないと、最終日に見つかったバグをタスクを閉じずに次のスプリントに転送する必要があります。