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

Question

关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

3年前关闭。




Improve this question




敏捷/Scrum 是答案吗？ Scrum 如何处理这个问题？

一个产品负责人，一个产品待办列表 vs 多个产品负责人和产品待办列表？

它如何为您工作？请分享您的成功失败故事？

我正在尝试将一个流程放在一起来管理多个工作队列，从
基础设施项目，简单的功能增强，然后是大项目
由 6-7 名开发人员组成的小型开发团队。

Answer 1

缺少的一点是，这在技术上是否是一种产品(例如一个代码库，即使很大)。

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

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

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

如果这是 一个产品/一个代码库 - 那么事情就容易多了。即使团队因不同的项目而不得不接触代码库的不同区域，他们仍将致力于相同的产品，因此 Scrum 的所有机制都将很好地应用。一份积压，一份 PO。

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

另外，不要忘记敏捷的所有技术实践。单元测试。自动构建和测试。代码审查。巧妙地使用 repo 。高标准重新。质量。在如此具有挑战性的环境中，所有这些都是必须的。