问当您只有一个开发团队时，处理多个项目的最佳方式是什么？

EN

我想你可以做两件事：

1. 完成一个项目的一个版本，完成后，执行下一个
2. 拆分您的开发团队

或者两者的组合:)

敏捷/Scrum是很好的流行语，但似乎与你的问题没有太大关系。因为它们适用于一个项目的范围，而不是一堆项目。

我有第二种选择的经验，直到有更多的项目比开发人员更多，这不是你想要的。但是，有了像样的代码审查会议，它看起来确实有效。

缺少的一点是，从技术上讲，这是否是一个产品(就像一个代码库，即使很大)。

如果它们是完全独立的产品，那么使用Scrum，我会用很短的冲刺(1-2周)和序列开发工作。所以两周的项目A，然后是项目B，然后是C，然后是A--可能是两个冲刺，然后是C等等。在这种情况下，单个积压没有意义，应该为A，B和C保留单独的积压。我知道至少有一个团队是这样工作的。

你是否需要更多的POs是一个关于产品知识的函数。也许你每个项目都需要有人，也许你有一个足够了解A，B和C的人来担任PO。

如果是不同的产品，那么当你尝试从不同的积压中获取不同的故事时，你最终会得到split team。当然，人们会专注于给定的项目，而且很难对完成有一个好的定义(如果我们可以为A和B提供新的增量，而不是C，那么我们就完成了吗？)如果你不能用短冲刺对项目进行排序，那么我会期待看板尝试将一些组织投入其中。

如果这是one product/one codebase -那么事情就简单多了。即使团队因为不同的项目而不得不接触代码库的不同区域，他们仍然会在相同的产品上工作，所以Scrum的所有机制都会很好地应用。一个待办事项，一个采购订单。

需要注意的一个缺点是，团队中的人将进行上下文切换，并且无论您使用什么流程，这样做都会受到惩罚。无论您选择哪种流程，都应该尽可能长时间地尽量减少这种情况(只要业务能够保持)。关于Scrum的好处是，它与PO达成了一个内置的协议，即上下文切换只能在sprint边界发生-换句话说，在切换到另一个项目之前，团队将有1-2周的时间来集中精力。

此外，不要忘记敏捷的所有技术实践。单元测试。自动构建和测试。代码评审。巧妙地使用repos。高标准re。质量。在这样一个充满挑战的环境中，所有这些都是必须的。

更多的细节可能会有所帮助。是不是一个很大的生产团队，在他们之间共享很多项目？它是一个小团队(5岁左右)，有很多项目吗？

为什么你有这么多项目？他们是否在不同的时间范围内工作，一些是“真正的工作”，另一些是“如果你不忙的话，把这个作为后台任务”。

我想这里的关键可能是项目与开发人员的比率。

我们有一个大约15人的部门，在任何时候运行3-4个项目。人们通常在任何时候都属于一个项目，但随着项目经历不同的阶段，以及需要不同的技能，人们可以在他们之间移动。尤其是测试，似乎经常切换项目。

至于严格的process...make，该流程符合您的需求。如果我们能更好地了解你的需求，我们也许能提出更好的建议。