複数のプロジェクトがある場合、スクラムはどのように機能しますか？[閉まっている]

私はスクラムの利点とプロセスをかなりよく読んでいます。バックログ、バーンダウンチャート、反復、ユーザーストーリーの使用、およびその他のスクラム「フレームワーク」のさまざまな概念についてのアイデアが得られます。

とはいえ、私は一度に複数のプロジェクトを管理するWeb開発会社で働いており、「制作チーム」を構成する6人のチームメンバーがいます。

スクラムは複数のプロジェクトを持つことでどのように機能しますか？それでも、特定の時間内に1つのプロジェクトの反復をスケジュールし、チーム全体がその作業を行い、その反復が完了したら、新しい反復を使用して次のプロジェクトに進みますか？または、同時に1つのチームのみで独自のイテレーションを使用して複数のプロジェクトを管理する「アジャイル」な方法はありますか？

スクラムは、1つの自己完結型製品で作業する必要があることを実際に指示しません。これは、実行する必要のある一連の処理（製品のバックログ）があり、次の反復で利用可能な開発時間（プロジェクトの速度から算出）があり、クライアントによって選択された項目があることを示しています。 / businessは、次のイテレーション（スプリントバックログ）で実行される問題/タスクのこのプールから最も優先度が高いものとして。

製品バックログとスプリントバックログが1つのプロジェクトからのものである必要がある理由はありません。単一のプロジェクトであっても、UI、ビジネスレイヤー、データベーススキーマなど、別個のプロジェクトのような個別の作業単位があります。特にエンタープライズソフトウェア開発は次のようなものであり、すべてを進める必要のある多数のコードベースがあります。スクラムプロセス-会議、質問、バーンダウンチャートなど-1つまたは複数のプロジェクトに関係なく、すべてが機能します。

とは言っても、実際には、反復ごとに「レポートモジュールを実行する」または「XYZシステムのAPIとのインターフェース」という主要なテーマを設定することが多くの場合、多くの問題が1つのプロジェクトまたは領域からイテレーションの終わりに、大量の作業をポイントし、それに対してティックを配置できます。

答えは、「バックログ項目を誰が優先するか」に依存すると思います（つまり、最初に何を行う必要があるかを決定します）。これが1人の場合、この人はプロジェクトのプロダクトオーナーであり、すべてのプロジェクトのすべてのアイテム-またはプロジェクトごとのバックログ-を1つ持つことができ、計画時にすべてのプロジェクトからバックログアイテムを選択します。スプリント。この場合、スクラムは正常に機能します。

すべてのプロジェクトに責任がある場合、各責任者が（多かれ少なかれ意識的に）プロジェクトを支持しようとする問題が発生する可能性があります。私見、仲裁によって優先順位を解決する権限を持つ1人のプロダクトオーナーが必要です。

そのような状況で従うべき1つのルールは、スプリント中にスプリントの内容を決して変更しないことです。必要に応じて、反復を2週間または3週間に短縮して、現在のスプリントに緊急のアイテムを追加しなければならないリスクを軽減できます。

私は反対しなければなりません。スプリント中にチームが単一のプロジェクトに集中することがプロセスの鍵となると思います。開発プロセス全体に貢献できない専門家（コンテンツ作成者、グラフィック担当者、ビジネスプロセスアナリストなど）がいる場合は、貢献できなくなったときにチームからシャッフルします。さらに良いことに、テストなどに貢献できるように、いくつかの異なるタスクについてトレーニングを受けさせます。

