您在 TFS 中的何处记录技术债务？答案

【问题标题】：Where do you record Technical Debt in TFS?您在 TFS 中的何处记录技术债务？
【发布时间】：2009-12-21 01:15:15
【问题描述】：

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

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

我可能会考虑哪些常用方法？我什至试图找到一个合适的地方来放置它，从而找到正确的树吗？

【问题讨论】：

我不知道该怎么做，但这是一个很好的问题。您应该像跟踪需求一样跟踪技术债务，这是非常有意义的。我看到的问题是识别债务。如果您能准确识别它，那么您可以制作一个工作项来偿还它。
TFS == Team Foundation Server？如果您定义首字母缩写词会有所帮助。
抱歉 - 是的 TFS === Team Foundation Server。我试图在标记之间标记它，但 SO 不支持它们。

标签： tfs technical-debt

【解决方案1】：

我还没有发现需要单独跟踪它；我只是将其作为附加任务输入。这样，就可以轻松跟踪和报告它们。

【讨论】：

但是您还不需要将任务与特定迭代关联吗？您是否发现这种方法干净且易于管理？对于可能跨越几次迭代的任务，您会怎么做？
我像其他任何任务一样管理它——所以是的，我觉得它干净且易于管理。我还没有发现将“技术债务”作为一个单独的领域分开是有用的。最后，它真的归结为在现有领域的更多工作。有时任务进入当前迭代；有时在另一个。与所有任务一样，有时随着迭代结束，它们可能会从当前迭代推迟到下一次迭代。对于可以跨越迭代的任务，我通常只是将它们分解为多个任务（即使像“阶段 1”和“阶段 2”这样简单的任务通常也可以正常工作）。
我喜欢你的观点，即任何技术债务最终都会在项目的现有功能或区域中产生“根本原因”。好点子。
@RickNZ 但是您有针对任务/用户故事的功能吗？还是只是与任务相关的用户故事？

【解决方案2】：

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

【讨论】：

谢谢。这是我很好奇的一种方法。但是你觉得效果好吗？是否有其他人/企业以这种方式经营？您的“技术债务”区域和“维护积压”迭代是否都位于各自层次结构的顶层？
它运作良好，因为团队可以采取积极主动的方法，随时记录技术债务，即使他们无法在当前迭代中修复它。我还可以轻松地报告每个周期有多少意外工作是由于技术债务等造成的。我们所在地区的另一家公司（200 多名开发人员）使用了类似的方法。我不能代表更广泛的社区，但它似乎按照预期利用了 TFS。

【解决方案3】：

对于它的价值，我将我的 2 美分加上一个当代旋转 - 在 Azure DevOps（TFS 的继任者）的积压工作中捕获技术债务工作项的最佳实践。

1.使用标签
使用tech debt 标签标记此类工单以指示对客户的隐含价值总是很方便（例如，平衡冲刺中此类任务的百分比）。

2。避免技术债务功能
避免使用技术债务功能的原因有 3 个：

跟踪目的。
epic 或功能需要明确定义的目标才能实现，因此可以在某个时间点将其从列表中划掉以反映进度。重构或与技术债务相关的任务是一个永无止境的过程，因此将它们置于功能之下会使跟踪进度毫无意义。
违反单亲规则。
使用单亲功能单亲和单亲
em>epic 用于功能。可能有例外，但应该很少见。有多位家长在门票上将难以跟踪进度。
技术债任务可能属于“真实”功能。
如果 技术债务 任务的子集有助于更快地完成正在进行的或未来的功能/史诗，那么将这些工单保留在该功能/史诗下是有意义的.将其与相应的标签结合起来以防万一。当然，稍后当时间用完时，您可能会放弃这些技术债务任务。

3。没有功能的任务不是犯罪
如果您可以像这样管理任务，则任务并不总是需要功能。 Azure DevOps 提供了大量工具（例如查询票证）来查找和管理您想要的内容。

做对团队和您的项目有意义的事情，而不是“打勾”。

【讨论】：