工作项跟踪（1）

可跟踪性是软件过程的重要能力，TFS主要是以工作项来实现过程的可跟踪性。曾有人问："你们实际项目里的工作项是怎么样的？能不能让我们看看？"我也一直很好奇别的公司TFS里的工作项是怎样的，网上这方面的资料很少。我就以三年前的三维管线项目为例，说一说我们的工作项跟踪，欢迎大家批评指正。

1 需求

敏捷宣言认为："响应变化重于遵循计划"，需求的变化，尤其是在中国，经常是无休无止。我们要做的就是要在TFS上做好需求管理，从而达到响应变化的目的。

1.1 需求管理

我们先新建一个用户情景，标题写上"爆管分析"，然后指定区域，迭代，堆栈级别，需求说明写到详细信息里。情景点是跟工作量相关的，我们没有估算工作量，也没有安排时间进度。

用户情景是需求管理的基本单元，跟文档化需求管理有很大的不同，我们没有强调需求基线评审，也没有正式的需求变更审批。需求发生变化时，只管更新到用户情景的详细信息。需求往往会经过反反复复的修改，历史记录里会保存着更改的时间，人，内容。这比跟踪需求规格说明书这样的大文档的版本历史要容易的多。

1.2 用户故事

用户故事是需求建模的一种方式，也是敏捷开发的重要实践。功能点的建模我推荐采用用户故事，可以比可视化建模表达详细的信息。转到上图里的"实现"，这时我们看到当前的子项为空，接下来新建一个子任务"编写爆管分析用户故事"，经过反反复复的修改最终结果如下：

1 启动爆管分析命令，系统显示爆管分析界面；

2 指定一条管段，三维窗口里显示这条管段的选中状态；

3 输入缓冲区半径后执行分析，系统显示出阀门井列表；

4 双击列表中的一条记录，三维窗口定位到当前的阀门；

5 点击[导出]按钮，列表里的数据导出到excel里了；

（用户故事完成后合并到用户情景的详细信息里，跟需求规格并列）

2 设计

软件的设计涉及到方方面面，同时还有各种各样的设计方法。我认为实际的工作中我们应该只做必要的设计，敏捷宣言认为："工作的软件重于详尽的文档"。工作的软件就是可以运行的程序，和运行所必须的数据。基于代码和数据一样可以作出好的设计，在没有必要写文档时，尽量不要长篇大论。

2.1 爆管分析输出设计

转到用户情景的"实现"，创建一个新的子任务，写上标题"爆管分析输出设计"，并链接"编写爆管分析用户故事"作为前置任务。

接下来我们看看这个任务的结果，变更集的注释是"爆管分析输出设计.fly"，下载打开发现是用skyline软件制作的三维数据，如图所示。

2.2 爆管分析用户界面视觉设计

再创建一个子任务，写上标题"爆管分析用户界面视觉设计"，指派给界面设计师，转到"所有链接"，链接类型选择"已进行版本管理的项"，指定项"$\Pipe2012A1\Documents\设计\输出设计\爆管分析\爆管分析输出设计1.png"，写上注释"工作输入"。即"爆管分析输出设计"任务的工作输出是这个任务的工作输入。

工作完成后，我们打开变更集5702，并查看其中的图片"$\Pipe2012A1\Documents\设计\界面设计\爆管分析\爆管分析界面设计1.png"

2.3 爆管分析面向对象设计

再创建一个子任务，写上标题"爆管分析面向对象设计"，并链接"编写爆管分析用户故事"作为前置任务。这里的"面向对象设计"已经是详细设计了，我们的做法是直接到代码，需要设计类名，输入数据，输出数据，方法，命名空间等。"代码是最精确的文档"，不要在文档上绕来绕去，没有程序员有兴趣看那些华而不实的设计文档。

我们打开"变更集5143"，查看"BoomPipeCommand.cs"。

3 构建

构建最主要的活动是编码，由于敏捷开发反对过度的详细设计，所以这里的编码所涉及到不仅仅是实现，还包括：算法设计，设计模式，代码重构，代码调整等等。用代码承载那些精妙的设计，而不是笨重的文档。

3.1 爆管分析编码

再创建一个子任务，写上标题"爆管分析面向对象设计"，并链接"爆管分析用户界面视觉设计"和"爆管分析面向对象设计"作为前置任务。这样就不用给该任务链接工作输入了，执行任务的程序员可以直接找到前置任务的工作输出（即变更集）。

任务完成后，我们看到"变更集5115"的链接注释"BoomPipeCommand.cs"，"变更集5160"的链接注释"BoomPipeControl.cs"。代码大家都很熟悉了，这里就不再详述。

4 测试

TFS的测试涉及非常多的内容，本文我只谈测试用例和Bug。

4.1 测试用例

转到用户情景的"测试用例"，创建一个新的测试用例，标题写上"手工输入管段ID进行碰撞分析"，然后使用Microsoft测试管理器进行编辑，在步骤里写上：

操作	预期结果
点击[爆管分析]按钮	左边栏显示爆管分析界面窗口
从文本框输入"J-A229"，回车	三维窗口高亮显示ID为"J-A229"的管段，并闪烁爆管的图标。
输入缓冲区半径200，点击[开始分析]按钮	阀门井列表显示2条记录
双击列表中的第一条记录	三维窗口定位到控制阀门"FA-331"并闪烁
点击[导出]按钮，选择路径"d:\1.xls"	系统提示导出成功。
在excel里打开"d:\1.xls"	显示2条记录，ID分别是"FA-331"，"FA-334"，

测试用例完成后结果如下：

4.2 Bug

测试工程师在测试中发现了Bug，这时候应该转到用户情景的"所有链接"，新建一个Bug，标题写上"Bug：阀门记录与操作有误"，严重级别为"中"，然后写上说明，指派给某个程序员。程序员调试Bug之后，会把状态改为"已解决"，原因改为"已修复"。指派给测试工程师，测试工程师验证后，如果没有问题就将状态改为"已关闭"。

5 小结

现在让我们回到用户情景的"所有链接"，我们将看到如下图所示：

在TFS上，需求管理，项目管理，测试管理，缺陷跟踪等融为一体。无论是从需求到设计，编码，测试，Bug的正向跟踪，还是从Bug向编码，设计，需求的逆向回溯，都不成问题。取得了可跟踪的能力，响应变化也就不再是一句空话了。

博客转自：《TFS(Team Foundation Server)敏捷使用教程(四)：工作项跟踪（1）》

巴特西

[转载]基于TFS实践敏捷-工作项跟踪