覚えておくべきもう1つのことは、プロジェクトを並行して実行するとスケジュールが失われることです。これを考慮してください。簡単にするために、同じチームを使用し、同じ日に開始する5つのプロジェクトがあるとします。各プロジェクトには3か月の労力が必要です。並行して実行する最良のシナリオでは、一度にすべてを完了し、15か月かかります。1か所のスプリントで1か月の労力の1/5しか収まらないため、速度はクリーム状になります。また、同時に5つのデモ会議を行います。したがって、最良のシナリオは、5か月のプロジェクトを15か月で納品し、競合他社は3で同じ作業を実行できると主張することになります。成熟度を見積もるチームは、利用可能な労働力の20％しか考慮できないため、影響を受けます。実際には、1つのスプリントで一部のタスクを実行できない場合があります。作業しているプロジェクトの数を5から変更する必要がある場合、チームはチームの効率を損なう見積もりの​​習慣を調整する必要があります。さらに、単純なタスクの再割り当てで作業を開始する前に新しい開発環境をスピンアップする必要がある場合、チームは自己組織化するのが難しいと感じるでしょう。

同じ5つのプロジェクトを連続して実行する場合、5番目のプロジェクトを同じ15か月で納品しますが、12か月のバックログがあり、使用できるというチームの需要が高いことをクライアントに伝えます。そのときは、プロジェクトの目標を調整します。または、一定のバックログがある場合は、別のチームの採用を開始するときが来たことがわかります。ただし、最良のプロジェクトは、アクティブ期間中に急速な改善が見られたクライアントと3か月で終了します。あなたは一年前にそのプロジェクトを終えることができ、あなたの履歴書にそれを置くことができます。あなたのスプリント速度はその期間にわたって安定し、あなたはそれが1つか2つのプロジェクトの後にそのストライドにヒットし、特定のスプリントでより多くを達成できることに気付くかもしれません。

プロジェクトを連続して実行することは、組織がスクラムフェースを採用しようとする最大のハードルの1つだと思います。これは、プロジェクトマネージャーの役​​割の解体に伴う大きな文化的変化ですが、スクラムプロセスへのメリットは非常に大きくなります。

すべての人が完全なチームメンバーである必要はないことに注意してください。彼らはあなたのクライアントを待合室に引き込み、開発プロセスの準備をすることができます。私はビジネスアナリスト、ネットワークアーキテクト、グラフィックデザイン担当者をドメインエキスパートとして維持し、必要に応じてチームにのみ所属させています。それらをスプリント0で実行してみましょう。ルックアンドフィールとワークフローの作業がいかに魅力的であるかに驚くでしょう。また、開発が本格的に始まると、実際に参加のレベルが上がる可能性があること、およびクライアントが利用できることが重要であることを理解して、クライアントを準備することも良いでしょう。スケジュールを知らせて、休暇や休日などを前もって十分に処理できるようにします。

私はこの正確な状況にありました。

プロジェクト全体で1人の製品所有者がいる場合、Phillipeは完全に正しいです。1つのチームで1つのスプリントがうまく機能するはずです。

複数の製品所有者がいる場合、理想的には、ビジネスサイドは、作業のスケジュール設定を担当する単一の「優先順位付け担当者」を選択する必要があります。これは間違いなく最良の解決策です。

（おそらくそうであるように）ビジネスが優先順位を付けたい方法を変更したくない場合（それは非常に便利です）、チームを分割して、2つの同時スプリントを実行できます。ただし、チームが6つある場合は、3つを超えるチームに分割することはしません（分割する必要はまったくありませんが、2〜3チームは実行可能だと思います）。ケニーが示唆するようにさらに分割し、1人のチームでチームを組むことは、私にはやや無意味に思えます。

チームを分割している場合、同じコードベースの大部分で別々のスプリントが機能しているのでない限り、スタンドアップを融合することにあまり価値はありませんが、それはそれらのチームを融合するための議論になるかもしれませんスプリント。

私が最近読んだもう1つの意見があります。つまり、アジャイル環境ではプロジェクトの概念は逆効果になる可能性があり、排除できるということです。この考え方によれば、組織は代わりにリリースに焦点を当てるべきです。これは、プロジェクトは、完成するまで価値を生み出さない人工的な作業の箱だからです。それらは、出荷可能な価値を頻繁に提供するというアジャイルの目標に反しています。A リリースは、それが価値の提供に向けて、その範囲を縮小またはチームは、次の前に提供できるものに基づいて拡張することができますので、配向されているので、アジャイルに沿ったよりあるリリース。

