如果您有多个项目，Scrum如何工作？
我对Scrum的好处和stream程有相当的了解。 我得到了关于积压，burndown图表，迭代，使用用户故事和Scrum“框架”的其他各种概念的想法。
有了这个说法……我为一家networking开发公司工作，该公司一次pipe理多个项目，六个团队成员组成“生产团队”。
Scrum如何处理多个项目？ 你是否仍然在一定的时间内为单个项目计划一个迭代，整个团队都在这个迭代中工作，然后当迭代完成时，用新的迭代转向下一个项目？ 还是在一个团队中同时pipe理多个项目的“敏捷”方式？
Scrum并不意味着你必须在一个独立的产品上工作。 它只是表示需要完成一些工作（产品积压），在下一次迭代中有一定的开发时间（根据项目速度计算），并且有客户select的项目/业务作为在下一次迭代（sprint积压）中将完成的问题/任务池中的最高优先级。
没有理由，产品积压和冲刺积压必须来自一个项目 – 即使在一个单独的项目中，也会有独立的工作单元，如单独的项目 – 用户界面，业务层，数据库模式等。特别是企业软件开发是这样的，你有许多代码基础，都必须进步。 Scrum过程 – 会议，问题，图表等 – 无论是一个项目还是多个项目，都可以工作。
话虽如此，但在实践中，每次迭代通常都有一个主题 – “做报告模块”或“与XYZ系统的API接口” – 这样一来，很多问题就来自于一个项目或领域，迭代结束时，您可以指向大量工作，并对其进行打勾。
我认为答案取决于“ 谁将优先处理积压项目 ”（即决定首先需要做什么）。 如果这是一个人，那么这个人就是您的项目的产品负责人，并且您可以有一个积压项目将所有项目的所有项目 – 或者每个项目的积压 – 并且当您计划时select来自所有项目的积压项目冲刺。 在这种情况下，Scrum“工作”很好。
如果每个项目都有自己的责任，那么你很可能会遇到一些麻烦，每个负责人或多或less有意识地试图支持它的项目。 恕我直言，你需要有一个产品负责人只有通过仲裁来解决优先权。
在这种情况下应该遵循的一条规则是在Sprint期间永远不要改变Sprint的内容 。 如有必要，您可以将迭代周期缩短为两周或三周，以降低在当前Sprint中添加紧急项目的风险。
我不同意。 我认为在冲刺期间让一个团队专注于单个项目是这个过程的关键。 如果你有一些专家不能为整个开发过程做贡献（内容作者，graphics人员，业务stream程分析师等），当他们不能再作出贡献的时候，我会把他们从团队中洗牌。 或者更好的是，让他们接受一些不同的任务训练，以便他们能够为testing等事情做出贡献。
还有一件事要记住，并行运行的项目会导致你的日程安排失败。 考虑一下：为了简单起见，可以说我们有5个项目使用相同的团队，并从同一天开始。 每个项目需要3个月的努力，在最好的情况下并行运行，您将一次完成，需要15个月的时间。 你的速度会变成奶油，因为你只能在一次冲刺中一个月的五分之一的努力。 你也将同时做5个演示会议。 所以最好的情况是，你在15个月内交付你的5个项目，你的竞争对手会声称他们可以在3年完成同样的工作。你估计到期的团队将受到影响，因为他们只能考虑20％的可用劳动力。 你可能会发现你实际上无法在单个sprint中执行一些任务。 如果你不得不改变从5开始工作的项目数量，你的团队将不得不调整他们的估算习惯，这会损害团队效率。 此外，当简单的任务重新分配可能需要在开始工作之前需要旋转新的开发环境时，您的团队将很难自行组织。
如果你连续运行同样的5个项目，你会在同样的15个月内交付第五个项目，但是你应该教育你的客户，你的团队需要你有12个月的积压，你可以使用那个时候来完善你的项目目标。 或者如果你有一个不断的积压，你就知道是时候开始招聘另一个团队了。 但是，最好的项目是在3个月内完成的，并且在活动期间已经看到了快速的改善。 你可以在一年前完成这个项目，并且可以把它放在你的简历上。 你的冲刺速度将在这段时间内稳定下来，你可能会发现，在一两个项目之后，冲刺的步伐会在一个特定的冲刺中完成得更多。
我认为连续运行项目是一个组织尝试采用Scrum的最大障碍之一。 这是一个与解构项目经理angular色有关的重大文化变革，但是Scrum过程的好处是巨大的。
请记住，每个人不需要是一个完整的团队成员。 他们可以让您的客户进入候车室，为开发过程做好准备。 我将我的业务分析师，networking架构师和graphicsdevise人员保留为领域专家，并根据需要将他们附加到团队中。 让他们以sprint 0运行。您会惊讶于从事外观和工作stream程方面的工作。 在准备开始的时候，让你的客户做好准备也是件好事，他们的参与程度实际上可能会提高，而且重要的是他们可以得到。 让他们知道日程安排，让他们有足够的时间提前处理假期和假期等事情。
我一直在这个确切的情况。
如果你在项目中有一个产品负责人，那么Phillipe是绝对正确的。 一个冲刺与一个团队应该工作得很好。
如果您有多个产品所有者，那么理想的情况是，企业方需要select一个负责安排工作的“优先级sorting器”。 这绝对是最好的解决scheme。
如果（可能是这种情况）企业不想改变他们想要的优先级（这太方便了），那么你可以拆分团队，并且运行两个并发的冲刺。 然而，一支六人的球队，我不会把它分成三支以上的球队（我根本不想分割，但我认为2-3支球队是可行的）。 像肯尼所说的那样进一步分裂，让一个人的团队在我看来似乎毫无意义，因为你们不再有团队，只有个别的程序员。
如果你正在分裂团队，除非你在单独的代码基础上分开工作，否则我并没有在合并站点时发现太多的价值，但是这可能是一个为了冲刺。
我最近还看到另外一个观点，那就是在敏捷的环境下， 项目的概念可能适得其反，可以被淘汰。 按照这种思路，组织应该把重点放在发布上 。 这是因为项目是人造的工作箱，只有在完成之后才能产生价值。 这违背了雅居乐频繁提供可交付价值的目标。 一个版本更符合敏捷，因为它的目标是实现价值，因为它的范围可以根据团队在下一个版本之前可以提供的内容来缩小或扩大。
现在有一个潜在的中间地带，其中以前称为贵公司的项目现在被重新包装为普通的敏捷主题或特征 。 这种方法的好处是， 主题或特征现在可以按照产品所有者认为合适的价值实现。
还有一个团队在多个产品上工作的问题，这是一个问题，因为对领域知识和可能的技术技能的合理关注。 但是使用敏捷构build的产品 ，甚至是由单个团队构build的多个产品 ，都在不断地积累可释放的价值。 相反， 项目在完成之前是没有价值的（许多项目都没有）。
有些事情要考虑…
正如@Chris所说，一个正常的项目里面有子项目。 你只有一个积压。
在所有的项目积压。 第一个问题：你是否将任务或项目分配给优先级？ 我更喜欢每个项目的积压。 至less要明确产品所有者的优先权。
拥有不同的产品所有者，以及由于这些产品所有者不同意他们应该给每个项目多less时间。 “有人”将不得不吸取关于如何pipe理项目间优先事项的决定。 注意：开发人员不应该这样做。
在这里，我们的项目“S”经理将平衡产品所有者需要的资源和团队成员的时间。 产品所有者A支付了一个月的工作时间，但产品负责人B总是更新他的项目（并支付给您）。 有一些方法可以让你的团队平衡A，让他有一个月的时间（开发者时间），并且不要阻止B填满你的口袋。
在内部软件（一家公司，一千个项目）的情况下。 不同的产品所有者应该同意给予他们的时间。 他们不是孤立的，而是和你一样（项目“S”经理）。 他们会让你的生活更容易推迟一些任务，但同时你也不应该忘记他们的需求。
那么，我仍然试图找出最好的方法来做到这一点。 但这就是我们现在正在推动的。 我希望它有帮助。
团队成员可以在Scrum项目之间分配时间，但团队成员完全致力于更有效率。 团队成员也可以从一个冲刺改变到另一个冲刺，但这也会降低团队的生产力。 拥有较大团队的项目被组织为多个团队，每个团队都将重点放在产品开发的不同方面上，并密切协调他们的工作。
我认为anopres是正确的：最好的办法是同时避免多个项目与scrum。 千方百计地平行跑得太高，效率不高。
让我们假设5个项目，每个约3个月，为5个人的团队。
方法1：每个人在团队中的单个项目上工作
- 每个项目的1/5交货速度为所有项目提供了15个月的交货期
- 每个人都是专家，但只有在自己的项目
- 没有团队精神
方法2：每个项目冲刺1次，切换项目
- 项目中的每一个短跑都在进行
- 项目工作之间的时间太长 – 对于项目而言不是定期增量值（对于产品积压是），容易忘记，恢复上下文所需的努力，
- 第一个项目在大约12-13个月后交付（假设2周冲刺）
方法3：单个冲刺中的5个项目
- 为了适应冲刺，需要进行太多细致的任务分割
- 每个项目的增量构build非常less
- 大约12-15个月后交付第一个项目
方法4：build议 – 序列化的工作
- 项目之后团队在单个项目上工作
- 第一个项目在3个月后开始交付
- 第二个项目在3个月后开始，6个月后交付
- …
- 第五个项目在12个月后开始，15个月后交付
- 团队高度关注项目，深入研究和与客户的协作
- 整个团队对所有项目都有一般的了解
- 上下文切换没有浪费时间
- 需要良好的团队合作（冲突会减慢交付）。
正如你所看到的，解决scheme4通常会更好，因为项目的交付速度要快得多，团队一起工作并且高效。 其他方法包括从上下文切换浪费时间，没有充分的团队协作，所有项目的交付时间非常长。
那么积压梳理呢？ 如果团队同时在单个项目上工作，那么很简单 – 每个人都会join。 如果有多个项目，我们可能需要委派单独的人员进行梳理会议（不涉及整个团队）。
重要的是要让客户相信，在3个月后开始第二个项目仍然会导致更快的交付（第六个月后），而不是如果我们立即与其他所有人开始交付。 pipe理者看到的是一个幻觉 – 我们立刻开始了5个项目，我们努力工作，一点一点地交付。 但最后这不是有效的。
这就是为什么我不相信Scrum对于多个项目是同时有效的，将它匹配到框架和按照Scrum规则工作是非常棘手的。 有时候可能有两个项目可以让所有人都被占用，但是我们添加的项目越less效率越低。 也许看板只是看到进步和团队合作的一种select（不像Scrum团队那么强大）？
问候，亚当
我build议为每个项目运行一个Sprint，并且每天有一个站立会议来处理所有活动的Springs /项目。
我想贡献。 这是我做的方式：
- 每个团队有一个产品所有者和一个产品积压。 产品所有者不一定是一个人，而是产品所有者“实体”负责产品积压。
- 产品积压具有每个项目的用户故事（这里的所有项目）。 每个用户故事都有一个努力/故事点（团队责任）和一个商业价值（产品责任人）。
- 我们有一个“产品积压梳理”会议每个冲刺。 在这次会议之前，产品所有者已经更新了故事的商业价值（如果出于任何商业原因，我们不需要也不应该关心，他们需要改变），并且包括一些新的故事。 在这次会议上，新的故事被解释，并且努力也被更新。 这次会议持续约一个小时（第一次除外，约4小时）。
- 当我们计划一个新的冲刺时，我们打开产品积压，通过投资回报（这是商业价值/努力）排列故事，并计划故事，直到时间消逝。
就是这样。 我可以说这工作得很好。 我们使用几个谷歌电子表格（产品积压和冲刺积压的东西，都与图表和东西），这样做，并redmine（与特定的语义）每天在线组织：时间，任务进度等
这种方法的问题是我有重复的冲刺积压电子表格和redmine的任务。 但是我没有find任何在线工具来完成这个在线。 我错过了redmine的产品积压（对我来说没有其他的语义工作），jira中的单个委员会，taiga的更多故事，等等
