一、引言

1 中国式软件过程的坏味道
RUP，CMM/CMMI到了中国就变了味。。。。。。

2 Team Foundation Server
TFS是软件开发的协作平台，它要解决的首要问题是团队成员的协作问题。比如说：
研发团队内部怎么协作，产品经理，架构师，设计师，开发人员，测试人员怎么进行协作，并行工作？
研发团队之间怎么协作，开发人员怎么共享重用技术，加强横向的联系？
研发团队与运营团队怎么协作？

之前我一直在实践着Rational系列软件产品，总觉得Rational系列易用性不好。一直到2006年我才发现有TFS，但安装部署Team Foundation Server 2005没有成功，所以到2007年Team Foundation Server 2008(beta1)发布后，我们才开始试用，期间经历了TFS的多次发布。在4年的实践过程当中，我们越来越深刻认识到：只要协作的问题解决了，管理的诸多问题将迎刃而解。
"软件过程没有银弹！"但可以有核弹，TFS就是这样的核弹，它的威力足以支持超大型的软件团队，研发优秀的软件产品。当然它的威力大小取决于你运用的功力。

3 敏捷过程
作为软件全生命周期的工具，TFS支持CMM等重量型软件过程，也支持敏捷过程。CMM等重量型软件过程受管理人员的欢迎，敏捷过程更受开发人员的欢迎。重量型软件过程过于粗放，敏捷过程更细致灵活。从管理思想上来看，重量型软件过程强调管理，执行力，纪律，制度等，有兵家和法家思想的特点。敏捷过程强调协作，创造性，自由等，无为而治，有道家思想的特点。
君子性非异也，善假于物也。再先进的思想也离不开工具。扎根在TFS的平台上，敏捷思想必能开出更加炫丽的花朵。
4 持续改进
中国文化创造了中国式软件过程的坏味道，西方文化创造了TFS，也创造了敏捷思想，并且指明了软件过程持续改进的原则。从蹒跚学步到腾云驾雾绝非一日之功，需要十年磨一剑的执着。而分享成功的经验，改变中国式软件过程的坏味道，不要让TFS也变了味，为千千万万的程序员创造良好的生态环境，则是更大的挑战，需要更多人的努力，更需要持续改进。
最近我一直在思索，新手怎么学习TFS和敏捷过程。对于刚刚工作的程序员，虽然经验不足，但恶习未养成，可塑性最好。从一开始就应该持续的学习和实践，始终走在正确的道路上。千里之行，始于足下。从一下篇开始，我们将把起点定位新手的水平，来学习TFS

二、源代码管理

重量型过程改进通常会先拿出一个文件夹，里面有各种规范和文档模板，琳琅满目，ISO9000如此，RUP也是如此，CMM更是如此。一般人看到这么多东西非吓晕过去不可，但咨询师会鼓励你，告诉你这是培训的框架，都是必须品，等你把这些东西掌握了就如何神通广大了，然后开始漫长的学习过程。新手？这是for高级岗位的。

敏捷开发认为：代码是最精确的文档，一个软件什么都可以省，唯独代码是必不可少。一个项目团队可以没有项目经理，测试人员，哪怕只有一个人，那一定是个程序员。现在，只要会写代码，马上就可以开始敏捷开发了，门槛不高吧？这才是最贴近我们程序员的软件过程。

1 TFS 2010入门

TFS 2010的安装已经很容易了，安装完后点下面的链接先入个门：Visual Studio Application Lifecycle Management 入门

1.1 连接到 Team Foundation Server

1.2 新建团队项目

1.3 将解决方案添加到源代码管理

1.4 签入

简单练习一下上面列出的4条，你就已经入门了。

2 源代码管理资源管理器

接下来请打开"源代码管理"，这才是众妙之门，CMM的文档模板集只是个笨重的大包裹。练练"签入"，"签出"，就可以用TFS来工作了。好像有的人用TFS只是来做源代码管理，有点儿可惜了。

3 管理工作区

3.1 编辑工作区

接下来打开工作区，添加或编辑工作区，把TFS服务器映射到本地文件夹D:\Projects，确定后系统会提示你，"工作区已修改，是否要更新本地工作区"，选是。

3.2 本地工作区

下图是本地工作区D:\Projects的目录结构，每个文件夹映射到一个团队项目，与服务器的团队项目完全相同。这样把各个不同的项目区分开，不同项目的成果和过程文件等各自放到各个项目文件夹里，不要再放到桌面，我的文档，逻辑驱动盘的根目录等。另外不要把不相关的文件签入到团队项目里来。敏捷的秘诀之一就是力求简单。

3.3 团队项目目录结构

序号	目录	说明
1	Data	数据
2	Documents	文档
3	Source	源代码

软件=程序+数据+文档，这不正是我们软件工程师理解的软件吗？让那些高高在上的理论落地，成为我们实践中的一部分。

4 变更集

4.1 历史记录

在"源代码管理资源管理器"里选中"Source"，然后点击工具条上的历史记录，我们将看到"Source"目录下所有的变更集。这些变更集是我们日常签入在TFS上自动化的结果，这不需要CMM过程填这样那样的表格，不会增加我们的负担。即使写个简要的注释慢慢的我们也习惯得了。要知道，我们的目的是给程序员减压，而不是加压。

