我正在寻找一种手动调整 TFS 任务开始日期的方法,以便我的燃尽图看起来正确。
本质上,迭代具有固定的开始/结束日期,并且一些用户故事直到迭代进行到一半才被填写。
这使得燃尽在路上有一个颠簸,所以看起来我们低于目标。
我拥有对 TFS 数据库的完全访问权限,并且想知道我需要编写哪些查询才能使我的任务回溯到迭代的开始。
我在某处读到它是 System.AuthorizedDate 控制燃尽图。
任何帮助表示赞赏。Ĵ
我正在寻找一种手动调整 TFS 任务开始日期的方法,以便我的燃尽图看起来正确。
本质上,迭代具有固定的开始/结束日期,并且一些用户故事直到迭代进行到一半才被填写。
这使得燃尽在路上有一个颠簸,所以看起来我们低于目标。
我拥有对 TFS 数据库的完全访问权限,并且想知道我需要编写哪些查询才能使我的任务回溯到迭代的开始。
我在某处读到它是 System.AuthorizedDate 控制燃尽图。
任何帮助表示赞赏。Ĵ
您在使用 System.AuthorizedDate 时是正确的。
您将无法通过公共 API 更改 System.AuthorizedDate。它不会让你。您无法通过 SQL 更新命令更改 System.AuthorizedDate 日期并保持受支持状态。正式地,Microsoft 不允许这样做,并且仍然保持 Microsoft 为您提供支持的能力,除非 SQL 在他们的指导下(例如通过支持事件)进行了更改。
我怀疑微软的支持事件会产生更新查询,因为它不是缺陷,正如我稍后解释的那样,它可能会让你陷入非常糟糕的境地。您能否在适当的表上创建一系列更新来回溯 System.AuthorizedDate?毫无疑问。它甚至可能会起作用,但我不确定如果你敢这样做,它是否会起作用。原因是工作项在创建时按顺序接收 System.Id 编号。我确实知道,在版本控制中,系统期望更高的变更集编号必须比任何较低的变更集编号具有更晚的提交日期(无法回忆确切的字段名称)。如果系统中对工作项有类似的期望,我不会感到惊讶。您可能会发现,从 SQL 对工作项中的字段进行这种更改会在各个地方呈现错误或意外结果——我可以想象未来的升级甚至更新只是轰炸而无法执行。这都是假设性的,因为除非您希望您的环境处于不受支持的状态,否则您不会通过 SQL 更改它。
除了创建您自己的评估方式不同的燃尽图之外,我不知道在这些条件下实现您期望目标的方法。