这是第一本由微软Visual Studio Team System一线开发人员所写的原创精品。本书直接针对中国软件开发人员写的循序渐进的、基于案例的教材；通过微软自身的实践直接介绍微软开发流程(MSF)的实用手册，许多方法和模板正在微软的实际开发中使用着。

　　觉得众多的软件工程“方法论”纷繁复杂么？作者第一次在MSF Agile 4.0过程模型的基础上提出了适合小型团队的“移山方法”，精简过程，直奔主题。

这是一本介绍软件开发方法(MSF)和工具(VSTS)的书，这本书讲程序设计的基本原则，如何在工具的帮助下进行软件的开发，如何与人合作，如何管理软件工程，微软解决方案及方法论。

本书通过虚拟的开发团队——移山公司利用Visual Studio Team System (VSTS)及Microsoft Solution Framework (MSF)敏捷方法论来开发其网站的全过程，系统地讲述了软件开发的方方面面，使大家可以了解VSTS如何与真实的开发过程结合起来。并且通过一系列发生在团队成员之间故事和对话，生动地描述了在实战中如何运用开发方法，同时解答读者的疑惑。

本书共分三个部分，在编排上由易到难，可以供各种层次的读者选择阅读。第一部分，介绍VSTS的基本功能；第二部分，着重讲个人开发技术和两个人如何合作；第三部分，联系具体的开发过程，讲解具体使用技巧，理论联系实战。

第1篇 VSTS介绍

第1章 VSTS概述

　1.1 VSTS简介

　1.2 VSTS快速演示

　1.3 实战演习

　1.4 河曲数码的项目经理

　1.5 本章讨论

第2章 白话MSF方法论

　2.1 果冻的预习

　2.2 MSF基本原则

　2.3 MSF团队模型

　2.4 MSF过程模型

　2.5 MSF敏捷开发模式

　2.6 MSF CMMI开发模式

　2.7 本章讨论

第3章 MSF敏捷模式的工作流程

　3.1 开门14件事

　3.2 项目管理流程

　3.3 回顾

　3.4 本章讨论

第4章 工作项

　4.1 什么是工作项

　4.2 工作项的字段

　4.3 MSF敏捷方法论中的工作项

　4.4 本章讨论

第5章 源代码控制

　5.1 TF源码控制基本使用场景

　5.2 把一个项目加到源码控制中

　5.3 和服务器的同步

　5.4 签入待定修改

　5.5 分支，合并，标签

　5.6 源码控制中的标签

　5.7 上架(Shelve)，下架(Unshelve)

　5.8 TFS和VSS

　5.9 本章讨论

第6章 构建工具

　6.1 TF构建的基本概念

　6.2 TBF架构

　6.3 拓扑结构和安全性

　6.4 构建基本流程

　6.5 每日构建

　6.6 本章讨论

第7章 软件测试和VSTS测试工具

 7.1 基本名词解释及分类

 7.2 单元测试(Unit Test)

 7.3 代码覆盖率测试(Code Coverage Analysis)

 7.4 构建验证测试(BVT：Build Veilfication Test)

 7.5 验收测试(Acceptance Test)

 7.6 “探索式”的测试(Ad hoc Test)

 7.7 回归测试(Regression Test)

 7.8 场景/集成/系统测试(Scenario/integration/System Test)

 7.9 伙伴测试(Buddy Test)

 7.10 效能测试(Performance Test)

 7.11 压力测试(Stress Test)

 7.12 内部/外部公开测试(Alpha Test，Beta Test)

 7.13 可用性测试(Usability Test)

 7.14 “小强”大扫荡(Bug Bash)

 7.15 讨论

第8章 Office集成功能、报表、门户网站，以及其他

 8.1 与Excel的集成

 8.2 与Project的集成

 8.3 报表分析

 8.4 项目门户网站

 8.5 从网页访问VSTS

 8.6 使用TFS OM

 8.7 本章讨论

第2篇 基本技术

第9章 提高个人技术

 9.1 从Hello World开士台

 9.2 移山开发方法——比敏捷更精简

 9.3 建立最简单的项目，WC

 9.4 VSTS效能分析工具

 9.5 本章讨论

第10章 代码规范与代码复审

 10.1 代码风格规范

 10.2 代码设计规范

 10.3 代码复审

 10.4 本章讨论

第11章 两人合作

 11.1 对工作的估计

 11.2 WBS和时间的分配

 11.3 单元测试

 11.4 好的单元测试的标准

 11.5 结对编程

 11.6 两人合作的不同阶段(舞蹈版)

 11.7 二人的合作——如何影响对方

 11.8 黄金点——两人合作的项目

 11.9 思考

 11.10 进一步的作业

 11.11 本章讨论

第3篇 实例分析

