TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

工作项跟踪(1)

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

1 需求

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

1.1 需求管理

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

1.2 用户故事

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

1 启动爆管分析命令,系统显示爆管分析界面;

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

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

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

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

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

2 设计

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

2.1 爆管分析输出设计

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

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

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

2.3 爆管分析面向对象设计

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

3 构建

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

3.1 爆管分析编码

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(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",

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

4.2 Bug

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

5 小结

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

TFS(Team Foundation Server)敏捷使用教程(四):工作项跟踪(1)

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

上一篇:[TYVJ] P1001 第K极值


下一篇:javascript工具--控制台详解(转自 阮一峰博客)