问当你有多个项目时，Scrum是如何工作的？

EN

Scrum实际上并没有规定你必须在一个独立的产品上工作。它简单地说明了有一堆事情需要完成(产品积压)，在下一次迭代中有一定数量的开发时间可用(从项目速度中计算出来)，并且有客户/业务从这个问题/任务池中选择的具有最高优先级的项，这些问题/任务将在下一次迭代中完成(冲刺积压)。

没有理由产品积压和冲刺积压必须来自一个项目-即使在一个项目中，也会有像单独项目一样的离散工作单元- UI、业务层、数据库模式等。企业软件开发特别像这样，其中您有许多代码库，所有这些代码库都必须进行。Scrum流程--会议、问题、烧毁图表等等--无论是一个项目还是多个项目，都是有效的。

话虽如此，在实践中，每次迭代都有一个主要的主题-“做报告模块”或“与XYZ系统的API接口”-这样很多问题都来自一个项目或领域，在迭代结束时，你可以指向大量的工作，并在其上打勾。

我认为答案取决于“谁将优先处理待办事项”(即决定首先需要做什么)。如果这是一个人，那么这个人就是您的项目的产品负责人，您可以拥有一个单一的backlog将所有项目的所有项-或每个项目的backlog -并且您在计划Sprint时从所有项目中选择backlog项。在这种情况下，Scrum“工作”得很好。

如果每个项目都有它的负责人，那么你可能会遇到一些麻烦，每个负责人或多或少都会有意识地试图偏爱自己的项目。我的意思是，你只需要一个产品负责人有权通过仲裁解决优先权。

在这种情况下应该遵循的一条规则是，在冲刺期间，永远不要更改冲刺内容。如果有必要，您可以将迭代缩短到两到三周，以降低必须在当前Sprint中添加紧急项目的风险。

我不同意你的观点。我认为在冲刺过程中，让团队专注于单个项目是关键。如果您有一些不能对整个开发过程做出贡献的专家(内容作者、图形人员、业务流程分析师等)当他们不能再做出贡献时，我会把他们从团队中抽离出来。或者更好的是，让他们在一些不同的任务上接受培训，这样他们就可以为测试之类的事情做出贡献。

另一件要记住的事情是，并行运行项目会扼杀你的日程安排。考虑到这一点:为了简单起见，假设我们有5个项目使用相同的团队，并且在相同的日期开始。每个项目需要3个月的努力，在最好的情况下并行运行，您将立即完成它们，这将需要15个月。你的速度会变得很慢，因为你在一次冲刺中只能完成一个月工作的1/5。您还将同时进行5个演示会议。所以最好的情况是，你在15个月内交付了5个项目，而你的竞争对手会声称他们可以在3个月内完成同样的工作。你的团队估计成熟度将受到影响，因为他们只能考虑20%的可用劳动力。你可能会发现你实际上不能在一次冲刺中完成一些任务。如果你必须改变5个项目的数量，你的团队将不得不调整他们的评估习惯，这将损害团队的效率。此外，当一个简单的任务重新分配可能需要一个新的开发环境才能开始工作时，您的团队会发现很难自组织。

如果你要连续运行同样的5个项目，你将在同样的15个月内交付第5个项目，但你会告诉你的客户，你的团队的需求是如此之大，你有12个月的积压，你可以利用这段时间来完善你的项目目标。或者，如果你有一个持续的积压，你知道是时候开始雇佣另一个团队了。然而，你最好的项目是在3个月内完成的，客户在活跃期间看到了快速的改进。你可以提前一年完成这个项目，并把它写在你的简历上。你的冲刺速度将在这段时间内稳定下来，你可能会发现在一两个项目之后就达到了它的步幅，并且能够在给定的冲刺中完成更多的事情。

我认为连续运行项目是组织尝试采用scrum faces的最大障碍之一。这是与解构项目经理角色相关的重大文化变化，但scrum过程的好处是巨大的。

请记住，每个人都不需要成为正式的团队成员。他们可以让你的客户在等候室中参与进来，为开发过程做准备。我让我的业务分析师、网络架构师和图形设计人员作为领域专家，只在需要时才将他们加入团队。让他们使用sprint 0运行。你会惊讶于在外观和工作流程上的工作是多么的吸引人。让你的客户做好准备也是很好的，因为当开发真正开始时，他们的参与程度实际上可能会上升，这对他们来说是很重要的。让他们知道日程安排，这样他们就有足够的时间提前处理假期和假期之类的事情。