问“重构”产品待办事项是否应该计入速度？

EN

在我看来，在你的产品积压中有这样的项目是绝对好的，因为我一直认为PB是软件完成所需要做的一切。

我以前经常在Product Backlog中有特性、bug修复、重构和研究任务。如果你不把它放在待办事项表中，那任务还能怎么完成呢？您还需要为任务定义“完成”，这有助于描述重构的目标(使代码运行更快，使代码更易于测试，等等)。

我已经看到不同团队以几种方式解决了这个问题。

1)技术债务项(如重构)作为故事添加到产品待办事项列表中，用户类型为“开发人员”，业务价值表示为直接成本或投资回报率。

这样做的好处是使技术债务项(以及它们的业务价值/存在原因)对每个人都可见，包括客户。它还使速度包括必要的技术工作被考虑和可见。

但是，它们可能太过技术性，每个人都无法理解，并且可能会浪费时间来解释和协商这些项目。业务价值可能不会对每个人都是显而易见或可解释的，特别是那些专注于功能的人。

2)为技术债务问题预留一个“特殊”冲刺。

这些都是在与产品待办事项完全分开的技术待办事项清单上进行跟踪的。这就消除了团队为他们做案例的需要，消除了将技术债务项添加到基于业务价值的积压中的需要，或者消除了将这些问题强制纳入用户故事形式的需要。

缺点:社区中有一些人反对任何一种特殊的迭代。它还要求客户(和每个人)接受“黑暗”迭代的生产力打击，在这种迭代中，没有明显的进展(和速度)。

3)将技术债务所需的时间汇总到故事中。

这允许团队只承诺那些可以在不招致技术债务的情况下完成的项目。故事点和速度因此将包括重构之类的东西。

我看到的最大的缺点是，它意味着故事应该在没有技术debt...which的情况下完成，这似乎违反了只做足够的工作来完成一个项目的原则。

这个问题有点过时了，但这个话题本身并不过时，所以我冒险给出一个答案。

我对此的看法是:不，在计算速度时，不应将重构作为单独的活动考虑在内，因为它不会带来业务价值，也不会带来可用的增量。

此数据的结构不适用于即将到来的用户情景，需要一种不同的方法

然后，我会分别定义和估计“即将到来的用户故事”。