アジャイルSCRUMでは、「エキスパート」間のスプリントにおける作業の均等配分をどのように処理しますか？
私が働いているところでは、知識のサイロがたくさんあります。基本的に、開発チームの各メンバーは、ソフトウェア全体の特定の部分の専門家（場合によっては、物事を知っている唯一のメンバー）です。たとえば、一人の人がゲームのレンダリングエンジンのエキスパートである場合があります。もう1つは、GUIで作業する人です。 2つが混在することはほとんどありません。懸念事項は、GUIの人にネットワーキング関連の作業を任せることは意味がないということです。すでに効率化の面で、慣れ親しんでいるため、何かを効率的に行える人がすでにいる場合です。
この状況はSCRUMでのスプリント計画を難しくしているようです。チームの人々がタスクを何も持っていなかったり、特定のスプリントで真に十分に活用されていない可能性は十分にあります。これは、あるスプリント中に他のスプリント中に実際により多くの割り当てを取得する人に基づいて変化するため、速度の計算の信頼性が低くなります。
この問題をどのようにして克服しますか？焦点は、タスクと実行する必要があることに重点を置くべきであり、作業する特定の人々に重点を置くべきではないようです。上級管理職は、常にできるだけ早く作業を行うことを好むと思います。そして、GUI開発者がEngineに関連するタスクで21ストーリーポイントを推定し、Engine Guyが5ポイントを推定することがわかった場合、なぜ21を選択したのか質問します（目標は明らかに知識の共有ですが、これによりチームは全体的に非効率的に動作します）。
私が働いているところでは、知識のサイロがたくさんあります。
良くない。
懸念事項は、GUIの人にネットワーキング関連の作業を任せることは意味がないということです。すでに効率化の面で、慣れ親しんでいるため、何かを効率的に行える人がすでにいる場合です。
もちろん、それがこの種のシナリオまたは常に存在する「ボブがバスにぶつかったらどうなるか」につながることを除いて。問題。
この問題をどのようにして克服しますか？
まず、上層部はあなたの見積もりを見ることはできません。彼らは人レベルの割り当てを見ることができません。彼らはあなたが5対21を選んだことを決して知らないはずです。彼らはスプリントの終わりに、チームがクールなことをしたことを見るはずです。
それを超えて、5と21の推定値の代わりに5と...があるように、人々をクロストレーニングする必要があります。仕事のスペース。レンダラーエキスパートが次のスプリントで60時間を費やしていることがわかっている場合は、90時間のレンダラー作業を最優先事項としないでください。それは時々発生しますが、アジャイルが必要になったときに物事を行うことに集中している場合でも、人と人の自然な衰退と流れを管理することは一般的なニーズです。
あなたのチームがそのように専門化されている場合、ある程度、あなたができることは何もありません。そして、あなたがマネージャーの観点から質問しているなら、あなたも何もしませんすべきもします。これはチーム自身が解決する問題です。
覚えておくべきポイントは、スクラムは個人ではなくteamを最適化しようとすることです。個人がアイドル状態であることは（スクラムの観点から）まったく問題ありません。目標はチーム全体が生産的になることです。それが意味するのであれば、UI担当者はチームが生産的になるために時間の一部がアイドル状態であることを意味します。
チームが成熟するにつれて、チーム自体が、チームメンバーが何もすることがないように自分自身を最適化する方法を学習します。たとえば、チームメンバーはテストの作成方法を習得したり、ドキュメントを作成したり、技術的負債や内部サポートに取り組んだり、今後の要件について製品の所有者と話し合ったりすることができます。
コンサルタントとして、私のチームにも同様に専門分野のメンバーがいます。お客様のニーズと組織の利益率を最大限に満たすためには、できるだけ早く高品質を達成する必要があります。最適なパフォーマンスに特化したチームメンバーがいることは完全に有効です。
HOWEVER：これは、クロストレーニングが発生してはならないという意味ではありません。
私たちはフロントエンドの開発スペシャリストを持っていますが、彼らが忙しいとき、私たちのプロジェクトは止まることができません。 .NET開発者がスプリントに余計な時間をかけているように見える場合、彼らはアイドル状態ではありません。彼らはあまり馴染みのないものをつかみ、質問できる誰かとしてエキスパートを使います。スペシャリストはすでに他の作業に取り組んでいるため（そうでなければストーリーを取得することができません）、速度を「浪費」しているのではなく、その専門分野でチーム全体の能力と能力を高めています（質問の時間が想定されていない場合）生産性の向上を打ち消します）。これは、「アイドル」のチームメンバーを使用してチーム全体の速度を向上させ、チームの機能横断的な能力を向上させる優れた方法です。
もう1つのオプションは、アイドル状態の開発者を使用してプログラムをペアリングし、他の人のための単体テストを作成し、必要なドキュメントを作成し、実行する必要がある可能性のあるタスクについて製品の所有者を支援することです。チームが行う必要のある作業では、常に余分な手を使って作業を迅速化できることに注意してください。
特殊化のレベルによっては、ペアプログラミングのあるタイプの実装を検討する場合があります。誰かがスプリント中に十分に活用されていない場合は、ベロシティについて心配しないでください。そして、知らない専門分野で活用されている誰かとペアリングしてください。これの明らかな利点は、チームのメンバーが誰もが何でもできるの終わりに向かって、さまざまな分野でスキルを構築できることです。
サイロはいくつかの理由で悪いです。バス係数についてはすでに触れました。専門分野が狭い場合は、引き継ぎと統合の費用も支払います。
マネージャーとして「何もしない」という考え方は気に入っています。それは賢明なアドバイスですが、まだ注意が必要な点があります。
優先度。これは、質問がプロセス（計画、見積もりなど）に来るとき、ほとんど常に現場から脱出するようです。プロセスは、自分のためではなく、ビジネス価値を提供するのに役立ちます。自分自身、またはより良いチームに、バックログの最も重要なことがどのようになり得るか最も迅速に行われるですか？彼らはこれを理解します。アイドルサイクルを埋める作業を割り当てないでください。アイドル状態の人に、小さいが重要ではない何かに取り組んでもらう代わりに、重要な価値を提供する方法を改善することに時間を費やさせます。自動化/テンプレート化などの作業は常にあります。
チームの所有権。あなたが実際にチームを持っている場合（単に分散した一時的なコンサルタントを雇っただけではありません）、チーム内のチームの所有感を向上させることに取り組みます。チームのeveryoneが進行中の作業に興味を持っていると、すばらしいことです。彼が興味のない/理解していない他の人のアップデートを聞いている間、スタンドアップ中にあくびをしている場合、それは悪いことです。チームが垂直スライスに取り組むようにしてください。そうすることで、チームは一度に1つのエンドツーエンドのエクスペリエンスを構築できるようになります。時間、そしてそれはUIの男がバックエンドを助け、逆もまた同様です。すでに示唆したように、 [〜＃〜] xp [〜＃〜] は、チームの所有権を構築し、知識の共有を改善するのに最適です。
小さいストーリー。 21はA LOTです。あなたはより小さな垂直スライスを作ることができますか？それはあなたのチームが開発する必要があるスキルであり、最初に行うのは難しいです。私が提唱しているのは指で計画ポーカーをプレイする（1,2,3,5）推定値を求めている場合-これはストーリーが大きすぎて推定できないことを示す信号です。ストーリー作成スキルを習得すると、自然に NoEstimates の動きに傾くようになります。単純に物語を数えることがあなたの速度に最適です。しかし、欠点については this を読んでください;）