Scrum：由非技术 PO 管理的待办事项中的技术项目？ [关闭]

Posted 2023-02-25

【中文标题】Scrum：由非技术 PO 管理的待办事项中的技术项目？ [关闭]

【英文标题】：Scrum: Technical items in a backlog that is managed by a non technical PO? [closed]

【发布时间】：2010-11-25 05:35:47

【问题描述】：

是否应该将诸如“将服务器从 v1 升级到 v2”或“提高启动性能”或“重构登录模块以降低代码复杂性”等技术项目列入产品待办事项列表，如果是，非技术产品所有者应该如何能够将它们优先于其他功能更强大的待办事项？

是否应该有单独的积压的技术资料？我们是否应该与两个人共同担任 PO 角色，以便在产品待办列表中优先考虑功能和技术方面的内容？

【参考方案1】：

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

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

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

【讨论】：

你能举个例子吗？例如，如何用商业术语解释“为当前项目准备代码生成工具”？

【参考方案2】：

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

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

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

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

附：您可能会在 Mike Cohn 的名为“User Stories Applied: For Agile Software Development”的优秀著作中找到关于这个主题的很好的讨论（主要是在它的第 3 部分）。

【讨论】：

有些任务不能归入你提到的两个组。有些任务是预先需要的任务，例如：准备好代码生成、培训团队成员、制作日志基础设施、准备好基本的开发基础设施、将项目分成 3 个不同的项目以便对其进行更多控制……如何遇到它们？

【参考方案3】：

我在双重积压方法上取得了成功：

产品待办事项归产品所有者所有。它包含故事级别的项目（功能），这些项目由团队估计，然后由产品所有者确定优先级。此估算过程将故事拆分为较小的任务。

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

（在一些大型的多项目计划中，我也有包含史诗级项目的计划待办事项，由计划管理团队拥有并确定优先级，以便进一步拆分为故事到产品待办事项中。）

【讨论】：

恕我直言，双重积压方法不是一个好习惯。团队更应该尝试用商业术语来表达技术故事，展示它们提供的商业价值，解释它们如何影响团队速度。这样，PO 将能够像其他故事一样对它们进行优先排序。

我认为有多个待办事项会使项目或 sprint 管理成为一场噩梦。我认为这是一种反模式。

多个积压工作会使产品负责人和开发团队陷入冲突。如果双方之间有信任，那么这不是问题。如果没有信任，你就有更大的问题。

每个设置/团队都不同；没有规则，真的。要进行的改进列表可以帮助开发人员摆脱困境。在规划期间，这些项目可以“工作”为用户故事的估计。较大的项目可以重新构建为用户故事，但价值明确映射，它的“所以”很重要；以便页面加载更快 + 链接到页面加载/销售影响研究。