当您有多个项目时，Scrum 如何工作？[关闭]

Question

我对 Scrum 的好处和流程有相当多的了解。我得到了积压工作、燃尽图、迭代、使用用户故事以及 Scrum“框架”的其他各种概念的想法。

照这样说...我在一家网络开发公司工作，该公司同时管理多个项目，由六名团队成员组成“生产团队”。

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

Answer 1

Scrum确实没有要求你必须在一个独立的产品上工作。它只是声明需要完成一些事情（产品积压），在下一次迭代中有一定的开发时间（从项目速度计算出来）并且客户选择了一些项目/ business作为将在下一次迭代（sprint backlog）中完成的问题/任务池中具有最高优先级。

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

话虽如此，实际上每次迭代通常都有一个主题 - “做报告模块”。或“与XYZ系统的API接口” - 因此很多问题来自一个项目或区域，并且在迭代结束时，您可以指向大量工作并对其进行勾选。

Answer 2

我认为答案取决于“谁将优先考虑积压物品” （即决定首先需要做什么）。如果这是一个人，则此人是您项目的产品负责人，并且您可以将所有项目的所有项目（或每个项目的待办事项）都有一个待办事项，并在计划时从所有项目中选择待办事项一个冲刺。在这种情况下，Scrum“工作”。精细。

如果每个项目都有责任，那么你可能会遇到一些麻烦，每个负责人都会 - 或多或少地有意识地 - 试图支持它的项目。恕我直言，您只需拥有一名产品负责人，并有权通过仲裁解决优先事项。

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

Answer 3

我不同意。我认为在sprint期间让团队专注于单个项目是关键。如果您有一些无法为整个开发过程做出贡献的专家（内容作者，图形人员，业务流程分析师等），那么当他们无法再做出贡献时，我会将他们从团队中移除。或者更好的是，让他们接受一些不同的任务培训，这样他们就可以为测试做出贡献。

要记住的另一件事是并行运行项目会导致计划失败。考虑一下：为了简单起见，我们假设我们有5个项目使用相同的团队，并在同一天开始。每个项目需要3个月的努力，在并行运行的最佳情况下，您将同时完成所有这些并且需要15个月。你的速度会因为你只能在单个冲刺中适应1/5个月的力量而得到提升。您还将同时进行5次演示会议。最好的情况是，您在15个月内交付5个项目，您的竞争对手将声称他们可以在3中完成相同的工作。您的团队估计成熟度将受到影响，因为他们只能考虑20％的可用劳动力。您可能会发现实际上无法在单个sprint中执行某些任务。如果你必须从5改变工作项目的数量，你的团队将不得不调整他们的估计习惯，这将损害团队的效率。此外，如果简单的任务重新分配可能需要在工作开始之前启动新的开发环境，您的团队将发现很难进行自我组织。

如果您要连续运行相同的5个项目，那么您将在同样的15个月内交付第5个项目，但是您可以让您的客户知道您的团队需要您有12个月的积压工作您可以利用这段时间来优化项目目标。或者如果你有一个持续的积压，你知道是时候开始雇用另一个团队了。然而，您最好的项目在3个月内完成，客户在活动期间已经看到了快速的改进。您可以在一年前完成该项目，并将其放在简历上。你的冲刺速度会在这段时间内稳定下来，你可能会发现在一两个项目之后它会大步前进并且能够在给定的冲刺中完成更多。

我认为连续运行项目是组织试图采用Scrum面临的最大障碍之一。这是与解构项目经理角色相关的重大文化变革，但对Scrum流程的好处是巨大的。

请记住，EVERYBODY不需要是一个完整的团队成员。他们可以让您的客户在候诊室，为开发过程做准备。我将业务分析师，网络架构师和图形设计人员作为领域专家，并根据需要将其附加到团队中。让他们用sprint 0运行。你会惊讶于在外观和工作流程方面的工作。为您的客户做好准备也是一件好事，他们的理解是，当开发真正开始时，他们的参与程度可能会上升，并且对他们来说很重要。让他们知道时间表，以便他们有足够的时间提前处理假期和假期等事情。

Answer 4

我一直处于这种精确的状态。

如果项目中有一个产品所有者，那么Phillipe绝对正确;一个团队的一个冲刺应该工作得很好。

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

如果（可能就是这种情况），企业不想改变他们想要优先排序的方式（这太方便了），那么你可以拆分团队。并运行两个并发冲刺。但是如果有一个六人小组，我不会把它分成三个以上的小组（我根本不想分开它，但我认为2-3个小组是可行的）。正如肯尼所暗示的那样进一步分裂，并且拥有一个人的团队对我来说似乎毫无意义，因为那时你不再拥有团队，只有个别程序员。

如果你正在分裂团队，我没有找到合并站立的很多价值，除非你有很多单独的冲刺工作在很多相同的代码库，但那可能是合并这些团队的论据冲刺的目的。

Answer 5

最近我一直在阅读另一种观点，即在敏捷环境中，项目的概念可能适得其反，可以消除。根据这种思路，组织应该专注于 Releases 。这是因为 Projects 是人为的工作框，在完成之前不会产生任何价值。它们违背了敏捷经常提供可交付价值的目标。 Release 更符合Agile，因为它旨在提供价值，并且可以根据团队在下一次发布之前提供的内容来减少或扩展其范围。

有一个潜在的中间立场，您公司以前称为 Project 的东西现在被重新打包为常见的敏捷主题或功能。这种方法的好处是，主题或功能现在可以在产品所有者认为合适的价值中实现。

