这里有一个有趣的例子:多个敏捷团队跨多个相关但独立的产品……
你好,
我搜索了一下，但我只看到关于多个敏捷团队开发一个产品的帖子。我目前的情况如下:
- 大约两年前，我在一家从瀑布式过渡到敏捷式的公司担任采购总监。
- 在我来之前，我管理的产品并没有正式的采购订单——开发主管在她的主要职责和采购订单上工作了两倍的时间。
- 现在，我们有三个不同的产品和三个不同的敏捷团队在这些产品上工作(团队不专注于特定的产品)。
- 在这三个产品中，两个有单一的backlog，一个有多个(考虑到这个产品是为每个客户高度定制的，尽管它有部分共享的公共代码库)。
- 我们还有三个不同的团队级别的积压工作。团队backlog包含了本质上指向产品故事的故事。
- 目前，该设置支持以下需求:
- 提供一种方法，将跨三个产品的工作组合到团队级ecr中，需要跨多个产品进行新功能/错误等工作。
- 在产品backlog上提供一个工作流，在团队backlog上提供一个不同的、简化的工作流。(产品项目需要更广泛的团队进行更多的初始和进度审查)
- 防止跨三个产品的一个非常大的积压(三个产品中有数百个项目)。
- 目前，该设置阻碍了以下需求(至少这些是主要需求):
- 与公司中的其他产品团队保持一致，他们的基本设置是每个产品有一个团队，因此每个产品有一个backlog。
- 跨越多个产品的发布的高级视图(缩减、报告、特性级信息，等等)。
- 产品负责人需要某种形式的理智:)
有人见过这样的东西吗?你能把事情结合到一个合理的过程中吗?关于如何在发布中创建更高级别的视图，以及如何与每个产品使用一个backlog的其他产品团队保持一致，您有什么想法吗?我已经绞尽脑汁想办法解决这个问题了。我有一个指令，以确保我的团队和公司其他产品团队之间的一致性。我不知道该怎么做。
非常感谢你能提供的任何建议!
——乔恩
我还应该指出，对于三个不同的敏捷团队，我们有三套sprint计划/评估/评审/回溯。
在Scrum中，每个单独的产品都应该有一个产品待办事项列表，每个产品待办事项列表都有一个明确的产品负责人。可以有多个开发团队从相同的产品Backlog中抽取工作，并且他们将计划自己的Sprint Backlog，这将导致每个Sprint都有一个集成的和可发布的产品增量。
-你指的“团队积压”是什么?
-为什么人们希望将原本是分开的产品和产品backlog之间的工作或工作流结合起来?
-为什么发布跨越多个产品?
都是很好的有效的观点/问题。这就是我目前的困境。
在Scrum中，每个单独的产品都应该有一个产品待办事项列表，每个产品待办事项列表都有一个明确的产品负责人。
- 那就是我，这三种产品。
-你指的“团队积压”是什么?
- 实际上，我们在Jira中有3个额外的项目，每个团队一个。这是对Jira中的Product项目的补充。团队故事实际上会链接回项目中的bug /改进/新特性。
-为什么人们希望将原本是分开的产品和产品backlog之间的工作或工作流结合起来?-为什么发布跨越多个产品?
- 我们的系统由三个主要组件组成，每个组件都被定义为自己的产品:
- 配置工具
- 一个中央处理/执行/等应用程序
- 驻留在分布在大地理位置上的各种硬件元素上的软件
- 我们有三个团队可以在这三个组件上工作，但是每个组件在给定的sprint期间可能没有工作(sprint为所有三个产品排列)，所以我们不能为每个组件分配一个团队。有时，为了创建新特性，工作必须跨多个组件完成(或者bug可能跨组件)。我们处于这样一种情况:“产品”(组件)不是完全不同，也不是完全统一。我们有三支队伍，因为如果加在一起，人数会非常多。
- 一个新的特性或错误是专门给一个特定的团队的，他们在一个或多个sprint中处理跨三个组件的所有工作。
我的主要挑战，我正在寻找解决的问题，是消除团队的Jira项目和相关的积压，并仅从Product项目(积压)中工作。挑战是在这样做的同时保持当前的跨团队/跨产品工作流，而不为每个PBI创建大量的开销、复杂性或20个交叉链接。
嗨,约翰,
给你们的谈话加点料，也许会有别的转折。伊恩，也许你也接触过这个。
我们有一个场景，在一个功能产品领域，我们有4个应用程序，不同的技术(考虑接近生命周期/遗产)。现在我们有2个scrum团队，每个团队负责2个应用程序，他们都有自己的backlog和产品负责人。所有应用程序的积压/资金正在减少，如果没有不同的技术，一个scrum团队可以支持所有4个应用程序。寻找其他组织如何处理这一问题的模型或例子。
假设具备这些技能，单个开发团队可以通过1周的轮番冲刺来支持4个产品。每个sprint将为不同的产品提供服务，因此每个产品将每月为不同的产品负责人工作一次。在每种情况下，提供这样的服务可能是Sprint目标。
谢谢你伊恩。
这是我们的挑战，假设:)每个应用程序都有不同的代码库(c++、Java、PLSQL等)，所以技能集如此多样，我还没有见过一个由1或2人组成的scrum团队的模型，但我也没有见过一个由1个完整的scrum团队支持3或4种技术的模型。不确定它是否存在。
嘿，约翰，你想好解决办法了吗?我有一个客户也有类似的问题，我想看看你的帖子，同时寻找有关他们如何解决问题的信息，以及是否有人以前这样做过。
关于Jira的一些重要注意事项:
(1)在项目中创建问题
(2)板是基于查询构建的，因此可以显示来自多个项目的问题
(3)报告(燃尽图等)是基于板的
(4)将工作流应用到项目中
(5)同一项目中的不同问题类型可以有不同的工作流程
您可以在其他项目上重用相同的工作流(不需要重新创建它)
我建议为所有问题添加一个名为“team”的自定义字段，该字段将有三个团队的下拉列表。然后，您可以通过基于该字段的查询筛选问题，为每个团队创建一个公告板。因此，每个团队将有一个单独的板，在那里他们可以管理工作。
请注意，如果您没有编辑查询的权限以使其他人能够看到它，那么只有您能够看到由该查询生成的板子。
听起来，您可能还想编辑工作流方案，以便特性(或层次结构中更高层次的其他东西)使用需要额外检查检查点的工作流，而这些检查点不在层次结构中较低层次的问题的工作流中。
(PS.我知道这个回复对于已经在这个帖子上的人来说太迟了，但也许它会帮助到一些新的人。)
你好@约翰@布兰登，
我很想知道你是如何解决最初的问题的
(1)多个小型scrum团队(每个团队最多1到4个开发人员)。
(2)每个scrum团队有不同的产品愿景
在只有1个或2个开发人员的scrum团队中，使用SM或PO是否有效?对于小型scrum团队来说，哪种敏捷方法是最好的?