9

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

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

我可能会考虑哪些常见的方法?我什至是通过试图找到一个合适的地方来放这个东西来找到合适的树吗?

4

3 回答 3

4

我还没有发现需要单独跟踪它;我只是将其作为附加任务输入。这样,他们可以很容易地被跟踪和报告。

于 2009-12-21T01:42:01.753 回答
4

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

于 2009-12-21T01:58:25.547 回答
0

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

1. 使用标签 用标签
标记此类工单tech debt以表明对客户的隐含价值总是很方便的(例如,在冲刺中平衡此类任务的百分比)。

2. 避免技术债务功能 避免技术债务功能
的原因有 3 个:

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

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

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

于 2022-01-24T11:50:13.133 回答