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

Question

“将服务器从 v1 升级到 v2”或“提高启动性能”或“重构登录模块以降低代码复杂性”等技术项目是否应该进入产品待办事项列表中，如果是这样，非技术产品所有者应该如何确定它们的优先级与其他更具功能性的积压项目相比？

技术方面是否应该有单独的积压工作？我们是否应该与两个人一起担任联合 PO 角色，以优先考虑产品待办事项中的功能和技术内容？

Answer 1

我通过双重待办事项方法取得了成功：

1. 产品待办事项列表归产品负责人所有。它包含故事级别的项目（功能），由团队评估，然后由产品负责人确定优先级。这个估计过程将故事分成更小的任务。

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

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

Answer 2

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

要我非技术PO不应该看着像“升级服务器”的故事。这不是一个商业故事，所以很难若配制这种方式优先考虑它是不是给最终用户可见。重点应根据工作的商业价值进行分配。 “升级”没有太大意义。 “允许更多的并发连接”，“减少停机时间”甚至“提高团队的速度”可能会提供更有价值的见解的非技术人员。如果你不能找到一个非技术性的说明问自己有关升级的必要性问题：）

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

我建议做了“升级”的故事为与“提高性能”和“重因子”是任务相关的商业故事激增。

P.S。你可能会在优秀的书由迈克·科恩称“的用户故事申请：对于敏捷软件开发”

。

Answer 3

我同意看待任何技术故事的商业利益和跟踪它的主要产品积压的看法

我不认为有涉及到球队的速度/容量的内部故事，有时更方便地通过分配有一定能力的开发管理，特别是当产品负责人不感兴趣优先或管理这些故事。 例如。 10％的容量分配给测试自动化积压（遗留回归），CI服务器设置等

是的，一切当然可以用商业术语表达，但它的一些应该被认为那里是产品所有者和团队，该团队将容量得到最佳利用之间的信任“我们需要做我们的工作方式”分配这一点。