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

【问题标题】：How does Scrum work when you have multiple projects? [closed]当您有多个项目时，Scrum 如何工作？ [关闭]
【发布时间】：2010-09-29 13:51:25
【问题描述】：

我非常了解 Scrum 的好处和流程。我得到了关于积压、燃尽图、迭代、使用用户故事以及 Scrum“框架”的其他各种概念的想法。

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

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

【问题讨论】：

我希望我知道，我有 3+ 个项目，并且每天必须做 3+ 个 SCRUMS。 :哭:
这个问题是题外话，因为它不在本网站的范围内，如What topics can I ask about here? 中定义的那样另见：What types of questions should I avoid asking? 您可以在another Stack Exchange site 上提问，例如@ 987654324@ 或Software Engineering。请务必阅读您打算在其上发布问题的任何网站的帮助中心的主题页面。
@Makyen 这里要考虑的一件事是，这个问题已经成功地存在了 8.5 年，并且早在大多数子 Stack Exchange 存在之前就已经出现了。因此，虽然现在这个主题可能最好由项目管理堆栈交换之类的东西来解决，但当时有关 Scrum 实践的问题与开发人员及其在如何最好地完成工作方面的方法非常相关。
我同意，在被问到时这是合理的。作为一个问题，这个问题没有错。目前这不是 SO 的主题。随着时间的推移，SO 的主题发生了变化。虽然这个问题是程序员感兴趣的，但它主要不是关于编程的。它是关于 Scrum 过程的，它是一种管理项目的方法，而不是专门的编程。它是关于“管理多个项目......只有一个团队......”，这可能是各种各样的项目类型。因此，关闭它是合适的。我不会投票删除它，因为这里有有用的信息。
我投票结束这个问题，因为它是关于组织实践，而不是编程。

标签： project-management agile scrum

【解决方案1】：

Scrum 并不要求您必须开发一个独立的产品。它只是说明有一堆东西需要完成（产品积压），在下一次迭代中有一定的开发时间可用（从项目速度中计算出来），并且有客户选择的项目/business 将在下一次迭代（sprint backlog）中完成的这个问题/任务池中具有最高优先级。

产品 backlog 和 sprint backlog 没有理由必须来自同一个项目 - 即使在单个项目中，也会有像单独项目一样的离散工作单元 - UI、业务层、数据库架构等等。特别是企业软件开发就是这样，你有许多代码库，它们都必须在进步。 Scrum 流程——会议、问题、燃尽图等——无论是一个项目还是多个项目都有效。

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

【讨论】：

+1：Scrum 的本质是协调活动的日常站立会议。适用于单个或多个项目。
我不同意 S.Lott，我认为本质是 sprint，站立会议是管理 sprint 的工具。我会运行 6 个 sprint 或每个项目 1 个。
@Kenny：如果不是必须的，您会省去每个单独项目的每日站立会议吗？如果是这样，您将如何使每个项目的冲刺保持在正轨上？
@S.Lott，如果出现问题，会议是为了解决问题。我会为整个团队站出来。保持知情并没有什么坏处，不同/新的观点通常很有价值。
那么 3 个项目，3 个团队成员各自为不同的产品所有者开发自己的代码库呢？在这种情况下，有 3 个团队吗？

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

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

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

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

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

请记住，每个人都不需要成为完整的团队成员。他们可以在候诊室与您的客户互动，为开发过程做准备。我让我的业务分析师、网络架构师和图形设计人员担任领域专家，并且只根据需要将他们加入团队。让它们以 sprint 0 运行。您会惊讶于在外观和工作流程上的工作是多么引人入胜。让您的客户做好准备也很重要，即当认真开始开发时，他们的参与程度实际上可能会提高，并且让他们有空是很重要的。让他们知道日程安排，以便他们有足够的时间提前处理假期和假期等事情。

【讨论】：

这仅适用于您可以重新分配团队成员的情况。如果他们无处可去，你不能让他们闲着。

【解决方案4】：

我一直处于这种情况。

如果您的项目中只有一位产品负责人，那么 Phillipe 是绝对正确的；一个团队的一个冲刺应该可以正常工作。

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

如果（可能是这种情况）企业不想改变他们想要的优先顺序（这太方便了），那么您可以拆分团队，并同时运行两个冲刺。但是对于一个六人的团队，我不会将其拆分为超过 3 个团队（我根本不想拆分它，但我认为 2-3 个团队是可行的）。像 Kenny 建议的那样进一步拆分，让一个人组成的团队在我看来有点毫无意义，因为那样你就不再有团队了，只有个人程序员。

