当您有多个项目时，Scrum如何工作？

最近我一直在阅读另一种观点，即在敏捷环境中的概念
的
项目
</强>
可能适得其反，可以消除。根据这种思路，组织应该关注
的
发布
</强>
代替。这是因为

项目

是人造的工作箱，在完成之前不会产生任何价值。它们违背了敏捷经常提供可交付价值的目标。一个

发布

更符合敏捷，因为它旨在提供价值，因为它的范围可以根据团队在下一个团队之前提供的内容来减少或扩展

发布

。

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

• 
  每个团队有一个产品所有者和一个产品待办事项。产品所有者不必是一个人，但该产品所有者“实体”负责产品积压。
  


• 
  产品待办事项包含每个项目的用户故事（此处的所有项目）。每个用户故事都有一个努力/故事点（团队责任）和一个商业价值（产品所有者责任）。
  


• 
  我们在每个冲刺阶段都会举行“产品积压培训”会议。在此次会议之前，产品所有者已经更新了故事的业务价值（如果他们需要针对任何业务原因进行一些更改 - 我们不会也不应该关心）并包含一些新故事。在这次会议中，将解释新故事并更新努力。这次会议持续约一个小时（第一次，约4小时除外）。
  


• 
  当我们计划一个新的冲刺时，我们打开产品积压，按ROI订购故事（这是商业价值/努力）并计划故事，直到时间消失。
  

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

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

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

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

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

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

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

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

我认为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团队那么强大）？

问候，
亚当

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

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

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

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