第12章 构想阶段

 12.1 项目的起因

 12.2 收集意见

 12.3 团队构成

 12.4 领导小组——阿超的软件开发观点和管理理念

 12.5 团队讨论

 12.6 不对称的主楼

 12.7 用户需求分析

 12.8 决定项目的远景

 12.9 团队合作要经历的阶段

 12.10 本章讨论

第13章 计划阶段

 13.1 委群材，会群工

 13.2 项目计划

 13.3 创建TFS项目及设置

 13.4 软件项目的估计

 13.5 项目计划

 13.6 项目管理到底管啥

 13.7 移山故事：功能本天成，妙手偶得之

 13.8 测试计划

 13.9 本章讨论

第14章 开发阶段

 14.1 典型用户

 14.2 从典型用户到场景

 14.3 场景到任务

 14.4 从任务到代码

 14.5 别人在干啥

 14.6 开发阶段的日常管理

 14.7 代码完成

 14.8 讨论

第15章 稳定阶段

 15.1 Debug还是Release

 15.2 测试的文档

 15.3 测试设计说明书(TDS)

 15.4 测试用例(Test Case)

 15.5 错误报告(Bug Report)

 15.6 测试修复，关闭缺陷报告

 15.7 测试报告(Test Report)

 15.8 运用测试工具

 15.9 萝卜、白菜，各有所爱

 15.10 会诊(Triage)

 15.11 向ZBB进军

 15.12 本章讨论

第16章 发布阶段和之后

 16.1 公开测试，Alpha和Beta发布

 16.2 执行发布计划

 16.3 设计变更(DCR)

 16.4 重写或者是重构

 16.5 砍掉功能

 16.6 螺旋式的上升

 16.7 衡量工作绩效

 16.8 本章讨论

第17章 结束语

 17.1 阿超和小李

 17.2 大牛

 17.3 小飞

 17.4 果冻

 17.5 荔荔

 17.6 大栓

 17.7 二柱

 17.8 九条

 17.9 芸芸

 17.10 你的结束语

附录A 参考资料

附录B 代码规范

附录C 测试计划

附录D 网络软件工程相关站点

作者介绍

英文索引

中文索引

　 3.2 项目管理流程

3.2.1 制定项目的远景

我们要开发一个软件项目，首先要了解项目的背景，了解什么样的内部和外部事件促发产生了对于新的系统的要求。了解项目的驱动因素：描述项目的主要用户需求，或者时间需求。说明此项目是时间驱动(在某一展览会前必须发布，某年度开始前)，或者是功能驱动(所有功能实现后才能发布)。

了解并定义项目的用户：决定谁能从软件系统中获得最主要的价值。

讨论项目的核心价值：系统的价值主张(Value Proposition)在哪里?卖点在哪里?用户能得到啥?要把核心的概念浓缩到30个字左右的一句话。

定义用户角色：从项目远景中提到的用户中选取一组用户。如果项目远景没有足够的用户说明，现在就要做。如果系统牵涉到安全性的问题，则用户集合中最好要包括一个不怀好意用户的角色，比如未经认证的用户。

创建典型用户。为TCIJ建典型用户，必须收集用户的数据。收集用户信息的方法有多种：可用性测试、实地访问用户、市场调查、用户调研(Focus Groups)。

把用户按照典型的知识、技巧、能力、喜好分类，为每一类用户都创建一个典型用户文件。为每一个典型用户起一个接近真实生活的名字。在典型用户文件中描述人物的简要经历、性格特征(好的和略有怪异的方面)、兴趣和爱好等，可以加上一些生活细节，使人物看起来更活灵活现、可信。把典型人物文件发布到团队项目门户网站上去。

细化典型用户。分析各类用户在以下方面的异同：知识、技能、使用系统的模式、交互方式，以及想通过系统达成的目标。

如果用户的差异比较火，分析是否需要一个新的典型用户，或者修改目前已有的用户。这时候，团队成员要考虑：

◆是否要增加或修改场景、QoS；

◆检查已有的优先级，考虑是否要正。

3.2.2 指导项目进展

项目的管理人员存项目过程中做什么事情呢?指导项日进展要如何“指导”?

回顾目标和进展

设置最低接受标准。评估市场和用户对产品的期望值。要考虑到竞争对手、以前版本的系统和商业需求。根据期望值，审核已有的场景和QoS，对于每一项，设定一个最低接受标准。

报告当前的接受水平。报告当前团队在各方面取得的成果和最低接受标准的差距。

评估进度

评估未完成的工作。如果项目有一个预期完成的日期，用已经发生的迭代长度来确定还可以进行多少次迭代(得到N)。使用进度报告(Velocity Report)来确定理想状态下完成一次迭代需要的人日是多少(得到PD)。用N x Pd得到理想状态下我们还剩下多少人日。

