Agile / Scrum是答案吗？ Scrum如何处理这个问题？
一个产品负责人，一个产品Backlog与多个产品所有者和产品积压？
它对你有用吗？请分享你成功失败的故事？
我正在尝试将一个流程放在一起来管理多个工作队列 基础设施项目，简单的功能增强，然后是大型项目 由6-7名开发人员组成的小型开发团队。
答案 0 :(得分：2)
缺少一点是技术上是否是一种产品（如同一个代码库，即使是大型代码）。
如果那些完全独立的产品那么使用Scrum我会进行非常短的冲刺（1-2周）和序列开发工作。因此，两个星期项目A，然后项目B，然后是C，然后再次A - 可能是两个冲刺，然后是C等。在这种情况下，单个积压没有意义，应该为A，B和C保留单独的积压。至少知道一个像这样工作的团队。
您是否需要更多PO，而不是产品知识的功能。也许每个项目都需要一个人，也许你有一个知道A，B和C足够成为PO的人。
如果是不同的产品，那么当你尝试通过从不同的积压工作中获取不同的故事时，你最终会得到的是分裂团队。当然人们会专注于给定的项目，也很难有一个很好的定义完成（如果我们可以为A和B发送新的增量而不是C这个冲刺？我们会这样做吗？）。如果你不能对短冲刺的项目进行排序，那么我会向Kanban寻求尝试将一些组织纳入其中。
如果这是一个产品/一个代码库 - 那么事情会容易得多。即使团队因为不同的项目而不得不触及代码库的不同区域，他们仍将使用相同的产品，因此Scrum的所有机制都将很好地应用。一个积压，一个PO。
需要注意的一个缺点是，团队中的人员将进行上下文切换，无论您使用何种流程，都会受到惩罚。无论您选择哪种流程，都应尽量尽量缩短（只要业务能够持有）。关于Scrum的好处是，它与PO建立了一致，上下文切换只能在短跑边界发生 - 换句话说，团队将在需要切换到另一个项目之前集中精力1-2周。
另外，不要忘记敏捷的所有技术实践。单元测试。自动构建＆amp;试验。代码评论。聪明地使用回购。高标准重新。质量。在这样一个充满挑战的环境中，所有这些都是必须的。
答案 1 :(得分：1)
更多细节可能会有所帮助。 它是一个大型的生产团队，它们之间分享了很多项目吗？这是一个拥有大量项目的小团队（5个人）吗？
为什么你有很多项目？他们是否在不同的时间框架上工作，其中一些是“真正的工作”，另一些则是“如果你不忙于将此作为后台任务”。
我认为这里的关键可能是项目与开发者的比率。
我们有一个大约15个部门，任何时候都可以运行3-4个项目。人们通常在任何时候属于一个项目，但是当项目经历不同阶段时，他们可以在他们之间移动，并且需要不同的技能。特别是测试似乎很多都会改变项目。
至于严格的流程......使流程符合您的需求。如果我们能够更好地了解您的需求，我们可能会提出更好的建议。
答案 2 :(得分：1)
我猜你可以做两件事：
或两者兼而有之：）
敏捷/ Scrum是很好的流行语，但似乎与你的问题无关。 因为它们适用于项目的范围，而不适用于一堆项目。
我有第二个选项的经验，直到开发人员有更多项目的水平，这不是你想要的。但是通过合适的代码审查会议，它似乎确实有效。
答案 3 :(得分：1)
一个关键因素是多个产品所有者需要彼此了解并能够在开发范围之外一起工作。如果他们被隔离到他们自己的领地，并且每个人都试图比其他人更响亮以获得“他们的产品”所应得的关注，那么你将会遇到问题。
当任何开发工作提交给团队时，这些事情应该已经理顺了。开发人员不应该关心（或者，在某些情况下，甚至懒得知道）什么任务是什么所有者或什么项目，等等。他们可以关心并知道这些事情，当然，但它不应该不重要。
产品所有者和其他各种高级角色需要开始每个sprint，并计划在该sprint期间完成哪些故事。任何给定项目中包含多少故事并不重要，对其进行排序是对这些利益相关者的安排关注。与架构师或高级开发人员等合作，他们应该简单地决定在当前/下一个sprint中实现哪些故事。
（另一方面，我有一个针对这类事情的51区提案：http://area51.stackexchange.com/proposals/9543/development-methodologies）
答案 4 :(得分：0)
恕我直言，当你有一个由4到6名开发人员组成的团队至少进行为期两到三周的3到4次迭代时，Scrum会更有效。所以对于+ - 400人/天的项目
我认为一次做多个项目是个坏主意。
请同时查看此前已回答的问题：
答案 5 :(得分：0)