下面这份邮件是发自参加了Scrum Navigator Training 第11期的学员，在这里和大家分享一下。这里面有很多很有意思的信息，特别是这位学员比较了TFS与CC之间在源代码管理上各自的优势，供大家参考。
各位领导，老师、同学：
本周3，4，5（2012年11月）参加了微软委托SSW公司进行的 Visual Studio 2012 实战培训。这里是培训简单纪要和分析。
我对VS2012+TFS+Scrum了解还是很少，如有认识错误，还请leixu@ssw老师指正。
本次培训包含大约三块内容。
- Scrum过程管理讲解，
- 使用VS2012 TFS完成Scrum过程的实践。
- VS2012 测试工具与测试流程，含Lab Manager的简要介绍。
通过培训可以发现VS2012的功能几乎已经覆盖我所知的软件开发过程管理的各个环节。唯一例外还没有发现原型设计工具。
Scrum开发过程
Scrum是一种软件开发过程管理模式，和CMM一样Scrum并不一定需要某种软件支持。使用纸质表格、看板也可以实现Scrum。软件过程管理大方向上分为4类：无管理，Agile（敏捷）、Iterative（迭代）和Waterfall（瀑布）。Scrum属于Agile的一种。除了Scrum，Agile还包含Agile Modeling，Feature-driven development（FDD，特性驱动开发，目前我们的方式），Test-driven development（TDD，测试驱动开发，目前U8的方式），eXtreme Programming(XP)等。
Scrum与CMMI存在理念上的差异。CMMI基于对人的不信任，对流程的信任。而Scrum则基于对人的信任，进而创造出一种基于信任的工作方式。Scrum认为CMM4更倾向于对个体的考核，而不是对团队的考核，这样CMMI4的考核方式可能造成团队支离破碎。Scrum模式与 CMM3（组织内的各种行为存在固定流程）,ISO 9001兼容。如果CMM Level < 3，Scrum有助于企业达成CMMI 3。如果CMM Level > 3，Scrum将成为到CMM 3以上级别的障碍。【PS：CMMI4，组织内的流程可度量，PS2：CMM创世于美国国防部】
Scrum的主要目的是为了发现问题，暴露问题。而不是解决问题。Scrum时间节拍推荐为2周，也可以推广为1~4周。 从人员看，Scrum比较适合5~9人，团队内人员没有技术分化，PM的个人能力较弱的情形。Scrum的理念主要包含：
- PM分裂为PO和ScrumMaster两个人。将需求与时间成本的权衡过程从一个人的脑内思维过程，转变为2个人的博弈过程。通过矛盾公开暴露问题。
- 采用“情景点数量”代替“工时估计”。情景点用符号而不是数字区分大小。项目运行中期，可以根据此前实际发生的情景点-工时对照关系推算之后项目还需要的时间。
- 每个周期叫做一个时间盒，ScrumMaster将情景点分解为大约1日可完成的工作项，并把这些工作项放置在不同的时间盒中。
- 积压工作任务自主领取方式，而不需要管理人员分配问题。
- 采用固定的时间节拍。时间到，本次迭代即终止。便于控制时间进度和暴露问题。
- 工作项只考察完成/未完成。而不考察完成百分比。因为完成百分比没有意义。
- 任何工作项的完成都带有一个可考核标准。
- 任何错误都会被及时告知。
Scrum的主要元素包含：
- 双周计划，评审和回顾会议。评审会议和回顾会议区别在于是否有客户方参加。
- 每日站立会议。
- 积压工作项看板
- 燃尽图
Yangli注：不能把Scrum简单的理解为双周计划+看板，双周计划+看板不含有PO和ScrumMaster的博弈过程，也不是任务自主领取方式。
Visual Studio 2012的调试、测试新功能
- VS2012可以将测试过程自动记录，可自动录屏（含语音）、截图、录操作。并且通过TFS将测试人员的操作过程回放给开发人员，便于重现问题和问题的回归测试。另外录制的脚本可编程。这一点类似Robot，但TFS的测试工具和过程工具的集成度更高。另外Robot采用的是类Basic语言，而TFS测试脚本采用的是C#语言。南昌测试中心建立后，此功能对测试团队和开发团队的远程协作非常有用。
- VS2012+TFS支持“提交必须构造”、“提交必须通过单元测试”检查。TFS比CC多一个预提交概念。构造主控服务器/构造代理服务器在尝试构造预提交代码后。决定这些代码是否可正式提交。如果不成功，开发人员会得到构造错误反馈。同时TFS在构造检查时，还顺便检查“单元测试代码覆盖率”。单元测试代码覆盖率仅仅作为参考，并不要求100%，原因在于对于自动生成代码并不需要检查。、
- VS2012的历史调试功能得到强化。过去我们从用户现场只有抓Dump文件、回传日志两种方式。现在又增加在生产环境进行IntelliTrace功能。相对于Dump文件记录故障时刻的内存现场，IntelliTrace记录整个程序的状态变化过程。这样调试器可还原当时的整个执行过程，进而更快的找到问题所在。
- VS TestProject和Nunit单元测试工具在用法上接近。但更胜一筹。微软TestProject可以让上次测试失败用例优先运行，而且连续多次运行测试用例，后续的测试会被优化执行。疑似VS首先分析了代码变更集合，并计算了变更影响。对于无影响的Test Case自动跳过。
- VS 开发测试云/Lab Manager。将整个测试环境虚拟化。在虚拟环境中，他们的网络互相隔离，这样每个测试环境完全一样，甚至IP地址、机器名都一样。测试人员可以将测试故障现场保存在对应虚拟机时间点内。方便开发人员随时查看和重现问题。
Visual Studio 2012 TFS 与 CC/CQ 比较（粗体表示优势）
|
TFS |
CC/CQ |
| 直接提供Scrum、CMMI、Agile、MS Scrum 2.0等诸多管理模板，此外用户可通过TFS工作流设计器自行修改开发适合自己的过程。 | CQ提供客开工具，在CC各种操作上提供可编程的事件。这样用户自行开发一套适合自己的过程管理软件。 |
| 集成测试软件，并可以和录屏，录操作脚本直接整合 | |
| TFS2008在创建分支时，会复制整套源代码。TFS2010、TFS2012在创建分支时已经不会再复制整套源代码实例。但是否创建了元素的版本需要考察。 | 创建流时刻不会为每个元素创建版本，更不会创建元素实例。 |
| 丰富的报表和分析工具 | 所有报表需要客开 |
| 多种展现形式除Visual Studio外，还可以使用MS Project、MS SharePoint、MS Excel、Web Explorer等 | 需要各种插件支持，有些插件需要客开 |
| 代码在签入的时候建立变更集与工作项关联关系。但匪夷所思的是，将本次签入可以建立他人，甚至是已关闭的工作项建立关联 | 代码签出时建立活动与工作项目关联关系。 |
| 代码合并时，如果TFS认为合并没有问题。则自动完成合并。没有人的干预时机 | CC在所有产生冲突的合并都给出3文件对比视图。并缺省给出合并结果。让人决定如何合并。 |
| 无此视图，文件的流间比较可通过任意流+任意文件比较的方法实现。实际操作起来并不方便。 | 元素的版本树视图，可方便的进行文件可流间比较。 |
| 每次代码签入都产生新的变更集编号。每次分支之间的代码合并也产生新的变更集编号。TFS提供分支之间代码合并时的变更集追溯关系视图 | 提交本身不创建活动。也不会在签入代码后自动关闭活动。流之间提交活动不会产生新的 |
附：名词对应关系，左侧是TFS，右侧是CC/CQ。（很多概念并不是完全对应）
- 分支 — 流
- 变更集 — 活动
- 工作区 — 视图
- 工作项 — 工作项（缺陷、支持问题、BUG、开发任务）
个人观点：
IntelliTrace值得引入，此将成为WinDBG、Log之外的另一个有效的现场BUG分析工具。
微软的Test Project，以及提交时自动检查构造、检查单元测试、检查单元测试代码覆盖率的功能值得学习和引入。
自动化测试过程，录屏，录操作等过程。适合在远程工作。建议引入此工具。
虽然TFS在过程管理的诸多外围功能上比CC、CQ有明显优势。但是在最核心的源代码管理，尤其是活动和工作项关联过程、元素版本树、文件合并这三个关键点上并不如CC/CQ。至少说没有优势。对于咱公司来说，这些外围功能已自行开发并稳定运行。所以现阶段还不考虑CC向TFS迁移过程，尤其现在是4季度业绩冲刺阶段。其TFS的“预提交”机制，目前已经采用“提交到开发流，构造通过后提交到集成流方式”解决。