仍然存在一个团队致力于多个产品的问题，这是一个问题，因为对域知识和可能的技术技能的合理关注。但是，使用Agile构建的产品，甚至由单个团队构建的多个产品，不断积累 Release - 值。相比之下， Projects 在完成之前是没有价值的（而且很多都没有）。

要考虑的事情......

Answer 6

我认为 anopres 是对的：最好的方法是通过 Scrum 避免同时进行多个项目。尽一切努力让人们知道并行运行太多是低效的。

让我们假设 5 人的团队有 5 个项目，每个项目大约 3 个月。

方法一：每个人在团队中从事一个项目

• 每个项目 1/5 的交付速度使所有项目的交付时间为 15 个月
• 每个人都是专家，但仅限于自己的项目
• 没有团队精神

方法二：每个项目 1 次冲刺，切换项目

• 每 6 个冲刺项目工作
• 项目工作之间的时间太长 - 项目没有定期增量价值（对于产品积压是），容易忘记，需要努力恢复上下文，
• 第一个项目在大约 12-13 个月后交付（假设 2 周冲刺）

方法三：单次冲刺 5 个项目

• 需要太多详细的任务划分才能适应冲刺
• 每个项目的增量构建很少
• 约 12-15 个月后交付第一个项目

方法四：推荐-系列作品

• 团队在一个又一个项目上工作
• 第一个项目启动并在 3 个月后交付
• 第二个项目3个月后启动，6个月后交付
• ...
• 第5个项目12个月后启动，15个月后交付
• 团队高度专注于项目、深入研究以及与客户的合作
• 整个团队对所有项目都有良好的了解
• 无需在上下文切换上浪费时间
• 需要良好的团队合作（冲突会减慢交付速度）。

如您所见，解决方案 4 通常更好，因为项目交付速度更快，团队合作高效。其他方法包括上下文切换浪费时间、没有完整的团队协作、所有项目的总交付时间很长等。

那么积压的整理又如何呢？如果团队同时处理单个项目，那就很简单 - 每个人都会加入。如果有多个项目，我们可能需要委派单个人进行单独的美容会议（不涉及整个团队）。

重要的是要让客户相信，3 个月后开始第二个项目仍然会导致更快的交付（6 个月后），而不是我们立即与所有其他项目一起开始。这是管理者们看到的一种幻觉——我们同时启动5个项目，我们努力工作，一点一点地交付。但最终这并不高效。

这就是为什么我不相信 Scrum 对于并行的多个项目是有效的，将其匹配到框架并根据 Scrum 规则工作是非常棘手的。有时，有 2 个项目可以让所有人都忙碌起来可能会很好，但我们添加的项目越多，scrum 的效率就会越低。也许看板是一种替代方案，只是为了查看进度和团队合作（不像 Scrum 团队那么强大）？

问候 亚当

Answer 7

正如@Chris所说，一个正常的项目里面有子项目。你只有一个积压工作。

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

拥有不同的产品所有者，并且由于这些产品所有者不同意他们应该给每个项目多少时间。 ＆QUOT;有人＆QUOT;将不得不吸收关于如何管理项目间优先事项的决定。注意：开发人员不应该这样做。

这是我们的项目“S”。经理将平衡产品所有者所需的资源以及团队成员可以提供的时间。产品所有者A支付了一个月的工作，但产品所有者B总是更新他的项目（并且支付给你也很好）。还有一些方法可以让你的团队平衡A以获得一个月（开发时间），并且不要阻止B填满你的口袋。

对于内部软件（一家公司，一千个项目）。不同的产品所有者应该同意给他们的时间。他们不是孤立的，而是与你在同一条船上（项目“S”经理）。他们会让你的生活更轻松，能够推迟一些任务，但与此同时你永远不会忘记他们的需求。

好吧，我还在努力找出最好的方法。但这就是我们现在所推动的。我希望它有所帮助。

Answer 8

团队成员可以在scrum项目之间分配时间，但事情要多得多 使团队成员充分专注。团队成员也可以从一个改变 冲刺到下一个，但这也降低了团队的生产力。具有较大团队的项目被组织为多个scrums，每个项目都集中在产品的不同方面 发展，与他们的努力密切协调。

Answer 9

我建议为每个项目运行一个Sprint，每天举行1次站立会议来处理所有活动的Springs /项目。

Answer 10

我愿意做出贡献。我就是这样做的：

• 每个团队有一名产品负责人和一份产品待办事项列表。产品所有者不必是一个人，但该产品所有者“实体”负责产品待办事项列表。
• 产品待办事项列表包含每个项目（此处的所有项目）的用户故事。每个用户故事都有一个工作量/故事点（团队责任）和一个业务价值（产品所有者责任）。
• 我们有一个“产品积压整理”会议来满足每个冲刺。在这次会议之前，产品负责人已经更新了故事的业务价值（如果他们出于任何业务原因需要进行一些更改 - 我们不关心也不应该关心）并包含一些新故事。在这次会议上，我们解释了新的故事，也更新了我们的努力。本次会议持续约一小时（除第一次外，约4小时）。
• 当我们要计划一个新的冲刺时，我们会打开产品待办事项列表，按投资回报率（这是商业价值/工作量）对故事进行排序，并计划故事，直到时间过去。

就是这样。我可以说这工作得很好。我们每天使用几个谷歌电子表格（产品待办事项列表和冲刺待办事项列表，都带有图表和其他内容）来完成此操作，并使用 redmine（具有特定语义）用于在线组织：时间、任务进度等

这种方法的问题是我在 sprint backlog 电子表格和 redmine 中重复了任务。但我没有找到任何在线工具可以完全在线完成此操作。我错过了 redmine 中的产品积压（没有其他语义对我有用）、jira 中的单板、taiga 中的更多故事等等