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

我对Scrum的好处和过程非常了解。我可以在待办事项列表，燃尽图，迭代，使用用户故事以及Scrum“框架”的其他各种概念中获得想法。

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

Scrum如何处理多个项目？您是否仍然只是在一定时间内安排单个项目的迭代，并且整个团队都在该项目上进行工作，然后在迭代完成后继续进行新迭代的下一个项目？还是有一种“敏捷”的方式可以同时仅由一个团队使用自己的迭代来管理多个项目？

Scrum确实并不要求您必须开发一种独立的产品。它只是说明需要完成很多工作（产品积压），在下一次迭代中有一定的开发时间可用（从项目速度中得出），并且客户可以选择某些项目/ business在此问题/任务池中具有最高优先级，将在下一次迭代中完成（冲刺积压）。

产品积压和sprint积压完全没有理由来自一个项目-即使在一个项目中，也将有离散的工作单元，就像单独的项目一样-UI，业务层，数据库架构等。尤其是企业软件开发就是这样，您在其中拥有许多必须不断进步的代码库。Scrum过程-会议，问题，明细表等-无论是一个项目还是多个项目，都可以正常工作。

话虽这么说，实际上，每次迭代都有一个主要主题通常是很好的-“执行报告模块”或“与XYZ系统的API接口”-这样，许多问题就来自一个项目或领域，并且在在迭代结束时，您可以指向大量工作并在其上打勾。

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

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

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

我不同意。我认为在冲刺阶段让团队专注于单个项目对于流程至关重要。如果您有一些无法为整个开发过程做出贡献的专家（内容作者，图形人员，业务流程分析师等），当他们无法做出贡献时，我会将他们从团队中剔除。或者更好的是，让他们接受一些不同任务的培训，以便他们可以为测试之类的事情做出贡献。

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

如果您要连续运行相同的5个项目，则可以在相同的15个月内交付第5个项目，但是您会教育客户，您的团队有这样的需求，即您有12个月的积压订单，可以使用这段时间来完善您的项目目标。或者，如果您的订单积压不断，那么您就该开始招聘另一个团队了。但是，您最好的项目将在3个月内完成，该客户的客户在活动期间已获得快速改善。您可以在一年前完成该项目，并将其放在简历中。在此期间，您的sprint速度将保持稳定，并且您可能会发现在一个或两个项目之后达到了大步前进，并且能够在给定的sprint中完成更多任务。

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

请记住，每个人都不需要成为正式的团队成员。他们可以在候车室吸引您的客户，为开发过程做准备。我保留业务分析师，网络架构师和图形设计人员为领域专家，并仅在需要时将他们加入团队。让它们以sprint 0运行。您会惊讶于外观和工作流程的参与程度。为客户做好准备的前提是，当认真开始发展时，他们的参与水平实际上可能会上升，并且对于他们而言至关重要。让他们知道日程安排，以便他们有足够的时间提前处理诸如假期和假期之类的事情。

我一直处于这种情况。

如果您在项目中只有一位产品负责人，那么Phillipe是绝对正确的；与一个团队进行一次冲刺应该很好。

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

如果（可能是这样）企业不希望改变他们对事情进行优先排序的方式（这太方便了），则可以拆分团队，并运行两个并发的sprint。但是，如果有六个团队，我不会将其拆分为三个以上的团队（我根本不想将其拆分，但是我认为2-3个团队是可行的）。按照肯尼（Kenny）的建议，进一步拆分，让一个人组成的团队在我看来似乎毫无意义，因为那样的话，您将不再有团队，只有个人程序员。

如果您要拆分团队，则在合并独立人员中并没有太大的价值，除非您在相同的代码库中有很多独立的sprint，但这可能是出于合并目的而合并这些团队的理由。冲刺。

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

有潜在的中间立场，您公司中以前称为Project的地方现在被重新包装为通用的Agile Theme或Feature。这种方法的好处是，现在可以按照产品所有者认为合适的价值来实现主题或功能。

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

需要考虑的事情...

我认为aopres是对的：最好的方法是避免使用Scrum同时避免多个项目。尽一切可能使并行运行效率不高。

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

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

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

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

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

方法3：一次冲刺中有5个项目

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

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

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

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

那么积压梳理呢？如果团队一次完成一个项目，那很简单-每个人都会加入。如果有多个项目，我们可能需要委派单个人参加单独的培训会议（不涉及整个团队）。

为客户服务很重要，三个月后开始第二个项目仍会导致交货更快（第六个月后），而不是我们立即与所有其他项目立即开始。经理们看到的幻觉-我们一次启动5个项目，我们努力工作并逐步交付。最后，这不是有效的。

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

问候，亚当

正如@Chris所说，一个普通的项目内部有子项目。但是，您只有一个积压。

考虑所有项目的待办事项。第一个问题：您是否要为任务或项目分配优先级？我确实希望每个项目都积压。至少要弄清楚产品所有者的优先事项。

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

我们的“ S”项目经理来了，它将平衡产品所有者需要的资源和团队成员可以付出的时间。产品负责人A支付了一个月的工作费用，但是产品负责人B始终在更新其项目（并且也向您付款）。有一些方法可以平衡A团队一个月的时间（开发时间），并且不会阻止B充裕。

对于内部软件（一家公司，一千个项目）。不同的产品负责人应就给他们的时间达成一致。他们并非孤立生活，而是与您同住（项目“ S”经理）。它们可以推迟某些任务，使您的生活更轻松，但与此同时，您永远不应忘记他们的需求。

好吧，我仍在尝试找出最佳方法。但这就是我们现在要推动的。希望对您有所帮助。

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

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

我想贡献。这是我的方法：

• 每个团队只有一名产品负责人，一名积压产品。产品所有者不必是一个人，但是该产品所有者的“实体”负责产品积压。
• 产品积压的产品包含每个项目（此处为所有项目）的用户故事。每个用户故事都有一个工作点/故事点（团队责任）和业务价值（产品所有者责任）。
• 我们有一个“产品积压梳理”，可以满足每个冲刺的需要。在这次会议之前，产品负责人已经更新了故事的业务价值（如果他们出于商业原因（我们不在意和不在乎）而需要进行某些更改），并且包含了一些新故事。在这次会议上，新故事得到了解释，并且努力也得到了更新。该会议持续约一个小时（第一次除外，约4个小时）。
• 当我们要计划一个新的冲刺时，我们打开产品待办事项列表，按ROI（这是业务价值/工作量）订购故事，并计划故事直到时间消失。

就是这样。我可以说这很好。我们使用几个Google电子表格（产品待办事项列表和sprint待办事项列表，包括图表和内容）进行此操作，并每天为在线组织（具有特定语义）重做（时间，任务进度等）

这种方法的问题在于，我已经在sprint待办事项电子表格中重复了任务，并重复执行了redmine。但是我找不到任何完全在线完成此操作的在线工具。我错过了Redmine中的产品积压订单（对我而言没有其他语义可用），jira中的单一公告板，taiga中的更多故事等