Project management 当您有多个项目时，Scrum是如何工作的？

我对Scrum的好处和过程相当了解。我得到了关于积压工作、消耗图表、迭代、使用用户故事以及Scrum“框架”的其他各种概念的想法

话虽如此。。。我在一家网络开发公司工作，该公司一次管理多个项目，由六名团队成员组成“生产团队”

---

Scrum如何处理多个项目？您是否仍然只是在一定时间内为单个项目安排一个迭代，整个团队都在进行该迭代，然后在该迭代完成后使用新的迭代继续下一个项目？或者，是否有一种“敏捷”的方式来管理多个项目，同时只与一个团队进行迭代？

Scrum实际上并不要求您必须使用一个独立的产品。它只是简单地说明需要做一大堆事情（产品积压工作），在下一次迭代中有一定的开发时间（根据项目速度计算）客户/业务部门从下一次迭代（sprint积压工作）中将要完成的问题/任务池中选择了具有最高优先级的项目

产品待办事项和sprint待办事项不必来自同一个项目——即使在单个项目中，也会有类似于独立项目的离散工作单元——UI、业务层、数据库模式等。企业软件开发尤其是这样，您有许多代码库，所有这些代码库都必须进行开发。Scrum过程——会议、问题、消耗图表等——无论是一个项目还是多个项目，都是有效的

---

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

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

如果每个项目都有自己的责任人，那么你很可能会遇到一些麻烦，每个责任人或多或少都会有意识地支持自己的项目。嗯，你只需要有一个产品负责人，有权通过仲裁解决优先事项

---

在这种情况下应遵循的一条规则是，在Sprint过程中，切勿更改Sprint内容。如有必要，您可以将迭代缩短为两到三周，以降低在当前Sprint中添加紧急项目的风险

我建议对每个项目进行一次冲刺，每天召开一次站立会议来处理所有活动的spring/项目。

我正处于这种情况

如果项目中有一个产品负责人，那么Phillipe是绝对正确的；与一个团队进行一次冲刺应该会很好

如果您有多个产品负责人，那么理想情况下，业务方需要选择一个负责安排工作的“优先者”这绝对是最好的解决方案。

如果（很可能是这样）业务部门不想改变他们想优先处理事情的方式（那太方便了），那么您可以拆分团队，并同时运行两个sprint。然而，对于一个6人的团队，我不会把它分成3个以上的团队（我根本不想把它分开，但我认为2-3个团队是可行的）。正如Kenny所建议的那样，进一步分裂，在我看来，拥有一个人组成的团队似乎有些毫无意义，因为这样你就不再有团队，只有单个程序员

---

如果您要拆分团队，我没有发现合并独立项目的价值，除非您有单独的sprint在同一个代码库中工作，但这可能是为了sprint而合并这些团队的一个理由。

正如@Chris所说，一个普通项目内部有子项目。不过，您只有一个待办事项

考虑所有项目的积压工作。第一个问题：您是否为任务或项目分配优先级？我确实更喜欢每个项目的积压工作。至少要明确产品负责人的优先级

有不同的产品负责人，而且由于这些产品负责人不会同意他们应该给每个项目多少时间。“有人”将不得不承担如何管理项目间优先事项的决策。注意：开发人员不应该这样做

我们的项目经理将平衡产品所有者需要的资源和团队成员可以给予的时间。产品负责人A支付了一个月的工作费用，但产品负责人B总是在更新他的项目（而且给你的报酬也很高）。这里有一些方法，你可以平衡你的团队，让A有一个月的时间（开发人员时间），而不会阻止B填满你的口袋

就内部软件而言（一家公司，一千个项目）。不同的产品负责人应就分配给他们的时间达成一致。他们不是孤立地生活，而是和你（项目经理）生活在同一条船上。他们会让你的生活更轻松，因为你可以推迟一些任务，但同时你永远不要忘记他们的需要

---

好吧，我还在想最好的办法。但这就是我们现在正在推动的。我希望这有帮助。

我不同意。我认为让一个团队专注于单个项目dur是整个过程的关键