我在Pivotal Tracker板上添加了一些解决一些技术问题的用户案例。我应该将它们视为特征（保持速度水平）还是杂务/虫子（降低速度）？我知道，如果我坚持一贯做下去，从长远来看不会有任何区别，但是每次我添加技术债务的故事时，我都必须做出决定。

一些想法：

• 它们实际上不是错误，它们不会破坏任何东西
• 用户没有要求任何东西，因为它是不影响他们的低级实施，但是它将使长期开发变得更容易
• 如果您将功能定义为能够为用户增加价值的故事，那么a）他们不会，因为用户不会看到任何直接的利益，但是b）它们会这样做，因为它们使将来的开发/维护成为可能，从而确实可以增加价值，只是现在不行

我不决定是否真正进行这项工作，或何时安排它，我只是想知道我应该在项目管理工具中称其为技术债务的原因，以及原因。

这是一个功能。

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

像任何其他功能一样定义，计划和跟踪它。

如果实现此功能（对于客户或您而言）对于计划的时间而言还不够有价值，那就是另一个问题。

（偿还）技术债务不是一项功能，因为客户没有资格对此做出决定。最重要的是，客户无法决定何时完成，此外，客户完全依赖您来解释收益。您的判断是存在技术债务，并且应由您决定如何解决问题以及何时完成。技术债务会影响您（未来）的速度，而不是客户对软件的看法。如果没有债务，您将提高生产力。到目前为止，您一直在测量的速度是错误的，因为您应该花更多的时间来保持代码的形状。

我确实认为您应该与您的客户进行沟通，但这并不是他们的控制范围。您可以这样说：“到目前为止，我们已经采取了一些捷径，我们必须解决这些捷径。这意味着在接下来的几次迭代中，我们的速度将有所下降，但这是为了确保长期以来我们拥有可维护的软件。

继续进行客户功能的开发也将有助于您始终专注于为客户改进软件，而不是成为寻找完美设计的某种学术练习（这是我个人有时会遇到的问题）。

恕我直言，消除技术债务的任务绝对不是一项功能。可以将其铲入“ bug”部门，但是它将扩展术语的定义，因为它不会导致用户可以观察到的行为更改。

我将其称为维护任务。在任何开发项目中，都有许多这样的任务，例如，设置开发/测试环境，组装测试数据，在SCM中合并分支等。这些都不是用户直接观察到的，但是如果不能定期执行，则会导致开发工作量增加从长远来看，成本和错误率。

也许没有必要将它们作为单独的任务来处理（除非它们很大，和/或您现在没有实施新功能的压力）。通常，最好只确定何时需要重构/编写单元测试等新功能，并在开发新功能时进行处理。向管理人员和最终用户（如果他们想知道您花费的时间）可能更容易解释。更新：此外，它还帮助开发人员专注于重构的价值。出于重构的考虑，很容易陷入重构，因此，恕我直言，着眼于从客户的角度来看特定重构带来的附加值。

我称之为improvement。

不是错误，因为没有任何问题。

也没有功能，因为重构将不是客户的请求。（因为它有效！）。

improvement默认情况下，大多数跟踪系统都支持问题类型，否则，您可能仍可以更改类型。