当您有多个项目时，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

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

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

仍然存在一个团队致力于多个产品的问题，这是一个问题，因为对领域知识和可能的技术技能的合理关注。 但是， 产品具有敏捷而建，甚至多个产品由单一的建队，都在不断累积释放 -able值。 相比之下， 项目在完成之前是没有价值的（许多人没有）。

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

Answer 6

我认为anopres是对的：最好的方法是使用scrum同时避免多个项目。 尽一切努力使并行运行太多并不高效。

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

方法1：每个人在团队中的单个项目上工作

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

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

• 每第6个冲刺都在项目上工作
• 项目工作之间的时间太长 - 不是项目的常规增量值（产品积压是），容易忘记，恢复上下文所需的工作量，
• 第一个项目在大约12-13个月后交付（假设冲刺2周）

方法3：单个冲刺中的5个项目

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

方法4：建议 - 序列化工作

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

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

积压修饰怎么样？ 如果团队一次完成单个项目，那很简单 - 每个人都会加入。 如果有多个项目，我们可能需要将单个人委派给单独的修饰会话（不涉及完整的团队）。

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

这就是为什么我不相信scrum对多个项目并行有效，将它与框架相匹配并根据scrum规则工作是非常棘手的。 有时可能有两个项目可以让所有人都被占用，但是我们添加的项目越多，效率就越低。 也许kanban只是看到进步和团队工作的一种选择（不像Scrum团队那么强大）？

问候，亚当

Answer 7

团队成员可以在scrum项目之间分配时间，但让团队成员完全专注，效率更高。 团队成员也可以从一个sprint更改为下一个sprint，但这也会降低团队的工作效率。 具有较大团队的项目被组织为多个scrums，每个项目都集中在产品开发的不同方面，并密切协调他们的工作。

Answer 8

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

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

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

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

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

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

Answer 9

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

• 每个团队有一个产品所有者和一个产品待办事项。 产品所有者不必是一个人，但该产品所有者“实体”负责产品积压。
• 产品待办事项包含每个项目的用户故事（此处的所有项目）。 每个用户故事都有一个努力/故事点（团队责任）和一个商业价值（产品所有者责任）。
• 我们在每个冲刺阶段都会举行“产品积压培训”会议。 在此次会议之前，产品所有者已更新故事的业务价值（如果他们需要针对任何业务原因进行一些更改 - 我们不会也不应该关心）并包含一些新故事。 在这次会议中，将解释新故事并更新努力。 这次会议持续约一个小时（第一次，约4小时除外）。
• 当我们计划一个新的冲刺时，我们打开产品积压，按ROI订购故事（这是商业价值/努力）并计划故事，直到时间消失。

就是这样。 我可以说这很好用。 我们使用一些谷歌电子表格（产品积压和sprint积压的那些，包括图表和东西）来做这件事，并且每天为在线组织redmine（具有特定的语义）：时间，任务进度等

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

Answer 10

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