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