如果从进度分析上看，我们没有足够的时间去完成所有功能来达到“最低接受水平”，我们就不得不考虑：

◆削减功能；

◆增加资源；

◆提高劳动生产率。

如果在项目的早期就能够了解进度的潜在问题，就能够有更多的选择余地，以规避风险。还可以用“风险”这一工作项来管理类似的风险。

如果要选择增加劳动生产率，不要天真地认定这就万事大吉了。说不定在“生产率”提高的同时，产品的质量也在下降。“实际质量和计划速度对比”图表能告诉我们工作量的增加是否意味着质量下降。

还要检查项目计划中的依赖关系，如果_。些被依赖的项目没有按时交付，这是一个风险，需要根据它的严重程度适当地应对。

根据阈值评估测试报告

复审测试报告。复审各类测试报告，了解从测试的角度来看，项目的进展如何。进一步细化测试方法，更新测试标准数据阂值，并考虑在将来的迭代过程中提高测试标准。

刨建测试任务和风险。为了使项目走上正轨，达到预期目标，测试人员要刨建和分派测试任务。同时，对丁那些可能达不到预期目标的测试标准，测试人员还要创建风险工作项来跟踪这些问题。

会诊(Triage)缺陷

把所有的缺陷都给我列出来!

复审缺陷。对于每一个缺陷，征求开发/测试/管理领域的意见，决定各个缺陷的重要性，在存在意见分歧的情况下，要保证项目的最高目标能够实现。

决定优先级和修复缺陷的迭代阶段。保证开发团队能够在适当的时机按适当的优先级修复这些缺陷。

对丁大多数的缺陷，我们都要先重现(Reproduce)这个缺陷，弄清以下问题：

◆到底缺陷有多严重，问题发生后，有没有挽救的办法?

◆有没有别的途径也导致同一缺陷?

这样才能更好地了解缺陷的影响，为会诊提供充分的数据支持。

有些时候，会诊是在没有充分了解情况的条件下进行的。例如，前一天晚上发现的缺陷，在第二天早上会诊时，并没有时问做充分的调查，这时，可以先把这个缺陷分配给开发人员，在得到充分了解后，再提交，进行第二次会诊。(P61-64)

我在微软总部工作的时候，就听说邹欣程序写得很棒。后来在我和同事们的力邀下，邹欣2005年加盟亚洲研究院成为技术创新组研发经理。在负责将一些研究院技术转化成微软产品的同时，邹欣还负责研究院新员工和实习生的编程培训，包括MS^2项目。

邹欣工程师集他于微软10年的工作经验，撰写了这本关于编程和项目管理的专著。本书内容丰富实用，适合计算机学院、软件学院、信息学院高年级本科生、研究生作为软件开发方法和工具的参考教材。这又是一本基于VSTS软件开发编程实践的好书，是软件程序员继续进修的优秀阅读材料。吏特别的是，这是我读过的最有趣的一本关丁软件开发的书籍。所有对软件产业有兴趣的人士都会发现此书具有极大的参考价值。

作者在本书中与读者分享他在微软的工作经验，以及以MSF为代表的微软的管理理念和企业文化。他列举了很多微软的具体做法，比如一个软件团队成员组成为什么包括软件工程师(Dev)，项目经理(PM)，软件测试工程师(Test)。读者在本书中还会发现很多微软软件开发的秘密，例如吃狗食(Dogfood)，小强大扫荡(Bug Bash)和为什么我们采用里程碑(Milestone)的方式来开发软件。 以前人们常说软件总是要做到第三版(v3)才稳定和最终受用户欢迎，在互联网的时代中，书中的主人公们还有足够多的机会做到v3么?大家可以从书中找到答案。

编程是一个自我挑战的过程。要成为一个优秀的软件程序员，我们必须学习多种编程语言，熟悉编程环境，掌握编程工具，勇于面对挑战。

编程也是一种文化。编写大型软件需要团队协作，需要鼓励争论的工作环境，批评和自我批评的氛围。本书书名为“移山之道”，作者意在鼓励各位编程同好以愚公移山之执著精神，不断提高程序设计和管理的功力。

编程是一项艰苦的工作，更可以是一项有趣的工作。我希望读者在阅读本书时找到编程的快乐，在实战中发掘出更多的编程乐趣，在管理软件项目中收获成功的喜悦。

人类的生活因为优秀的程序员和杰出的软件而变得更加美好。

沈向洋博士

微软亚洲研究院院长

微软公司全球资深副总裁

2007年春于北京

编程是一个自我挑战的过程。

编程是一项艰苦的工作，但更是一项有趣的工作。

《移山之道》意在鼓励各位编程同位好以愚公移山之执著精神，不断提高编程功力。

——微软全球副总裁 沈向洋。