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

诸如“将服务器从v1升级到v2”或“提高启动性能”或“重构登录模块以降低代码复杂性”之类的技术项目是否应纳入产品待办事项列表中？如果是，非技术产品所有者应如何与其他更具功能性的待办事项列表项目相比，对其进行优先排序

---

是否应该有一个单独的技术工作积压？我们是否应该与两个人共同担任采购订单角色，以便对产品积压工作中的功能和技术内容进行优先排序？

我成功地采用了双重积压工作方法：

产品积压工作由产品所有者拥有。它包含由团队估算的故事级项目（功能），然后由产品所有者确定优先级。此评估过程将故事拆分为更小的任务

团队积压工作由开发团队拥有。它包含相对较小的任务级项目（可以在sprint中完成）。例如，它们可以作为障碍链接到故事：要完成故事，必须首先完成以下技术任务。它们也可以是独立的，因此任何故事本身都不需要它们，但它们会偿还一些技术债务，以便在未来实现更高的速度

---

（在一些大型、多项目项目的项目中，我也有包含史诗级项目的项目积压，这些项目由项目管理团队拥有并确定优先级，将进一步分解为故事和产品积压。）

通常在“普通”SCRUM中，您提到的技术任务不会作为单独的故事

对我来说，非技术PO不应该关注“升级服务器”之类的故事。这不是一个商业故事，最终用户看不到它，因此如果以这种方式制定，则很难确定优先级。应根据工作的商业价值来分配优先级。”升级“意义不大”允许更多同步连接、“减少停机时间”甚至“提高团队速度”可能会为非技术人员提供更有价值的见解。如果找不到非技术性说明，请询问自己升级的必要性：）

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

我建议将“升级”故事作为一个尖峰，“提高性能”和“重新考虑”作为相关业务故事的任务

---

另外，你可能会在Mike Cohn写的一本名为“.”的优秀著作中找到关于这个主题的一个很好的讨论（主要在第3部分）

我同意这样的观点，即查看任何技术故事的商业利益，并在主要产品待办事项中跟踪它

我确实认为有一些与团队的速度/能力相关的内部故事，通过向开发人员分配一些能力，有时可以更方便地管理这些故事，特别是当产品所有者不想优先考虑或管理这些故事时。 例如，将10%的容量分配给测试自动化积压（遗留回归）、CI服务器设置等

---

是的，一切都可以用商业术语来表达，但其中一些应该被视为“我们需要的工作方式”，产品所有者和团队之间相互信任，团队将充分利用为此分配的能力

恕我直言，双重积压做法不是一个好做法。团队更应该尝试用业务术语表达技术故事，展示它们提供的业务价值，解释它们如何影响团队速度。通过这种方式，PO将能够像任何其他故事一样对它们进行优先级排序。我认为有多个积压工作会使项目或sprint管理成为一场噩梦。我认为这是一种反模式。不止一个积压工作会让产品所有者和开发团队产生冲突。如果双方都有信任，那么这就不是问题。如果不信任，你会遇到更大的问题。每个环境/团队都不同；真的没有规则。要做的一系列改进可以帮助开发人员摆脱这些想法。在规划过程中，这些项目可以“转化为”用户情景的估算。更大的项目可以重新组织成用户故事，但随着价值的清晰映射，它的“所以”才是重要的；这样页面加载更快+链接到页面加载/销售影响研究。你能给我举个例子吗？例如，我如何用商业术语解释“使代码生成工具为当前项目做好准备”？有些任务不能在您提到的两个组中进行分类。有些任务是预先需要的任务，如：准备好代码生成、培训团队成员、准备好日志记录基础设施、准备好基本开发基础设施、将项目分成3个不同的项目以更好地控制它……如何应对它们？