Scrum和其他敏捷开发方法论，提供了用于管理软件开发项目的框架。
但是很多时候，方法论都集中在项目环境上，而团队主要集中在一个共同的目标上。团队主要致力于该项目的地方。
实际上，情况往往并非如此。
实际上，经常需要开发团队来开发和支持多种产品。具有多个产品所有者的多个产品。特别是在‘business as usual’持续的发展。
那么，您如何共享一个敏捷开发团队呢？
作为资源池运行通常并不理想。每个人都把他们的要求扔在墙上。那些大声喊叫的人会成为团队成员’的注意。也许更大的产品可以吸引团队’的关注，却以永远无法成为榜首，永远不会成为榜首的较小产品为代价。
按产品划分团队听起来很棒。但是有时候团队’太小，无法采用这种方法。否则会留下过多的个人开发人员，从而导致封面问题，您可以’每种产品只能与一名开发人员合作！
所以，你可以做什么？
我们很多团队中都有类似的情况。概括地说，我们正在这样解决它：
- 每个产品只有一位产品负责人。产品负责人为每个产品维护一个单独的产品待办列表。
- 开发团队是一个团队。
- Sprint预算（Sprint /迭代的可用工时数）是根据我们的充值方式分配给每个产品的，例如60％-20％-20％。如果你不这样做’充值后，作为一般经验法则，您可以在更高级别上同意这一点。每个产品都有每个Sprint预算的已知百分比。
- 用例/用户故事/功能被分解为任务，并由开发团队在Sprint计划期间进行估算。
- 每个产品负责人只能包括从其产品待办事项列表到分配的Sprint预算百分比的任务。
这种方法意味着开发团队可以作为一个团队。某人下班时有知识共享和掩护，因为在这种情况下，整体Sprint预算减少了，但每个人仍然获得了通常的可用时间百分比。
这也意味着团队成员不要’不必在0.x FTE的基础上兼顾产品之间的时间，这充其量是尴尬的，当分数太小或奇数时，根本就不可能。
相反，在Sprint中分配的任务已经适合每个产品的Sprint预算，这意味着团队成员可以专注于在Sprint中交付任务，而不必担心如何分配时间。
凯莉
也可以看看：
10 Key Principles of 敏捷 Software Development
10 Good Reasons to do 敏捷 Development
Top 10 敏捷 Development web sites
