SCRUMは、チームメンバーが共有される環境をどのように管理しますか？
さて、質問はそれ自体を言いました。私の職場ではこれらのケースが発生しますが、アジャイルの本の多くは同じ職場での作業を促進し、現在のプロジェクトに集中して作業のペースを速めます。
たぶん私はそのトピックについては知らされていないかもしれませんし、それほど厳密ではないかもしれませんが、それが私がそのような場合にアジャイルが提案するものを知りたかった理由です。
誰か？
スクラム方法論では、推定に影響するだけです。
各プロジェクトへの時間の割り当てに基づいて、その人にフォーカスファクターを割り当てます。
したがって、私がプロジェクトAとプロジェクトBに等しく取り組んでいる場合、プロジェクトAは次のようにリソースを計算します。
プロジェクトA —チームフォーカス係数70％
Sam-10日、100％割り当て（フォーカスファクター後7）
ジョー-10日間、100％割り当て（フォーカスファクター後7）
私-10日、50％の割り当て（フォーカスファクター後3.5）
合計：25日* 70％フォーカス係数= 17.5予測速度
また、プロジェクトの分割による効率が低下するため、チーム全体ではなく、フルタイムのチームメンバーとパートタイムのチームメンバーに対して別々にフォーカスファクターを計算することもできます。この場合、私のプロジェクトフォーカス係数の50％を使用し、それに個人割り当て 50％の25％、つまり2.5日間を掛けます予測速度。
これが実際にどの程度うまく機能するかは、共有リソースが各プロジェクトに費やす時間と、スクラムが他の方法でどれだけうまく機能しているかを事前に把握するための要素になります。
スクラムでの私の経験では、プロジェクトとチームが同じで献身的である場合にのみ速度を予測できます。これらのいずれかが変化する場合、以前のスプリントからの速度計算を実際に使用して推定を行うことはできません。試すことはできますが、通常よりもはるかに時間がかかります。
一般に、できる限り、チームを同じにして、スプリント全体で少なくとも献身的にすることをお勧めします。
私の意見では、これはすべてのプロジェクトに非常に悪影響を及ぼすでしょう。見積もりや計画だけではありません。はい、チームメンバーが3つのプロジェクトに割り当てられており、各プロジェクトに33％の割り当てがある場合、必要なすべてを知っていて完了していると言えますが、そうではありません。
コンテキストの切り替えは非常に高価です。また、複数の並行プロジェクトへの完全な取り組みを維持することは不可能であるため、開発者が単一のプロジェクトのみに割り当てられている場合、開発者の時間の33％パーセントは33％から遠く離れています。
これが完全に失敗する別の場所はコミュニケーションです。現在プロジェクトAで作業しているチームメンバーが、昨日プロジェクトAで作業しているが現在プロジェクトBで作業しているチームメンバーと何かをやり取りする必要がある場合はどうなりますか？最初のものは情報を必要としますが、2つ目は完全に異なるプロジェクトに集中しており、プロジェクトAへの質問は彼を邪魔するだけなので、それは両方の障害です。プロジェクトAのスクラムマスターは、開発者ができるだけ早く情報を取得することを望み、プロジェクトBのスクラムマスターは、チームメンバーがプロジェクトBに関連しないものに邪魔されることを望まない。これを避けたい場合は、すべてを計画する必要があるチームの開発者が同じプロジェクトを同じ日で作業する-これは、計画プロセス全体に大きな複雑性があり、完全に回避する必要があります。
また、衝突しないようにすべての会議を計画する必要があります。また、会議は実際には無駄であり、そのため、プロセスの制御を維持するためには、必要最小限の会議をできるだけ短くする必要があることも理解する必要があります。しかし、3つのプロジェクトで作業しているチームメンバーがいる場合、その3つのプロジェクトのすべての会議に参加する必要があります。>>開発者がビジネス価値を生み出さない3倍以上の会議。
結論アジャイルは無駄を減らすことでもあり（リーンアプローチによるものです）、チーム間でチームメンバーを共有することは、無駄の導入と生産性の低下という点で最悪の失敗の1つです。単一のプロジェクトへの33％の割り当てで提供されるビジネス価値は、フルタイムの割り当ての10-16％で提供されるビジネス価値に等しいと思います。つまり、開発者はプロジェクトの1/3の時間に参加するだけでなく、その時間の生産性は1/3から1/2の間になります。
SCRUMは、共有メンバーのいないコミットされたチームを持つことに基づいているため、次のように質問することもできます。
True == falseにする必要があると言われたので、xをどのように実行しますか
スクラムでない場合は、スクラムと呼ばないでください。
重要な質問は、チームメンバーのプロジェクトへの取り組みについてです。理想的には、チームメンバーはプロジェクトの成功に全面的に取り組む必要があります。これは、彼の時間がプロジェクトに専念しているという意味ではありませんが、プロジェクトに取り組んでいるときに、プロジェクトに必要なタスクを実行できることを意味します。
多くの場合、プロジェクトのパートタイムのみの担当者は、限られた範囲のコミットメントにのみ関与します。たとえば、データベースの最適化のみを行う人物がいるとします。
その場合、多くの場合、その人をチームメンバーではなく「リソース」として扱うのが最善です。チームは、特定のSprintで必要なリソースの量を決定し、Sprintに対して実行する非常に具体的な一連のタスクを提供します。チームにそのリソースを担当する特定のチームメンバーがいて、毎日のスクラムでそのリソースのステータスの更新と障害の報告を行うことが最善の場合もあります。
スクラムの核となる側面の1つは、チームが一度に1つのことに集中できるようにすることだと思います（1つのプロジェクト、1つのストーリー、1つのタスク...）。
リソースを1つのプロジェクトに割り当てることができない状況で「アジャイルは何を提案するか」と質問しました...次のいずれかを試すことを検討してください。
- 複数のプロジェクトにまたがる大きなかんばんボードを保持します。プロジェクトにはニーズがあるため、ボードに追加されます。人々には能力があるため、キーストーリーを引き出します。問題は、すべてのプロジェクトがまとめて管理され、1つのプロジェクトの全体的な予測可能性が低下することです。とはいえ、個々のストーリー/かんばんの要素は、焦点を絞った人物またはチームによって引き出され、開発されます。 （かんばんボードから引き出すために、より小さな4〜5人のチームを作成してみてください。
- コミットされたリソースのみを割り当てます。プロジェクト専用のリソースのプールを保持します。これらはチームとして保護され、中断はほぼゼロに保たれます。また、バックログがなく、プロジェクト/製品に重点を置いていない「迅速な対応チーム」を維持します。中断が発生すると、迅速な対応チームが中断に対処します。中断がない場合、ビルドシステムの改善、自動化テストフレームワークへの追加などに集中できます。また、コードレビュー/デザインレビュー、および発生するトリッキー/厄介なバグのトラブルシューティングにも役立ちます。このチームが存在しないかのように開発を管理します。彼らができることは、配達を引き込むことだけです。このチームを通じて人々をローテーションして、「新鮮さを保つ」（人々は迅速な対応チームにいるのが好き/嫌いなようです...）
お役に立てれば！