12

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

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

4

3 回答 3

11

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

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

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

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

PS 你可能会在 Mike Cohn 的名为“应用用户故事：敏捷软件开发”的优秀著作中找到关于这个主题的很好的讨论（主要是在它的第 3 部分）。

于 2009-09-03T11:01:59.900 回答
2

I agree with the view of looking at the business benefit of any technical story and tracking it on the main product backlog

I do think that there are internal stories related to the velocity/capability of the team, which are sometimes more conveniently managed by assigning some capacity to the developers, especially when the Product Owner is not interested to prioritize or manage those stories. E.g. assign 10% capacity to test automation backlog (of legacy regression), CI server setup, etc.

Yes, everything can certainly be expressed in business terms, but some of it should be considered "the way we need to do our job" where there is trust between Product Owner and team that the team will make best use of the capacity assigned for this.

于 2009-09-18T01:43:51.347 回答
0

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

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

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

（在一些大型的、多项目的项目中，我也有包含史诗级项目的项目积压，由项目管理团队拥有并优先考虑，以进一步拆分为故事到产品积压。）

于 2009-09-03T09:35:28.813 回答