科技债务的点数是否应该用团队的速度来计算？

Question

科技债务并没有直接的商业价值，直到与其他更快交付的故事相比，这些改进才能显现出来。从长远来看，实现或失败的sprint也会影响士气和交付，因此，如果必要的话，技术债务会导致sprint失败或速度下降。

虽然对每个组织来说，速度是不同的，但对于团队还是对业务来说，速度是一个衡量标准，是“纯”的技术债务，没有业务影响可以用团队的速度来衡量吗？

Answer 1

速度被定义为“在一定时间间隔内完成的工作单位数”。要实现一个工作单元，您通常有一个软件的现有部分，并添加一些新代码和/或更改一些现有代码。当软件的现有部分包含了大量的技术债务，并且您必须处理它以实现更改时，您可能需要更多的时间来完成一个工作单元。另一方面，新的技术债务的产生往往是为了在当前的冲刺中减少完成一项工作所需的时间。

因此，这里的度量标准始终取决于团队和实际的代码基础(可能还取决于周围的整个组织)。没有什么比绝对“团队的速度”更好的了。

但是，如果您的问题是，是否应该有只处理技术债务的工作单元，如果它们应该被计算为与业务需求的工作单元相同的方法，那么很明显，将这两种工作混合在一起可能会给您对团队实际开发速度的错误理解。事实上，如果你想衡量你的团队工作的速度，或者你的团队能以多快的速度交付新的业务价值，你必须自己决定。根据我的经验，大多数客户更愿意为他们获得的商业价值付费。

Answer 2

一种看待速度的方法是把它看作是“在给定的时间内可以完成的工作量”。假设修复技术债务是实际工作，就应该计算在内。

你必须记住，速度只是帮助你更好地工作的工具。如果增加技术债务对你的速度有帮助，那就去做吧。如果没有，就不要。跟踪速度S的唯一原因是帮助你更好地计划。如果你忽略了你实际做的工作，那对IMHO没有帮助。

Answer 3

我要说的是，不要以你的速度来计算技术债务。然而，作为一名开发人员，不像一个缺乏经验的经理，您知道，这意味着您可以任意地完成或多或少的工作，这取决于您增加或删除的债务。所以在你的计划中要考虑到这一点。

如果你的软件处于糟糕的状态，需要每周两天来处理下一年的技术债务，或者如果你有一个混乱的开发人员以巨大的速度创造债务，那么考虑到这一点，你的速度就会下降。