在TFS中，您在哪里记录技术债务？

我想找到一种方法来记录我们在TFS中产生的技术债务

我需要记录特定迭代之外的每个项目，以确保它始终可见并易于报告。我已经考虑过为技术债务创建一个单独的领域，但不确定该领域实际上有多适合

---

什么是我可能考虑的常见方法？我是不是想找一个合适的地方把它放在一棵合适的树上？

我没有发现需要单独跟踪它；我只是将其作为附加任务输入。通过这种方式，它们可以很容易地被跟踪和报告。

我发现有几种类型的技术债务：您知道并可以跟踪到修复的债务，以及由于意外错误而变得明显的债务。我喜欢在一个单独的迭代中跟踪未偿还的已知技术债务，我称之为“维护积压”，在“技术债务”区域下。然后，我可以将任何迭代中的相关bug链接到技术债务领域，同时仍然跟踪我还不能解决的问题。关键是您仍然需要与迭代相关的bug，这些bug被发现、修复并链接到原始需求，以用于报告等目的。

我不知道如何做到这一点，但这是一个很好的问题。您应该像跟踪需求一样跟踪技术债务，这是非常合理的。我看到的问题是确定债务。如果你能准确地识别它，那么你可以做一个工作项目来支付它。TFS＝= Team Foundation Server？如果你定义首字母缩写词，它会有帮助。抱歉-是的TFS＝= = Team Foundation Server。我试着在标签之间标记它，但它们在SO中不受支持。谢谢。这是我很好奇的方法。但是你觉得它很好用吗？是否有其他人/企业以这种方式经营？您的“技术债务”区域和“维护积压”迭代是否都处于各自层次结构的顶层？它工作得很好，因为团队可以采取主动的方法，记录技术债务，即使他们无法在当前迭代中修复它。我还可以很容易地报告每个周期有多少未预料到的工作是由于技术债务等。我们地区还有一家公司（200多名开发人员）使用类似的方法。我不能代表更广泛的社区发言，但它似乎按照它的意图利用了TFS。但是您是否仍然需要将任务与特定的迭代关联起来？您是否发现这种方法干净且易于管理？对于可能跨越几次迭代的任务，您会做些什么？我像管理其他任务一样管理它——因此，是的，我发现它干净且易于管理。我还没有发现把“技术债务”作为一个单独的领域来解决是有用的；归根结底，这实际上归结于在现有领域开展更多的工作。有时任务在当前迭代中执行；有时在另一个世界。与所有任务一样，有时随着迭代的结束，它们可能会从当前迭代推迟到下一个迭代。对于可以跨越多个迭代的任务，我通常只是将它们分解为多个任务（即使是像“阶段1”和“阶段2”这样简单的任务通常也能很好地工作）。我喜欢你关于任何技术债务最终都会在项目的现有特性或领域中产生“根本原因”的观点。这一点很好。@RickNZ但是您有任务/用户故事的功能吗？或者只是任务的用户故事？