92

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

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

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

4

10 回答 10

61

Scrum 并没有真正规定你必须开发一个独立的产品。它只是说明有一堆东西需要完成（产品待办事项），在下一次迭代中有一定的开发时间可用（根据项目速度计算），并且有客户选择的项目/business 将在下一次迭代（sprint backlog）中完成的这个问题/任务池中具有最高优先级。

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

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

于 2009-01-05T08:07:00.723 回答
26

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

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

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

于 2009-01-05T11:19:39.413 回答
16

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

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

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

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

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

于 2012-07-13T12:44:18.917 回答
8

我一直处于这种精确的情况。

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

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

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

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

于 2009-01-05T13:18:18.287 回答
5

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

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

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

有什么要考虑的...

于 2014-04-29T19:08:55.763 回答
4

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

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

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

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

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

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

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

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

方法四：推荐——序列化工作

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

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

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

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

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

问候，亚当

于 2015-10-26T21:04:25.073 回答
3

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

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

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

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

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

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

于 2010-04-06T20:49:11.113 回答
3

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

于 2012-11-26T15:10:12.697 回答
0

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

于 2009-01-05T12:58:37.560 回答
0

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

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

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

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

于 2016-02-19T10:05:49.580 回答