Answers:
在Scrum方法中，它仅影响估计。
您将根据他们对每个项目的时间分配为该人分配关注因子。
因此，如果我同时从事项目A和项目B，项目A会像这样计算资源：
项目A-团队关注度为70％，
Sam-10天，分配为100％（关注度后为7）
Joe-10天关注度，100％分配（关注因数之后为7）
Me-10天，关注度为50％（关注度后，为3.5） ）
总计：25天* 70％聚焦因子= 17.5预计速度
由于拆分项目的效率降低，您可能还需要分别为专职团队成员和兼职团队成员计算焦点因子，而不是为整个团队一次。在这种情况下，您将使用50％的项目关注因子，然后将其与50％的个人分配相乘，得出 25％（即2.5天的预计速度）。
这在实践中的效果如何，将成为您提前了解共享资源在每个项目上花费多少时间以及Scrum在其他方面为您工作的程度的一个因素。
根据我在Scrum中的经验，只有在项目和团队保持相同且专注的情况下，才能预测速度。如果这两种情况中的任何一种发生了变化，那么您就不能真正使用先前冲刺中的速度计算来进行估算。您可以尝试，但与通常情况相比，您所获得的收益将会更多。
总的来说，您绝对应该在整个Sprint中尽量保持团队的完整和尽职尽责，如果可以的话，则应更多。
我认为这将严重影响所有项目。这不仅仅是估计或计划的问题。是的，您可以说，如果将团队成员分配给三个项目，并且他们对每个项目的分配比例为33％，您就知道您需要的一切，并且您已经完成了，但这不是事实。
上下文切换非常昂贵。也不可能对多个并行项目保持完全承诺，因此，将开发人员分配给单个项目的33％的开发时间与33％的时间相去甚远。
完全失败的另一个地方是沟通。如果当前在项目A上工作的团队成员必须与昨天在项目A上但当前在项目B上工作的团队成员进行交流，会发生什么情况？这对他们俩都是一个障碍，因为第一个需要信息，而第二个则专注于完全不同的项目，而对项目A的任何疑问都只会打扰他。来自项目A的Scrum主管希望他的开发人员尽快获取信息，而来自项目B的Scrum主管不希望他的团队成员受到与项目B无关的任何事情的干扰。如果要避免这种情况，则必须计划所有团队中的开发人员可以在同一天内完成同一个项目，这对整个计划过程来说是一个很大的麻烦，应该完全避免。
您还必须计划所有会议不冲突。您还必须了解，会议实际上是浪费，因此，应尽量减少所需的最少会议次数，以保持对流程的控制。但是，如果您的团队成员在三个项目上工作，那么他必须参加这三个项目的所有会议=>是没有产生任何商业价值的会议的三倍。
结论得出结论，敏捷还涉及减少浪费（是的，这来自精益方法），而在团队之间共享团队成员是引入浪费和降低生产率方面最严重的失败之一。我想，为单个项目分配33％的交付的商业价值将等于全职分配的10-16％的交付的商业价值。这意味着开发人员不仅将参与项目的1/3时间，而且在此期间他的生产率将在1/3至1/2之间。
我相信Scrum的核心方面之一就是让团队一次专注于一件事（一个项目，一个故事，一项任务...）
在无法将资源分配给一个项目的情况下，您问“敏捷提议了什么”……您可以考虑尝试以下一种方法：
希望这可以帮助！