是否应该将诸如“将服务器从 v1 升级到 v2”或“提高启动性能”或“重构登录模块以降低代码复杂性”等技术项目列入产品待办事项列表，如果是，非技术产品所有者应该如何能够将它们优先于其他功能更强大的待办事项？
是否应该有单独的积压的技术资料？我们是否应该与两个人共同担任 PO 角色，以便在产品待办列表中优先考虑功能和技术方面的内容？
【问题讨论】：
标签： agile scrum extreme-programming development-process backlog
我同意查看任何技术故事的商业利益并在主要产品待办列表中跟踪它的观点
我确实认为存在与团队的速度/能力相关的内部故事，有时通过为开发人员分配一些能力来更方便地管理这些故事，特别是当产品负责人不感兴趣优先考虑或管理这些故事时。 例如。分配 10% 的容量来测试自动化积压（遗留回归）、CI 服务器设置等。
是的，一切都可以用业务术语来表达，但其中一些应该被认为是“我们完成工作所需的方式”，因为产品负责人和团队之间存在信任，即团队将充分利用能力为此分配的。
【讨论】：
通常在“普通”SCRUM 中，您提到的技术任务不会作为单独的故事进行。
对我来说，非技术 PO 不应该关注诸如“升级服务器”之类的故事。这不是一个商业故事，最终用户看不到它，因此如果以这种方式制定，很难确定优先级。应根据工作的商业价值分配优先级。 “升级”没有多大意义。 “允许更多的同时连接”、“减少停机时间”甚至“提高团队速度”可能会为非技术人员提供更有价值的见解。如果您找不到非技术性描述，请问自己有关升级必要性的问题 :)
“重构”的故事更加复杂。你有没有问过自己为什么这是一个故事？重构可以作为故事中的一项任务来完成，但它本身很少是一个故事。因此，如果您想让登录更好地工作或提供更多功能，那就是一个故事，但在引擎盖下修修补补不算是一个故事。另请注意，没有商业目的的重构很容易导致所谓的“镀金”
我建议将“升级”故事作为一个高峰，将“提高性能”和“重构”作为相关业务故事的任务。
附：您可能会在 Mike Cohn 的名为“User Stories Applied: For Agile Software Development”的优秀著作中找到关于这个主题的很好的讨论（主要是在它的第 3 部分）。
【讨论】：
我在双重积压方法上取得了成功：
产品待办事项归产品所有者所有。它包含故事级别的项目（功能），这些项目由团队估计，然后由产品所有者确定优先级。此估算过程将故事拆分为较小的任务。
团队积压工作归开发团队所有。它包含相对较小的任务级项目（可以在一个 sprint 内完成）。它们可以链接到故事，例如作为障碍：要完成故事，必须首先完成以下技术任务。它们也可以是独立的，因此它们本身不需要任何故事，但它们偿还了一些技术债务以在未来实现更高的速度。
（在一些大型的多项目计划中，我也有包含史诗级项目的计划待办事项，由计划管理团队拥有并确定优先级，以便进一步拆分为故事到产品待办事项中。）
【讨论】：