潜在的な中間点があり、以前は社内のプロジェクトと呼ばれていたものが現在、共通のアジャイルテーマまたは機能として再パッケージ化されています。このアプローチの利点は、製品所有者が適切と考えるように、テーマまたは機能を価値のある部分で実装できるようになったことです。

まだ1つのチームが複数の製品に取り組んでいるという問題があり、それはドメインの知識と考えられる技術的スキルに関する正当な懸念のための問題です。しかし、製品アジャイルで構築された、でも、複数の製品を単一のチームによって構築されたが、絶えず蓄積されているリリース -able値を。対照的に、プロジェクトは完了するまで何の価値もありません（多くのプロジェクトはそうではありません）。

考えること...

anopresは正しかったと思います。最善の方法は、スクラムを使用して同時に複数のプロジェクトを回避することです。並列処理が多すぎると効率が良くないことを理解するために、あらゆることを行ってください。

5人のチームの場合、約3か月ごとに5つのプロジェクトを想定します。

アプローチ1：各人がチームで1つのプロジェクトに取り組む

• プロジェクトあたり1/5の配信速度で、すべてのプロジェクトに15か月の配信を提供
• 一人一人が専門家ですが、自分のプロジェクトでのみ
• チーム精神がない

アプローチ2：プロジェクトごとに1つのスプリント、プロジェクトの切り替え

• プロジェクトの6回のスプリントごと
• プロジェクト作業の間隔が長すぎる-プロジェクトの通常の増分値ではない（製品バックログの場合は可）、忘れがちで、コンテキストを復元するために必要な作業、
• 約12〜13か月後に配信される最初のプロジェクト（2週間のスプリントを想定）

アプローチ3：シングルスプリントの5つのプロジェクト

• スプリントに収まるだけの詳細なタスク分割が必要
• プロジェクトごとの増分ビルドはほとんどありません
• 約12〜15か月後の最初のプロジェクトの納品

アプローチ4：推奨-シリアル化された作業

• チームはプロジェクトごとに1つのプロジェクトに取り組みます
• 最初のプロジェクトが開始され、3か月後に配信されました
• 2番目のプロジェクトは3か月後に開始され、6か月後に配信されました
• ...
• 5番目のプロジェクトは12か月後に開始され、15か月後に配信されました
• チームは、プロジェクト、集中的な調査、およびお客様とのコラボレーションに重点を置いています
• チーム全体がすべてのプロジェクトに関する一般的な知識を持っている
• コンテキストの切り替えに無駄な時間はありません
• 適切なチームの協力が必要です（競合により配信が遅くなる場合があります）。

ご覧のように、プロジェクトははるかに迅速に提供され、チームは連携して効率的であるため、ソリューション4は一般的に優れています。その他のアプローチには、コンテキスト切り替えからの無駄な時間、完全なチームコラボレーションの欠如、すべてのプロジェクトの非常に長い合計納期などがあります。

そして、バックロググルーミングはどうですか？チームが一度に単一のプロジェクトに取り組む場合、それは簡単です-誰もが参加します。複数のプロジェクトがある場合は、1人の担当者にグルーミングセッションを個別に委任する必要がある場合があります（チーム全体ではない）。

3か月後に2番目のプロジェクトを開始すると、他のすべてのプロジェクトをすぐに開始するよりも、6か月目以降に配信が速くなることをお客様に説明することが重要です。それはマネージャが見る幻想です-私たちは一度に5つのプロジェクトを開始し、私たちは一生懸命に取り組み、少しずつ提供します。しかし、結局これは効率的ではありません。

そのため、スクラムが複数のプロジェクトで並行して効率的であるとは信じられません。スクラムをフレームワークに適合させ、スクラムルールに従って作業するのは非常に困難です。時々、すべての人々を占有する2つのプロジェクトを用意することは良いことかもしれませんが、追加するプロジェクトが多いほど効率の悪いスクラムになります。たぶんかんばんは、進捗状況とチームワークを確認するための代替手段です（スクラムチームのようにそれほど強力ではありません）。

