Per*_*eng 12 agile scrum development-process extreme-programming backlog
如果"将服务器从v1升级到v2"或"提高启动性能"或"重构登录模块以降低代码复杂性"等技术项目应该进入产品待办事项,如果是,那么非技术产品所有者应该如何确定它们的优先级与其他更实用的积压项目？
是否应该单独积压技术资料？我们是否应该与两个人共同发挥PO作用,可以优先考虑产品积压的功能和技术内容？
Ily*_*tov 11
通常在'vanilla'SCRUM中,您提到的技术任务不会像单独的故事那样.
对我来说,非技术PO不应该关注"升级服务器"这样的故事.这不是一个商业故事,最终用户看不到它,因此如果以这种方式制定,很难确定优先顺序.应根据工作的商业价值分配优先顺序."升级"并不意味着什么."允许更多同时连接","减少停机时间"甚至"提高团队速度"可能会为非技术人员提供更有价值的洞察力.如果您找不到非技术性描述,请问自己有关升级必要性的问题:)
"重构"的故事更加复杂.你问自己为什么这是一个故事？重构可以作为故事中的任务完成,但它本身很少是一个故事.因此,如果您想让登录工作更好或提供更多功能,这是一个故事,但在引擎盖下修补不算一个.还请注意,没有商业目的的重构很容易导致所谓的"镀金"
我建议将"升级"故事作为一个尖峰,"改善表现"和"重新考虑因素"是相关商业故事的任务.
PS你可能会在Mike Cohn出版的一本名为" 用户故事应用:敏捷软件开发 " 的优秀书中找到关于这个主题的讨论(主要是第3部分).
我通过双重待办事项方法取得了成功：
产品待办事项列表归产品负责人所有。它包含故事级别的项目（功能），由团队评估，然后由产品负责人确定优先级。这个估计过程将故事分成更小的任务。
团队积压工作归开发团队所有。它包含相对较小的任务级项目（可以在一个冲刺内完成）。它们可以与故事相关联，例如作为障碍：要完成故事，必须首先完成以下技术任务。它们也可以是独立的，因此任何故事本身都不需要它们，但它们偿还了一些技术债务，以在未来实现更高的速度。
（在一些大型的多项目计划中，我还拥有包含史诗级项目的计划待办事项，由项目管理团队拥有并确定优先级，以便进一步将故事拆分为产品待办事项。）