4.2 变更集详细信息

现在我们看看70号变更集的详细信息，我们看到这次变更是添加了一个文件"LoadLayerCommand.cs"。

右键查看一下这个文件里写了什么：

4.3 查找变更集

打开"查找变更集"界面，我们可以按用户，文件，日期等条件进行组合查询。下图是查文件"LoadLayerCommand.cs"的变更历史，以了解它的开发以及重构等。

4.4 签入原则

变更集是由签入产生的，所以正确对待每一次签入。乱糟糟的代码肯定会导致乱糟糟的变更集，关于如何写简洁的代码，请参考《敏捷软件开发：原则、模式与实践》，《重构-改善既有代码的设计》等书。对于新手，签入的时候尽量用小的变更，不要把多个单一职责的文件一起签入，比如说："ImportTxtFileCommand.cs"和"ExportTxtFileCommand.cs"要分开签入，即使你写在同一个文件里"MainForm.cs"的两个方法"ImportTxtFile()" 和"ImportTxtFile()"也分开签入。为什么呢？是因为我们将归纳变更集来产生工作项，你签入耦合度非常大的变更集，我们就没办法归纳了。正向的工作计划不容易，逆向的工作总结要容易的多。好了，今天先说到这，至少工作项已经很近了，下一篇探讨怎么通过工作总结来提高工作计划的能力。

三、定制敏捷过程模板

Team Foundation Server 2010内置两个过程模板，虽然有TFS过程帮助文档，但微软并没有提供我们最需要的实践指南，示例等。我们一直用"MSF for Agile Software Development v5.0"，长期以来我们尽量适应这个模板，把它当成标准来用。但是渐渐的我们发现这个过程模板跟我们实际的开发工作并不吻合，一方面这个模板毕竟是舶来之品，跟中国式的软件特点有很大的差异；另一方面软件过程持续改进是恒定的规律，现阶段的工作特点需要跟现状相符的过程模板，而不是一步到位。

首先启动Visual Studio 2010，打开"团队\团队项目集合设置\过程模板管理器"，下载"MSF for Agile Software Development v5.0"到本地文件夹。

然后下载：Team Foundation Server Power Tools ，安装完成后，在visual studio里执行"工具\Process Editor\Process Templates\Open Process Template"，打开刚下载的"MSF for Agile Software Development v5.0"进行修改。

1 迭代(Iterations)

团队项目的第一个阶段是"迭代 1"，"迭代 n"等随项目的进展动态添加。另外，这里增加一个特殊的迭代："积压"(Backlog)，未计划的，不明确，不紧急的工作项暂时放到"积压"里，随着项目的进展情况以及客户的要求，"积压"里的工作项才会安排到"迭代n"里。

2 组成员资格(Group)

新增三个组：Developers (开发者)，Support (技术支持)，Testers (测试员)

3 团队查询(Team Queries)

敏捷过程模板默认生成的团队查询如下图所示，看起来比较复杂，我们一边用一边定制新的查询，来来回回用了两年，最后总结了最常用的查询，那些不常用的查询狠狠心都删除了。

图 1 修改前图 2 修改后

3.1修改查询

3.2 我的所有工作

这个查询体现的是个人关注，是项目成员工作的入口，把所有项目中指派给他的用户情景，任务，问题，Bug显示在一个表格里，使得他可以快速简便的查看自己的任务情况，比如：新任务，未完成的任务，优先级高的任务等等。实践发现，这种方式比让他去各个项目里去查找"我的任务"，"我的Bug"等要有效的多，特别是对于多项目并行开发以及跨部门协作的情况。

3.3 所有工作

这个查询体现的是项目关注，关注项目的全部工作项以及工作项之间的父子关系。

4 工作项(Work Item)

4.1 默认工作项(Default Work Items)

TFS2010支持工作项的层次结构，这样当工作项特别多的时候就不像TFS2008那么乱了。于是每一个新的团队项目里都要手工创建完全相同的顶层摘要任务，重复工作又来了，消灭重复劳动，提高自动化水平是我们义不容辞的责任，那就直接在默认工作项里添加吧。一点小遗憾是不能建立父子关系，只能在创建团队项目后手工完成。

4.2 工作项类型(Work Item Type)

本来不想定制工作项类型，无奈敏捷过程模板不支持"开始日期"和"完成日期"，如果想要设置工作项的"完成日期"，还要用Office Project打开tfs才能修改"完成日期"。这也太不敏捷了，打开"Type Definitions"编辑任务，添加上"开始日期"和"完成日期"。

预览一下看看效果，看起来还挺合适的嘛！自从把这两个字段放出来，舒适度提高20%。

最后，把修改完的过程模板改名为："MSF for Agile Software Development v5.1"，再次打开过程模板管理器，上载到服务器。

代码下载

四、工作项跟踪（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之后，会把状态改为"已解决"，原因改为"已修复"。指派给测试工程师，测试工程师验证后，如果没有问题就将状态改为"已关闭"。