如果您要拆分团队，我发现合并站立会议没有太大价值，除非您有单独的 sprint 处理非常多的相同代码库，但这可能是合并这些团队的理由冲刺的目的。

【讨论】：

【解决方案5】：

我最近一直在阅读另一种观点，即在敏捷环境中，项目的概念可能会适得其反，并且可能会被淘汰。根据这种思路，组织应该专注于发布。这是因为项目是人工的工作盒子，在完成之前不会产生任何价值。它们与敏捷提供可交付价值的目标背道而驰。发布更符合敏捷，因为它以交付价值为导向，并且可以根据团队在下一个发布之前交付的内容来缩小或扩大其范围。

有一个潜在的中间地带，您公司以前称为项目的东西现在被重新包装为常见的敏捷主题或功能强>。这种方法的好处是，主题或功能现在可以按照产品所有者认为合适的方式实现。

仍然存在一个团队开发多个产品的问题，这是一个出于对领域知识和可能的技术技能的合理担忧的问题。但是使用敏捷构建的产品，甚至是由单个团队构建的多个产品，都在不断地积累发布的价值。相比之下，项目在完成之前一文不值（而且很多项目都没有）。

想一想……

【讨论】：

同意，我们应该尽量减少“软件库存”，这是尚未投入使用的累积商业价值。

【解决方案6】：

我认为 anopres 是对的：最好的方法是使用 scrum 避免同时进行多个项目。尽一切努力证明并行运行过多是没有效率的。

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

方法 1：每个人在团队中处理单个项目

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

方法 2：每个项目 1 个 sprint，切换项目

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

方法 3：单个 sprint 中的 5 个项目

为了适应 sprint 需要对任务进行太多详细的拆分
每个项目的增量构建非常少
大约 12-15 个月后交付第一个项目

方法 4：推荐 - 序列化工作

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

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

那么积压梳理呢？如果团队同时在一个项目上工作，那很简单——每个人都会加入。如果有多个项目，我们可能需要委派一个人参加单独的梳理会议（不涉及整个团队）。

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

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

问候，亚当

【讨论】：

【解决方案7】：

正如@Chris 所说，一个普通的项目里面有子项目。不过，您只有一份积压工作。

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

拥有不同的产品负责人，并且由于这些产品负责人不会就他们应该为每个项目投入多少时间达成一致。 “某人”将不得不放弃关于如何管理项目间优先级的决定。注意：开发人员不应该这样做。

我们的项目“S”经理来了，他将平衡产品所有者所需的资源和团队成员可以给予的时间。产品负责人 A 支付了一个月的工作费用，但产品负责人 B 一直在更新他的项目（并且还给了你丰厚的报酬）。有一些方法可以平衡你的团队，让 A 有一个月的时间（开发人员时间），并且不要阻止 B 填满你的口袋。

以内部软件为例（一家公司，一千个项目）。不同的产品所有者应该就给予他们的时间达成一致。他们不是孤立地生活，而是与您（项目“S”经理）在同一条船上。推迟一些任务会让你的生活更轻松，但同时你也不应该忘记他们的需求。

嗯，我仍在尝试找出最好的方法来做到这一点。但这就是我们现在正在推动的。希望对你有帮助。

【讨论】：

【解决方案8】：

团队成员可以在 Scrum 项目之间分配他们的时间，但更多的是让团队成员全心全意地投入工作。团队成员也可以从一个改变冲刺到下一个，但这也降低了团队的生产力。具有较大团队的项目被组织为多个 scrum，每个 scrum 都专注于产品的不同方面发展，并密切协调他们的努力。

【讨论】：

【解决方案9】：

我建议为每个项目运行一个 Sprint，并召开 1 次每日站立会议来处理所有活跃的 Springs/项目。

【讨论】：

肯尼每次为每个项目冲刺一次？或者您是在谈论一次运行多个 sprint 并像其他人建议的那样拆分团队？
嘿蒂姆，我想不通过将团队拆分为 sprint 来改变您的团队结构，而只是为每个项目运行单独的 sprint/backlogs/etc...。在每次站立会议上，让每个人评论他们所困扰的问题。对我来说，跟上每个人/所有事情，或了解情况会很好。

【解决方案10】：

我想贡献。我就是这样做的：

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

就是这样。我可以说这很好用。我们使用几个 google 电子表格（产品待办事项和 sprint 待办事项，都带有图表和资料）来执行此操作，并每天为在线组织进行 redmine（具有特定语义）：时间、任务进度等

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

【讨论】：

您如何专注于待办事项中的每个产品？标签、命名约定等 ?我已经实施了类似的方法，但试图将所有内容都保留在 TFS 中，但还没有找到一个好的解决方案来允许功能/故事的积压和产品视图。