假设需要重构（太大而无法合并为现有用户故事的一部分） - 在产品待办事项列表中包含重构“故事”是否可以？
重构的目的不是改变系统的行为——所以根据定义，没有直接的商业价值给客户。
——那么重构“故事”是否有故事点，然后计入速度，或者这是否在某种程度上作弊？
背景：我们做了一个最初的故事，以最简单的结构存储一些数据。此数据的结构不适用于即将到来的用户故事，并且需要不同的方法，所有期望现有数据结构的现有功能都需要更改以适应这种新方法。
问问题
1518 次
3 回答
8
在我看来，在您的产品待办列表中包含此类项目绝对没问题，因为我一直认为 PB 是完成软件所需要做的一切。
我之前经常在产品待办列表中完成功能、错误修复、重构和研究任务。如果您不将其放入积压工作中，那么该任务将/如何完成？您还需要为任务定义“完成”，这有助于描述重构的目标（使代码运行得更快，使代码更易于测试等）。
于 2013-05-30T13:48:51.807 回答
1
我已经看到不同团队以多种方式解决了这个问题。
1）技术债务项目（如重构）作为故事添加到产品积压中，用户类型为“开发人员”，业务价值表示为直接成本或投资回报率。
这样做的好处是使包括客户在内的每个人都可以看到技术债务项目（及其业务价值/存在的原因）。它还使包括必要技术工作在内的速度得到考虑和可见。
但是，它们可能对每个人都过于技术性而无法理解，并且可能会浪费时间来解释和协商这些项目。对每个人来说，商业价值可能并不明显或无法解释，尤其是那些专注于功能的人。
2) 为技术债务问题预留一个“特殊”冲刺。
这些在与产品待办事项完全分开的技术待办事项上进行跟踪。这消除了团队为他们提出理由、推动将技术债务项目添加到基于业务价值的积压中或将这些问题强制转换为用户故事形式的需要。
缺点：社区中有些人反对任何一种特殊的迭代。它还要求客户（和每个人）接受“暗”迭代对生产力的影响，其中没有明显的进展（和速度）。
3) 将技术债务所需的时间汇总到故事中。
这允许团队只承诺那些可以在不产生技术债务的情况下完成的项目。因此，故事点和速度将包括重构之类的东西。
我看到的最大缺点是它意味着故事应该在没有技术债务的情况下完成......这似乎违反了只做足够完成一个项目的原则。
于 2013-06-19T01:02:02.823 回答
1
这个问题有点过时了，但主题本身不是，所以我会冒险回答。
我的看法是：不，在计算速度时不应考虑作为单独活动进行的重构，因为它不会带来业务价值，也不会提供可用的增量。
此数据的结构不适用于即将到来的用户故事，需要采用不同的方法
然后我会分别定义和估计“即将到来的用户故事”。
于 2015-07-17T09:42:02.343 回答