よろしく、アダム

@Chrisが言ったように、通常のプロジェクトには内部にサブプロジェクトがあります。ただし、バックログは1つしかありません。

すべてのプロジェクトのバックログを考えます。最初の問題：タスクまたはプロジェクトに優先順位を割り当てていますか？私はプロジェクトごとにバックログを好む。少なくとも製品の所有者が持っている優先事項を明確にすること。

異なる製品所有者がいること、およびそれらの製品所有者が各プロジェクトにどれだけの時間を費やすべきかについて合意することができないため。「誰か」は、プロジェクト間の優先順位をどのように管理するかに関する決定を放棄する必要があります。注：開発者はこれを行うべきではありません。

ここに私たちのプロジェクト「S」マネージャーが来て、製品所有者が必要とするリソースとチームのメンバーが与えることができる時間のバランスをとります。製品所有者Aは1か月の作業に対して支払いましたが、製品所有者Bは常に彼のプロジェクトを更新しています（そしてあなたにもよく支払います）。Aが1か月（開発者の時間）を過ごすためにチームのバランスをとる方法がいくつかあり、Bがポケットを満たすのを止めないでください。

内部ソフトウェアの場合（1社、1,000プロジェクト）。異なる製品の所有者は、与えられた時間について合意する必要があります。彼らは孤立して住んでいるわけではありませんが、あなたと同じボートにいます（プロジェクト "S"マネージャー）。彼らはあなたの人生をより簡単にいくつかのタスクを延期できるようにしますが、同時にあなたは彼らのニーズを決して忘れてはなりません。

まあ、私はまだこれを行うための最良の方法を理解しようとしています。しかし、これが私たちが現在進めていることです。お役に立てば幸いです。

チームメンバーはスクラムプロジェクト間で時間を分割できますが、チームメンバーを完全に専念させる方がはるかに生産的です。チームメンバーは1つのスプリントから次のスプリントに変更することもできますが、それによってチームの生産性も低下します。より大きなチームのプロジェクトは、複数のスクラムとして編成され、それぞれが製品開発のさまざまな側面に焦点を当て、彼らの努力を緊密に調整します。

プロジェクトごとに1つのスプリントを実行し、すべてのアクティブなSprings /プロジェクトを処理するために1日1回のスタンドアップミーティングを開催することをお勧めします。

貢献したいです。これは私がそれをする方法です：

• チームごとに1つの製品所有者と1つの製品バックログがあります。プロダクトオーナーは1人である必要はありませんが、このプロダクトオーナーの「エンティティ」がプロダクトバックログを担当します。
• 製品バックログには、すべてのプロジェクト（ここにあるすべてのプロジェクト）のユーザーストーリーがあります。各ユーザーストーリーには、努力/ストーリーポイント（チームの責任）とビジネス価値（製品所有者の責任）があります。
• すべてのスプリントに対応する「製品バックロググルーミング」があります。この会議の前に、製品の所有者はストーリーのビジネス価値を更新し（ビジネス上の理由で変更が必要な場合-気にしないでください）、新しいストーリーを含めます。この会議では、新しいストーリーが説明され、取り組みも更新されます。この会議の所要時間は約1時間です（初回を除く、約4時間）。
• 新しいスプリントを計画するときは、製品のバックログを開き、ストーリーをROIで注文し（これはビジネス価値/努力です）、時間がなくなるまでストーリーを計画します。

以上です。これはかなりうまくいくと言えます。私たちはこれを行うために、いくつかのgoogleスプレッドシート（​​製品バックログとスプリントバックログ（グラフとものの両方を含む））を使用し、オンライン組織に対して（特定のセマンティクスで）レッドマインを毎日使用します：時間、タスクの進行状況など

このアプローチの問題は、スプリントバックログスプレッドシートとレッドマインでタスクを複製していることです。しかし、これを完全にオンラインで行うためのオンラインツールは見つかりません。redmine（私にとって他のセマンティックな作業はありません）の製品バックログ、jiraのシングルボード、taigaのその他のストーリーなどがありません