“重构”产品积压项目是否应计入速度？

Question

假设需要重构（太大而不能作为现有用户故事的一部分合并） - 在产品Backlog上有重构'故事'是否可以？

重构的目的不是改变系统的行为 - 因此根据定义，不会给客户带来直接的商业价值。

- 那么重构'故事'的故事点是否会计入速度，还是会以某种方式作弊？

上下文： 我们做了一个初始故事，以最简单的结构存储一些数据。这些数据的结构不适用于即将发布的用户故事，需要采用不同的方法，所有现有的功能都需要更改，以适应这种新方法。

Answer 1

在我看来，在产品Backlog中有这样的项目是绝对正常的，因为我总是把PB作为完成软件所需的一切。

我之前经常在产品Backlog中有功能，错误修复，重构和研究任务。如果你没有把它放在积压的话，这个任务怎么可能完成？您还希望为任务定义“完成”，这有助于描述重构的目标（使代码更快，使代码更具可测性等）。

Answer 2

我看到不同的团队以不同的方式解决了这个问题。

1）技术债务项目（如重构）作为故事添加到产品待办事项中，用户类型为“开发人员”，业务价值表示为直接成本或ROI。

这具有使每个人（包括客户）都能看到技术债务项目（及其商业价值/存在理由）的优势。它还使得包括必要技术工作在内的速度得到了解释和可见。

然而，它们可能过于技术化而无法让每个人理解，并且可能浪费时间来解释和协商这些项目。对于每个人来说，商业价值可能都不明显或不易解释，尤其是那些以特色为中心的人。

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

这些跟踪在技术积压上，与产品积压完全分开。这样就无需团队为他们提供案例，推动将技术债务项目添加到基于业务价值的积压工作中，或者将这些问题强制转换为用户故事形式。

缺点：社区中有一些人反对任何特殊的迭代。它还要求客户（和每个人）接受“黑暗”迭代的生产力命中，其中没有可见的进展（和速度）。

3）将技术债务所需的时间用于报道。

这允许团队只承诺那些可以在不产生技术债务的情况下完成的项目。因此，故事点和速度将包括重构等内容。

我看到的最大缺点是它暗示故事应该在没有技术债务的情况下完成......这似乎违反了只做足以完成一项的原则。

Answer 3

这个问题有点过时，但话题本身并不存在，所以我会冒回答。

我对它的看法是：不，在计算速度时不应考虑作为单独活动完成的重构，因为它不会带来商业价值并且不能提供可用的增量。 / p>

  

此数据的结构不适用于即将发布的用户故事，需要采用不同的方法

然后我分别定义和估计即将到来的用户故事＆＃34;。