Scrum:由非技术PO管理的积压工作中的技术项目？

Question

诸如“将服务器从v1升级到v2”或“提高启动性能”或“重构登录模块以降低代码复杂性”之类的技术项目是否应该加入到产品积压中，如果是这样的话，非技术产品所有者应该如何确定它们与其他功能更多的积压项目的优先顺序？

技术资料是否应该有单独的待办事项？我们是否应该与两个人共同担任PO角色，以便优先处理产品待办事项中的功能和技术方面的内容？

Answer 1

我已经成功地使用了dual backlog方法：

1. 产品待办事项清单归产品所有者所有。它包含故事级的项目(功能)，这些项目由团队评估，然后由产品所有者确定优先级。这个评估过程将故事分成较小的任务。
2. 团队积压工作归开发团队所有。它包含相对较小的任务级项目(可以在一次冲刺中完成)。它们可以链接到故事，例如作为障碍:要完成故事，必须首先完成以下技术任务。它们也可以是独立的，因此任何故事本身都不需要它们，但它们偿还了一些技术债务，以在未来实现更高的速度。

(在一些大型的、多项目的项目中，我也有计划积压，其中包含史诗级别的项目，由计划管理团队拥有和优先考虑，并进一步拆分成产品积压的故事。)

Answer 2

通常在“香草”SCRUM中，你提到的技术任务不会作为单独的故事。

对我来说，非技术性的PO不应该关注像“升级服务器”这样的故事。这不是一个商业故事，它对最终用户是不可见的，所以如果它是以这种方式制定的，那么很难确定优先级。优先级应该根据工作的业务价值进行分配。“升级”并不意味着什么。“允许更多的同时连接”，“减少停机时间”，甚至“提高团队速度”可能会为非技术人员提供更有价值的见解。如果您找不到非技术描述，请问自己一个关于升级必要性的问题:)

“重构”的故事甚至更加复杂。你有没有问过自己，为什么这是一个故事？重构可以作为故事中的一项任务来完成，但它本身很少是一个故事。因此，如果您想让登录更好地工作或提供更多功能，这是一个故事，但在幕后修修补补并不算一个。还请注意，没有商业目的的重构很容易导致所谓的“镀金”。

我建议将“升级”故事作为一个突破口，将“提高性能”和“重构”作为相关业务故事的任务。

附注:你可能会在Mike Cohn的一本名为"User Stories Applied: For Agile Software Development“的优秀书籍中找到关于这个主题的很好的讨论(主要在第三部分)。

Answer 3

我同意这样的观点，即查看任何技术故事的业务收益，并在主要产品积压中跟踪它。

我确实认为有一些与团队的速度/能力相关的内部故事，有时通过向开发人员分配一些能力来更方便地管理这些故事，特别是当产品负责人对这些故事不感兴趣的时候。例如，将10%的容量分配给测试自动化积压(遗留回归)、CI服务器设置等。

是的，一切都可以用业务术语来表达，但其中一些应该被认为是“我们完成工作所需的方式”，产品负责人和团队之间相互信任，团队将最大限度地利用为此分配的能力。