我希望能找到一种在TFS中记录我们所承担的技术债务的方法。
我需要记录每个项目，无论是否在特定迭代中，以确保它始终可见且易于报告。我考虑创建一个专门用于技术债务的区域，但不确定该领域是否真的适合。
有哪些常见的方法可以考虑？我尝试寻找正确的位置来放置这个问题，这样做是否正确？
你在TFS中如何记录技术债务？
9
- Phil.Wheeler
3
我不确定如何做到这一点，但这是一个很好的问题。像跟踪需求一样跟踪技术债务是完全有道理的。我看到的问题是如何识别债务。如果您能准确地识别它，那么您可以创建一个工作项来偿还它。 - Mark Ewer
TFS == 团队基础架构服务器？定义首字母缩略词有帮助。 - S.Lott
抱歉 - 是的，TFS代表Team Foundation Server。我尝试在<abbr>标签之间标记它，但是它们在SO中不受支持。 - Phil.Wheeler
3个回答
4
我没有发现需要单独跟踪它的必要性；我只是将其作为额外任务输入。这样，它们可以轻松地被跟踪和报告。
- RickNZ
4
但是您仍然需要将任务与特定迭代相关联吗？您认为这种方法清晰易懂且易于管理吗？对于可能跨越几个迭代的任务，您会怎么做？ - Phil.Wheeler
2我像处理其他任务一样来管理它——所以，是的，我发现它很干净、易于管理。我没有发现将“技术债务”作为一个单独的领域很有用；最终，这确实归结为在现有领域中进行更多的工作。有时候任务会在当前迭代中完成；有时候则在另一个迭代中完成。与所有任务一样，有时候它们会被推迟到下一个迭代，因为迭代即将结束。对于可能跨越多个迭代的任务，我通常只是将它们分成多个任务（即使是像“阶段1”和“阶段2”这样简单的划分通常也可以很好地工作）。 - RickNZ
我喜欢你提到的任何技术债最终都有其存在特定功能或项目区域中的“根本原因”的观点。说得好。 - Phil.Wheeler
@RickNZ，您是否拥有任务/用户故事的特性？还是只有带任务的用户故事？ - Issa Fram
4
我发现有几种类型的技术债务: 一种是你知道并能够追踪直到修复的债务, 另一种则是由于意外错误而变得明显的债务。我喜欢将未解决的已知技术债务跟踪在一个称为“维护待办事项”的独立迭代中，该迭代属于“技术债务”领域。然后，我可以将任何迭代中的相关错误链接到技术债务领域，同时仍然跟踪我无法解决的问题。关键是仍然需要将所发现和修复的错误与它们所在的迭代以及原始需求关联起来，以便进行报告等目的。
- PortageMonkey
2
谢谢。这是我感兴趣的一种方法。但是你觉得它有效吗？还有其他人/企业也采用这种方式吗？你的“技术债务”区域和“维护积压”迭代都在各自层次结构的顶层吗？ - Phil.Wheeler
它的工作效果很好，团队可以采取主动的方法，在进行开发的过程中记录技术债务，即使他们不能在当前迭代中解决它。我还可以轻松地报告每个周期因技术债务而产生的未预料到的工作量等等。我们地区还有另一家公司（200多名开发人员）采用了类似的方法。虽然我不能代表更广泛的社区，但它似乎是充分利用了TFS所设计的功能。 - PortageMonkey
0
就我个人而言，我想以现代的方式分享我的经验——在Azure DevOps（TFS的后继者）中记录技术债务工作项的最佳实践。
1. 使用标签
使用tech debt标签标记此类工作项，以指示对客户的隐含价值始终很方便（例如，平衡迭代中此类任务的百分比）。
2. 避免技术债务功能
避免技术债务功能有三个原因：
一个史诗或特性需要有一个明确定义的目标以便实现，这样它就可以在某个时候被划掉清单以反映进展。像重构或技术债务相关任务是永无止境的过程，因此将它们纳入一个特性会使跟踪进度变得毫无意义。
违反单一父级工单规则。
采用单一父级特性和单一父级史诗树状处理工单非常方便。虽然可能存在例外情况，但应该很少见。在工单上拥有多个父级会对跟踪进度造成麻烦。
技术债务任务可能属于“真正的”特性。
如果一部分技术债务任务有助于更快地完成正在进行或未来的特性/史诗，那么将这些工单保留在该特性/史诗下是有意义的。与相应的标签结合使用以防万一。当然，到后来时间不够时你可以放弃这些技术债务任务。
3. 没有功能的任务并不是罪过
如果您可以像这样管理它们，那么任务并不总是需要一个功能。Azure DevOps提供了大量工具（例如，在票证上查询）来查找和管理您想要的内容。
为团队和项目做有意义的事情，而不是“打勾”。
- Alex Klaus
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接