複数のプロジェクトがある場合、スクラムはどのように機能しますか？
私はスクラムの利点とプロセスをかなりよく読んでいます。バックログ、バーンダウンチャート、イテレーション、ユーザーストーリーの使用、およびスクラムの「フレームワーク」の他のさまざまな概念に関するアイデアを得ることができます。
とは言うものの、私は複数のプロジェクトを同時に管理し、「プロダクションチーム」を構成する6人のチームメンバーを持つWeb開発会社で働いています。
複数のプロジェクトを持つスクラムはどのように機能しますか？一定の時間内に単一のプロジェクトの反復をスケジュールし、チーム全体が作業し、その反復が完了したら新しい反復で次のプロジェクトに移動しますか？または、同時に1つのチームだけで複数のプロジェクトを独自の反復で管理する「アジャイル」な方法がありますか？
スクラムは、1つの自己完結型製品に取り組む必要があることを実際に指示するものではありません。単に、実行する必要があるもの（製品バックログ）があり、次の反復で利用可能な一定の開発時間があり（プロジェクトの速度から計算された）、クライアントによって選択された項目があることを単に示しています。/businessは、次のイテレーション（スプリントバックログ）で行われるこの問題/タスクのプールから最も優先されるものとして。
製品バックログとスプリントバックログが1つのプロジェクトからのものである必要がある理由はありません-単一のプロジェクトであっても、UI、ビジネスレイヤー、データベーススキーマなど、個別のプロジェクトのような個別の作業単位があります。特にエンタープライズソフトウェアの開発は次のようになります。そこでは、すべてが進歩しなければならないコードベースがいくつかあります。スクラムプロセス（会議、質問、バーンダウンチャートなど）はすべて、1つのプロジェクトでも複数のプロジェクトでも機能します。
そうは言っても、実際には、各反復が「レポーティングモジュールを実行する」または「XYZシステムのAPIとのインターフェース」という主要なテーマを持っているとよい場合が多いので、多くの問題は1つのプロジェクトまたは領域から、反復の終わりに、あなたは大きな仕事の塊を指し、それに対して目盛りを付けることができます。
答えは「誰がバックログ項目を優先するか」（つまり、最初に何をする必要があるかを決める）に依存すると思います。これが1人の場合、この人はプロジェクトのプロダクトオーナーであり、すべてのプロジェクトのすべてのアイテム（またはプロジェクトごとのバックログ）を1つのバックログに持つことができ、計画時にすべてのプロジェクトからバックログアイテムを選択できますスプリント。この場合、スクラムはうまく機能します。
すべてのプロジェクトに責任がある場合、各責任者が（多少なりとも意識的に）そのプロジェクトを支持しようとするいくつかのトラブルに遭遇する可能性があります。私見、あなたは仲裁によって優先順位を解決する権限を持つ唯一のプロダクトオーナーが必要です。
このようなコンテキストで従うべき1つのルールは、スプリント中にスプリントの内容を変更しないでくださいです。必要に応じて、反復を2週間または3週間に短縮して、現在のスプリントに緊急のアイテムを追加する必要があるリスクを減らすことができます。
私は反対しなければなりません。スプリント中に単一のプロジェクトにチームを集中させることがプロセスの鍵だと思います。開発プロセス全体に貢献できない専門家（コンテンツ作成者、グラフィック担当者、ビジネスプロセスアナリストなど）がいる場合、彼らがもはや貢献できなくなったらチームからシャッフルします。または、さらに良いことに、テストなどに貢献できるように、いくつかの異なるタスクについてトレーニングを行います。
留意すべきもう1つのことは、プロジェクトを並行して実行するとスケジュールが中断されることです。これを考慮してください。簡単にするために、同じチームを使用して同じ日に開始する5つのプロジェクトがあるとします。各プロジェクトには3つの1か月の労力が必要です。並行して実行する最良の場合のシナリオでは、一度にすべてを完了し、15か月かかります。 1回のスプリントで1か月の努力の5分の1しか収まらないため、ベロシティはクリーム状になります。また、5つのデモ会議をすべて同時に行うことになります。したがって、ベストケースシナリオでは、5つのプロジェクトを15か月で提供し、競合他社は3で同じ作業を行うことができると主張します。実際には、1回のスプリントでいくつかのタスクを実行できないことがあります。作業中のプロジェクトの数を5から変更する必要がある場合、チームはチームの効率を損なう推定習慣を調整する必要があります。さらに、単純なタスクの再割り当てで作業を開始する前に新しい開発環境をスピンアップする必要がある場合、チームは自己組織化が困難になります。
同じ5つのプロジェクトを連続して実行する場合、同じ15か月で5番目のプロジェクトを提供しますが、12か月のバックログがあり、使用できるほどの需要があることをクライアントに教育します。そのとき、プロジェクトの目標を調整します。または、一定のバックログがある場合は、別のチームの採用を開始する時間であることを知っています。ただし、最適なプロジェクトは、アクティブな期間中に急速な改善が見られたクライアントと3か月で終了します。そのプロジェクトを1年前に完了し、履歴書に載せることができます。スプリントの速度はその期間にわたって安定し、プロジェクトまたは1、2の後、ストライドがそのストライドにヒットし、特定のスプリントでより多くを達成できることがあります。
プロジェクトを連続して実行することは、組織がスクラムフェースを採用しようとする最大のハードルの1つだと思います。これは、プロジェクトマネージャーの役割の解体に関連する大きな文化的変化ですが、スクラムプロセスのメリットは非常に大きいです。
全員が完全なチームメンバーである必要はないことに注意してください。彼らはあなたのクライアントを待合室に引き込み、開発プロセスの準備をすることができます。私はビジネスアナリスト、ネットワークアーキテクト、グラフィックデザインの人々をドメインエキスパートとして扱い、必要に応じてチームにアタッチするだけです。スプリント0で実行してみましょう。ルックアンドフィールとワークフローでの作業がどれほど魅力的であるかに驚くでしょう。また、開発が本格的に開始されると、参加レベルが実際に上がる可能性があり、彼らが利用できることが重要であることを理解してクライアントを準備することも良いことです。休暇や休暇などを十分に前もって処理する十分な時間があるように、彼らにスケジュールを知らせてください。
私はこの正確な状況にありました。
プロジェクト全体に1人の製品所有者がいる場合、Phillipeは間違いなく正しいです。 1つのチームで1つのスプリントを使用しても問題はありません。
複数の製品所有者がいる場合、理想的には、ビジネス側は作業のスケジューリングを担当する単一の「優先順位付け者」を選択する必要があります。 これは間違いなく最良のソリューションです。
（おそらくそうであるように）ビジネスが物事の優先順位付けの方法を変更したくない場合（それはあまりにも便利です）、チームを分割して、2つの同時スプリントを実行できます。しかし、6人のチームでは、3つ以上のチームに分割しません（まったく分割したくありませんが、2〜3チームが実行可能だと思います）。ケニーが示唆するように、さらに分割し、一人のチームを持つことは、チームを持たず、個々のプログラマーだけであるので、私にはいくらか無意味に思えます。
あなたがチームを分割している場合、同じコードベースの非常に多くに取り組んでいる別々のスプリントを持たない限り、スタンドアップを統合することにはあまり価値がありませんが、それはそれらのチームをスプリント。
私が最近読んでいる別の意見があります。つまり、アジャイル環境ではProjectの概念は逆効果になる可能性があり、排除できるという意見です。この考え方に従って、組織は代わりにReleasesに注目する必要があります。これは、Projectsが完了するまで値を生成しない人工的な作業箱だからです。これらは、出荷可能な価値を頻繁に提供するというアジャイルの目標に反しています。 Releaseは、価値を提供することを志向しており、その前にチームが提供できるものに基づいて範囲を縮小または拡大できるため、アジャイルとより一致していますnextRelease。
潜在的な妥協点があります。以前はProjectと呼ばれていたものが、一般的なアジャイルテーマ =または機能。このアプローチの利点は、ThemeまたはFeatureが製品の所有者が適切と判断した場合、価値のある部分で実装されます。
1つのチームが複数のProductsに取り組んでいるという疑問がまだあります。それは、ドメインの知識と可能な技術的スキルに関する正当な懸念のための質問です。ただし、Productsはアジャイルで構築され、複数のProductsは単一のチームによって構築されます、常に蓄積されているRelease-able値。対照的に、Projectsは終了するまで何の価値もありません（多くの人はそうしません）。
考えるべきこと...
Anopresは正しかったと思います。最良の方法は、スクラムで同時に複数のプロジェクトを避けることです。並行して実行しすぎると効率的ではないことを認識できるように、すべてを行ってください。
5人のチームの場合、それぞれ約3か月で5つのプロジェクトを想定します。
アプローチ1：各人がチーム内の単一のプロジェクトに取り組んでいます
- プロジェクトごとに1/5の配信速度により、すべてのプロジェクトで15か月の配信が可能
- 一人一人が専門家ですが、自分のプロジェクトでのみ
- チーム精神がない
アプローチ2：プロジェクトごとに1つのスプリント、プロジェクトを切り替える
- 6回ごとにスプリントがプロジェクトに取り組む
- プロジェクト作業の間隔が長すぎる-プロジェクトの定期的な増分値ではなく（製品バックログの場合）、忘れやすい、コンテキストを復元するのに必要な労力、
- 約12〜13か月後に最初に提供されたプロジェクト（2週間のスプリントを想定）
アプローチ3：シングルスプリントの5つのプロジェクト
- スプリントに収まるだけの詳細なタスク分割が必要
- プロジェクトごとの増分ビルドはほとんどありません
- 約12〜15か月後の最初のプロジェクトの配信
アプローチ4：推奨-直列化された作業
- チームはプロジェクトの後に単一のプロジェクトで作業する
- 最初のプロジェクトが開始され、3か月後に配信されました
- 2番目のプロジェクトは3か月後に開始され、6か月後に配信されます
- ...
- 5番目のプロジェクトは12か月後に開始され、15か月後に配信されました
- プロジェクト、集中的な調査、顧客とのコラボレーションに重点を置いたチーム
- チーム全体がすべてのプロジェクトに関する一般的な知識を持っています
- コンテキスト切り替えに無駄な時間はありません
- 優れたチームの協力が必要です（競合により配信が遅くなる可能性があります）。
ご覧のように、ソリューション4は一般的に優れています。プロジェクトがより迅速に提供され、チームが連携して効率的に作業できるためです。他のアプローチには、コンテキスト切り替えからの無駄な時間、完全なチームコラボレーションなし、すべてのプロジェクトの非常に長い合計配信時間などが含まれます。
バックログのグルーミングはどうですか？チームが一度に単一のプロジェクトに取り組む場合、それは簡単です-誰もが参加します。複数のプロジェクトがある場合は、個別のグルーミングセッションに単一の人を委任する必要があります（完全なチームは関与していません）。
3か月後に2番目のプロジェクトを開始すると、他のすべてのプロジェクトですぐに開始するのではなく、（6か月後に）納期が短縮されることをお客様にご理解いただくことが重要です。マネージャーには幻想です。一度に5つのプロジェクトを開始し、一生懸命働き、少しずつ成果を上げていきます。ただし、これは効率的ではありません。
だからこそ、スクラムは複数のプロジェクトに対して並行して効率的であるとは信じていません。フレームワークに合わせてスクラムルールに従って作業するのは非常に難しいです。すべての人を占有するために2つのプロジェクトを用意するのが良い場合もありますが、追加するプロジェクトの数が多いほど効率の悪いスクラムになります。たぶん、かんばんは進捗状況とチームワークを確認するための代替手段にすぎないかもしれません（スクラムチームのように強くありません）？
よろしく、アダム
@Chrisが言ったように、通常のプロジェクトにはサブプロジェクトが含まれています。ただし、バックログは1つしかありません。
すべてのプロジェクトのバックログで考えてください。最初の問題：タスクまたはプロジェクトに優先順位を割り当てていますか？私はプロジェクトごとのバックログを好みます。少なくとも、製品所有者が持っている優先事項を明確にすること。
異なる製品所有者がいること、およびそれらの製品所有者が各プロジェクトにどれだけの時間を与えるべきかについて同意しないという事実のため。 「誰か」は、プロジェクト間の優先順位を管理する方法に関する決定を放棄する必要があります。注：開発者は実行しないでください。
ここでは、製品の所有者が必要とするリソースとチームのメンバーが提供できる時間のバランスを取るプロジェクト「S」マネージャーが登場します。プロダクトオーナーAは1か月分の作業を支払いましたが、プロダクトオーナーBは常に自分のプロジェクトを更新しています（そしてあなたにも支払います）。 Aが1か月（開発者の時間）を確保し、Bがポケットを満たすのを止めないために、チームのバランスをとる方法があります。
内部ソフトウェアの場合（1社、1000プロジェクト）。異なる製品所有者は、与えられた時間に同意する必要があります。彼らは孤立して住んでいるのではなく、あなたと同じ船に乗っています（プロジェクト「S」マネージャー）。彼らはあなたの人生をいくつかのタスクを延期できるようにしますが、同時に彼らのニーズを決して忘れてはいけません。
まあ、私はまだこれを行うための最良の方法を見つけようとしています。しかし、これが私たちが今推進していることです。役に立てば幸いです。
チームメンバーはスクラムプロジェクト間で時間を分けることができますが、チームメンバーを完全に専念させる方がはるかに生産的です。チームメンバーはスプリントごとに変更できますが、チームの生産性も低下します。大規模なチームを持つプロジェクトは複数のスクラムとして編成され、各スクラムは製品開発のさまざまな側面に焦点を当て、それぞれの取り組みを綿密に調整しています。
プロジェクトごとに1つのスプリントを実行し、アクティブなすべてのスプリング/プロジェクトを処理するために毎日1回のスタンドアップミーティングを開催することをお勧めします。
貢献したいと思います。これは私がそれを行う方法です：
- チームごとに1人の製品所有者と1つの製品バックログがあります。製品所有者は一人である必要はありませんが、この製品所有者の「エンティティ」が製品のバックログを担当しています。
- 製品バックログには、すべてのプロジェクト（ここにあるすべてのプロジェクト）のユーザーストーリーが含まれています。各ユーザーストーリーには、努力/ストーリーポイント（チームの責任）とビジネス価値（製品所有者の責任）があります。
- すべてのスプリントに対応する「製品バックロググルーミング」があります。この会議の前に、製品の所有者はストーリーのビジネス価値を更新し（ビジネス上の理由で何らかの変更が必要な場合-気にしない、気にしない）-新しいストーリーを含めます。この会議では、新しいストーリーが説明され、取り組みも更新されます。この会議は約1時間続きます（初回を除き、約4時間）。
- 新しいスプリントを計画するときは、製品バックログを開き、ROI（これはビジネス価値/努力）でストーリーを順序付けし、時間が経つまでストーリーを計画します。
以上です。これはかなりうまくいくと言えます。これを行うために、Googleスプレッドシート（製品バックログとスプリントバックログ、グラフなど）を使用し、毎日オンライン組織で（特定のセマンティックを使用して）時間、タスクの進行状況などを整理します。
このアプローチの問題は、スプリントバックログスプレッドシートのタスクを複製して再作成することです。しかし、これを完全にオンラインで行うためのオンラインツールは見つかりません。 redmineの製品バックログ（他のセマンティックワークはありません）、jiraの単一ボード、taigaのその他のストーリーなどがありません