SCRUMは、チームメンバーが共有されている環境をどのように管理しますか？

まあ、質問はそれ自身を言いました。私の職場ではそのようなケースが起こりますが、多くのアジャイルの本は同じ職場で働き、仕事のペースを速くするために現在のプロジェクトに集中することを促進しています。

たぶん、私はそのトピックについて知らされていないかもしれませんが、それほど厳密ではないかもしれませんが、そのような場合にアジャイルが提案することを知りたいと思ったのはそのためです。

誰か？

スクラム方法論では、それは単に推定に影響します。

各プロジェクトへの時間の割り当てに基づいて、その人にフォーカスファクターを割り当てます。

したがって、プロジェクトAとプロジェクトBを等しく作業している場合、プロジェクトAは次のようにリソースを計算します。

プロジェクトA —チームフォーカスファクター70％
サム-10日、100％割り当て（フォーカスファクター後7）
ジョー-10日、100％割り当て（フォーカスファクター後7）
Me-10日、50％割り当て（フォーカスファクター後3.5） ）
合計：25日* 70％フォーカスファクター= 17.5予測速度

また、プロジェクトの分割による効率の低下により、チーム全体ではなく、フルタイムのチームメンバーとパートタイムのチームメンバーのフォーカスファクターを個別に計算することもできます。この場合、プロジェクトの50％のフォーカスファクターを使用し、それに25％の50％の個人割り当て、つまり2 . 5日間の予測速度を掛けます。

これが実際にうまく機能するかどうかは、共有リソースが各プロジェクトに費やす時間と、スクラムが他の方法でどれだけうまく機能しているかを事前にどれだけよく知っているかの要因になります。

スクラムでの私の経験では、プロジェクトとチームが同じで献身的である場合にのみ、速度を予測できます。これらのいずれかが変更された場合、推定を行うために以前のスプリントからの速度計算を実際に使用することはできません。試してみることはできますが、通常よりもはるかに多く離れています。

一般的には、スプリント全体を通してチームを同じように、そしてLEASTに専念するようにします。

私の意見では、これはすべてのプロジェクトに非常に悪い影響を与えます。見積もりや計画だけではありません。はい、チームメンバーが3つのプロジェクトに割り当てられており、各プロジェクトに33％割り当てられている場合、必要なものはすべてわかっているので完了です。

コンテキストの切り替えは非常に高価です。また、複数の並列プロジェクトへの完全なコミットメントを維持することは不可能であるため、開発者が単一のプロジェクトのみに割り当てられている場合、開発者の時間の33％は33％からはるかに離れています。

これが完全に失敗する別の場所はコミュニケーションです。現在プロジェクトAで作業しているチームメンバーが、昨日プロジェクトAで作業しているが現在プロジェクトBで作業しているチームメンバーと何かを伝えなければならない場合はどうなりますか？最初の1つは情報を必要としますが、2つ目は完全に異なるプロジェクトに集中しており、プロジェクトAの質問は彼を混乱させるだけなので、それは両方の障害です。プロジェクトAのスクラムマスターは、開発者ができるだけ早く情報を取得することを望み、プロジェクトBのスクラムマスターは、チームメンバーがプロジェクトBに関係のないものに邪魔されることを望みません。これを回避するには、すべてを計画する必要があります。チームの開発者が同じプロジェクトを同じ日に作業する-これは計画プロセス全体にとって大きな問題であり、完全に回避する必要があるものです。

また、衝突しないようにすべての会議を計画する必要があります。また、会議は実際には無駄であり、そのため、プロセスを制御し続けるには、必要最小限の会議をできるだけ短くする必要があることも理解する必要があります。ただし、3つのプロジェクトに取り組んでいるチームメンバーがいる場合は、それらの3つのプロジェクトのすべての会議に参加する必要があります。

結論として、アジャイルは無駄を減らすことでもあり（リーンアプローチによるものです）、チームメンバーをチーム間で共有することは、無駄をもたらし生産性を下げるという点で最悪の失敗の1つです。単一のプロジェクトへの33％の割り当てで提供されるビジネス価値は、フルタイムの割り当ての10-16％で提供されるビジネス価値に等しいと思います。つまり、開発者はプロジェクトに1/3の時間だけでなく、その間に彼の生産性は1/3から1/2の間になります。

SCRUMは、共有メンバーのない献身的なチームを持つことに基づいているため、次のように質問することもできます。

true == falseにする必要があると言われた場合、xをどのように行うのか

スクラムでない場合は、スクラムと呼ばないでください！

重要な質問は、プロジェクトに対するチームメンバーのコミットメントです。チームメンバーがプロジェクトの成功に全力を尽くすことが理想です。これは、彼の時間がプロジェクトに完全に専念しているという意味ではありませんが、プロジェクトに取り組んでいるときに、プロジェクトに必要なあらゆるタスクを実行できることを意味します。

多くの場合、プロジェクトにパートタイムでしか従事しない担当者は、限られた範囲のコミットメントにのみ関与します。たとえば、データベースの最適化のみを行う人がいる場合があります。

その場合、多くの場合、その人をチームメンバーとしてではなく「リソース」として扱うのが最善です。チームは、特定のスプリントで必要なリソースの量を決定し、スプリントのために完了する特定のタスクセットを提供します。チームがそのリソースを担当する特定のチームメンバーを持っていることが最適な場合があり、毎日のスクラムでそのリソースのステータスの更新と障害の報告を行います。

スクラムの核となる側面の1つは、チームを一度に1つ（1つのプロジェクト、1つのストーリー、1つのタスク...）に集中させ続けることだと思います

1つのプロジェクトにリソースを割り当てることができない状況で、「アジャイルは何を提案しますか」と尋ねました...

• 複数のプロジェクトにまたがる大きなかんばんを用意してください。プロジェクトにはニーズがあるので、ボードに追加されます。人々がキャパシティを持っているので、重要なストーリーを引き出します。問題は、すべてのプロジェクトが一緒に管理されることであり、1つのプロジェクトの全体的な予測可能性が低下します。とはいえ、個々のストーリー/かんばんの要素は、集中した人またはチームによって引き出され、開発されます。（かんばんボードから引き出すために、4-5人の小さなチームを作成してみてください。
• コミットされたリソースのみを割り当てます。プロジェクト専用のリソースのプールを保持します。これらはチームとして保護され、中断はほぼゼロに保たれます。また、バックログがなく、プロジェクト/製品に焦点を当てていない「迅速な対応チーム」を維持します。中断が発生すると、迅速な対応チームが中断に対処します。中断がない場合は、ビルドシステムの改善、自動化テストフレームワークへの追加などに集中できます。また、発生するトリッキーな/厄介なバグのコードレビュー/デザインレビューおよびトラブルシューティングを支援できます。このチームが存在しないかのように開発を管理します。彼らができることは、配達を引き込むことだけです。このチームを通じて人々を「新鮮に保つ」ために回転させます（人々は迅速な対応チームにいることを好む/嫌うようです...）

お役に立てれば！