工作项跟踪（1）
可跟踪性是软件过程的重要能力，TFS主要是以工作项来实现过程的可跟踪性。曾有人问："你们实际项目里的工作项是怎么样的？能不能让我们看看？"我也一直很好奇别的公司TFS里的工作项是怎样的，网上这方面的资料很少。我就以三年前的三维管线项目为例，说一说我们的工作项跟踪，欢迎大家批评指正。
1 需求
敏捷宣言认为："响应变化 重于 遵循计划"，需求的变化，尤其是在中国，经常是无休无止。我们要做的就是要在TFS上做好需求管理， 从而达到响应变化的目的。
1.1 需求管理
我们先新建一个用户情景，标题写上"爆管分析"，然后指定区域，迭代，堆栈级别，需求说明写到详细信息里。情景点是跟工作量相关的，我们没有估算工作量，也没有安排时间进度。
用户情景是需求管理的基本单元，跟文档化需求管理有很大的不同，我们没有强调需求基线评审，也没有正式的需求变更审批。需求发生变化时，只管更新到用户情景的详细信息。需求往往会经过反反复复的修改，历史记录里会保存着更改的时间，人，内容。这比跟踪需求规格说明书这样的大文档的版本历史要容易的多。
1.2 用户故事
用户故事是需求建模的一种方式，也是敏捷开发的重要实践。功能点的建模我推荐采用用户故事，可以比可视化建模表达详细的信息。转到上图里的"实现"，这时我们看到当前的子项为空，接下来新建一个子任务"编写爆管分析用户故事"，经过反反复复的修改最终结果如下：
1 启动爆管分析命令，系统显示爆管分析界面；
2 指定一条管段，三维窗口里显示这条管段的选中状态；
3 输入缓冲区半径后执行分析，系统显示出阀门井列表；
4 双击列表中的一条记录，三维窗口定位到当前的阀门；
5 点击[导出]按钮，列表里的数据导出到excel里了；
（用户故事完成后合并到用户情景的详细信息里，跟需求规格并列）
2 设计
软件的设计涉及到方方面面，同时还有各种各样的设计方法。我认为实际的工作中我们应该只做必要的设计，敏捷宣言认为："工作的软件 重于 详尽的文档"。工作的软件就是可以运行的程序，和运行所必须的数据。基于代码和数据一样可以作出好的设计，在没有必要写文档时，尽量不要长篇大论。
2.1 爆管分析输出设计
转到用户情景的"实现"，创建一个新的子任务，写上标题"爆管分析输出设计"，并链接"编写爆管分析用户故事"作为前置任务。
接下来我们看看这个任务的结果，变更集的注释是"爆管分析输出设计.fly"，下载打开发现是用skyline软件制作的三维数据，如图所示。
2.2 爆管分析用户界面视觉设计
再创建一个子任务，写上标题"爆管分析用户界面视觉设计"，指派给界面设计师，转到"所有链接"，链接类型选择"已进行版本管理的项"，指定项"$Pipe2012A1Documents设计输出设计爆管分析爆管分析输出设计1.png"，写上注释"工作输入"。即"爆管分析输出设计"任务的工作输出是这个任务的工作输入。
工作完成后，我们打开变更集5702，并查看其中的图片"$Pipe2012A1Documents设计界面设计爆管分析爆管分析界面设计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向编码，设计，需求的逆向回溯，都不成问题。取得了可跟踪的能力，响应变化也就不再是一句空话了。