为什么要写这本书
在2003年加入微软后，我负责Visual Studio Team System (VSTS)项目，这一新产品线刚刚于2005年底发布。作为这一组产品的规划师，我担任了首席客户代言人这一我很喜爱的角色。我已经在IT行业工作了20多年，在职业生涯的大部分时间里，我做过测试员、项目经理、分析师和开发员。
作为一名测试人员，对于那些高级开发者的实践（比如单元测试、代码覆盖度、静态分析以及内存和性能的特征分析），我始终都能够理解其理论价值。同时，我不能理解一个人怎样才能有耐性去学习那些晦涩难懂工具，而这些工具又是你在遵循正确的实践时所需要的。
作为一名项目经理，我经常烦恼的是：我们所能得到的体面的数据仅仅是那些与缺陷有关的数据。单靠缺陷数据来驾驭一个项目，就仿佛是闭着眼睛开车，只有在你碰到什么东西时才转动方向盘。你真正想要看的是能指引正确方向的正确指示器，而不是仅仅在偏离路线时能感到的颠簸。在这一岗位上，也是类似的情况，对于诸如代码覆盖度和项目速度之类的度量，我始终都能够理解它们的价值，但是我不能理解一个人怎样才能实际地收集到所有这些数据。
作为一名分析员，我爱上了建模。我边看边思考，发现图形化的模型控制了文档和沟通的方式。但是一旦进入到实现阶段，模型就总会过期。而且模型还正好没有处理开发者、测试者和运行中的关键顾虑。
在所有这些情形中，由于把整个团队的各开发环节连起来太困难了，我受到了挫折。我喜爱SCRUM（一个敏捷过程）中“单一产品待处理队列”的创意：你能在一个地方看到所有工作，但是人们实际使用的工具却都以它们各自的方法来分割工作。这些需求与那些工作有什么关系，与这边的模型元素，与那边的测试又有什么关系？还有，在这样的混合中，源代码又处于一个什么样的位置呢？
从历史的观点来看，当IT停止了对手工过程的自动化尝试时，我认为，已经“柳暗花明又一村”了。现在IT所询问的问题是“使用了自动化之后，我们怎么样才能再造核心业务过程？”这是IT开始交付真正的业务价值的时刻了。
人们常说“鞋匠的孩子没鞋穿”。这对于IT也很贴切。我们在忙于其他业务过程的自动化的同时，却在很大程度上忽略了我们自己。实际上，所有的以IT专业人士和团队为目标的工具仿佛仍然是对老的手动过程的自动化。那些过程在自动化之前需要很高的开销，在有了自动化以后，它们仍然有很高的开销。有多少次你参加的是一个1小时的项目会议，而会议的前90分钟却都在讨论谁的数字才正确呢？
现在，有了Visual Studio Team System，我们会很严肃地问“有了自动化，我们怎样才能再造我们的核心IT过程呢？我们怎样能消除这些优秀过程中的额外开销呢？我们怎样才能既让这些不同角色的每个人都能有更高的生产力，同时还能把他们整合成一个高效的团队呢？”
谁应该读这本书
本书为那些考虑在软件项目中使用VSTS的软件团队而写。这是一本关于为什么的书，而不是一本关于怎样做的书［1］。 VSTS身后的指导思想是什么？为什么这些观点以这些方式来表现？例如，为什么把这么多东西都叫作工作项？度量元仓库度量了些什么？你为什么要使用这些特定的报表？
我一次又一次地体验过：人们在知识、技能和经验上的不同使得软件项目启动时的条件也不一致。有的事情对于有的人来说是一个自证明的真理，而对于另一个人则是一个神话；有些事情对于有的人来说是常识，而对于另一个人则是个发现。各种功能角色往往已被固定在职业阶梯中，而这种对功能角色的自然强调使这一问题更加恶化了。我当然相信是有专家级的开发人员、专家级的测试人员、专家级的架构师、专家级的业务分析师和专家级的项目经理的，但是交付的客户价值要求的是各学科之间的协作。在与其他角色隔离的情况下，去努力优化某一个角色，并不一定会提升客户所能看到的结果的交付。
解决这一矛盾的一种方法是找一个现场教练（onsite coach）来领导团队通过一组一致的过程。教练很棒，但不是每个人都能享受这种奢侈能和教练一起工作。因为我不能发给你一个随需应变的教练，所以我就写了这本书。
本书不是用户手册那样的教程，不会一步一步地告诉你应该以怎样的顺序点击哪里。VSTS中已经带有大量关于这些主题的优秀文档，我会在适当的地方列出这些文档的引用。确切地说，本书提供了一个框架，让我们按照一种可以直接利用VSTS工具的方式来思考软件项目。实际上，我们开发VSTS正是为了能够以这种方式来管理软件项目。
本书也不是一个软件工程文献的纵览。在最近的40年中，已经有了几十种甚至上百种关于软件工程的著作。这里我就不对它们重述了，并且也不再全部包括那些其他著作已经包括了的材料。我预料到很多专家会批评说我的某些观点在今天是不言而喻的。不幸的是，正如Freud所指出的，不言而喻的东西往往根本没有人说。其结果就是：只有当发生了错误的争论时，团队成员之间在假设上的不同才能暴露出来。因此，如果你责怪我陈述了过多显而易见的东西，我承认的确如此。
我展示了足够的Team System理论和实践例子，目的是向大多数主流的IT项目和团队描述一个实际的过程。对于必须符合FAA（美国联邦航空管理局）的要求的航空软件来说，这一过程可能不够正式；对于驻扎在车库中的3个人的团队来说，这一过程可能又不够松散。
如何读这本书
VSTS所包含的过程指南被称作微软解决方案框架(Microsoft Solutions Framework，MSF)，其中所包含的核心概念就是一个基于团队同行的团队模型。团队模型还考虑到了不同尺度的专门化。MSF定义了在成功的项目中必须扮演的7类选民（选区），或者说视点，如图P1所示。MSF还包括了对于上调和下调伸缩性的建议。在本书中，我始终会强调这些视点，并使用下面这样的一个图标：
图P-1微软方案框架引入了一个团队同行的模型，锚定在一个成功项目所需要表现出的7个视点之上。用于CMMI过程改进的MSF把这7个视点细化为18个，而用于敏捷软件开发的MSF把产品管理和用户体验合并在了一起，从而使用6个角色实现了这7视点，它同时还提供了将它们减至为3个的指南
这本书是写给整个团队的。它展示信息的风格是为了能让所有团队成员感知彼此的视点。不过，本书还是针对角色来划分章节，这样就使读者能够根据自己对特定角色的需要而关注某些章节或略过某些章节。我已经努力将这些主题保持在这样一个级别上：既对团队的所有成员都有吸引力，又对任何人都不晦涩难懂（我的这一选择可能更会使某些人要批评我讲的过于简化）。在当今这个专业化的年代中，你与同事的专长各有不同，而你们之间的约定和对他们的预期也应该至少保持在这样一个级别上，我认为这很重要。如果你很忙，可以根据这些图标阅读那些与你最感兴趣的角色相关的主题。
文档提示
正如我所说的，这不是一本讲如何做的书。在那些需要VSTS的细节或它的文档的地方，你会看到一个文档提示，就像下面这个例子：
Microsoft Developer Network（MSDN）订阅
每套VSTS中都包括了一个微软开发者网络（MSDN）的订阅。请从链http://msdnmicrosoftcom/teamsystem开始，按照Reference→Product Documentation的链接向下走。对于有些术语，你可能想检查一下它们的用法。想要查询它们，请查阅MSDN的主题：
Development Tools and Technologies
Visual Studio Team System
Visual Studio Team System Glossary
译者注：若要访问中文MSDN中Visual Studio Team System，请用：
http://www.microsoft.com/china/msdn/vstudio/teamsystem/default.aspx 。
VSTS词汇表在中文MSDN中相应的主题为：
Visual Studio 2005
Visual Studio Team System文档
Visual Studio Team System 词汇表
http://msdn2.microsoft.com/zhcn/library/ms242882 (VS.80).aspx）我做出这样的选择是因为我假设在你读本书的大多数时间里，你没有坐在一台电脑前，你只是偶尔才会想要回到电脑桌前去做一些动手操作。当你只是阅读时，你可以跳过这些提示。
其他人的思想
我在本书中的目标是介绍VSTS背后的思想，但不是原样宣读这些思想。重新设计VSTS就是为了使不同的过程能够合适地应用到不同的组织和项目上。VSTS和本书都大量使用了软件社区已制定出的优秀实践。我已经在尾注中尽可能地包括了相应的资源。如果你对于这些参考书目没有兴趣，就不必去读这些尾注了。
在你开始之前需要对VSTS了解的内容
本书初稿的评审者曾经抱怨我没有把VSTS中有什么解释得足够清楚，因此我就把这个直接来自微软网站的产品介绍放到了下面的板块中。现在已经有了4个VSTS的客户端产品，并且以后可能还会更多，但是我并没有区分它们，因为价值是在Team Suite中的。当然，微软让你按菜单点菜的方式来购买功能，但我想保持简单。
因此，在我写到“VSTS”或“Team System”的时候，我所写的就是指Team Suite。
微软解决方案框架（Microsoft Solutions Framework，MSF）是VSTS的一部分，如图P2中的“过程指导”框所示。MSF在框外分为两种形式，并能定制成无数的变种。这两个标准形式是：
● 用于敏捷软件开发的MSF（MSF for Agile Software Development）
● 用于CMMI过程改进的MSF（MSF for CMMI Process Improvement）
稍后我会对这两种MSF描述得略微深入一些，但是基本上，如果你的组织对软件过程比较陌生，请从用于敏捷软件开发的MSF开始。如果出于地理上的分布、过程改进计划、一致性审计或期望通过CMMI评估等原因，你需要更为正式的过程的话，那么你应该考虑用于CMMI过程改进的MSF。
只有在有必要的时候，我才会区别这些产品，除此之外，我将保持关注于它们的公共概念。
图P2Visual Studio 2005 Team System由4个客户端产品和一个服务器产品组成
声明
最后，我需要澄清一下，本书中的观点仅是我个人的观点，并不一定是微软公司的观点。虽然我是微软的一名雇员，但是我的写作是我的个人行为，不是为了公司而写作。不要为了我在这里所表达的观点和所犯的错误而责备微软（除非你想告诉他们雇佣我是一个错误），请来向我抱怨。你可以直接来我的博http://blogsmircosoftcom/sam/与我讨论。
参考资料
［1］ 关于如何操作VSTS的书, 请参见Will Stott 和James Newkirk编写的《Visual Studio Team System Better Software Development for Agile Teams 》(Boston, MA: AddisonWesley, 2006)
致谢
很多人激励我编写这本书，他们给予了不寻常的帮助。我首先要感谢我的编辑Karen Gettman，感谢她愿意考虑一个第一次写作的人的愿望和提议。Ivar Jacobson和Cem Kaner是我的重要的导师，他们多年以来都在鼓励我写作。
接下来是Rick LaPlante，他还是我现在的老板。在Rick雇我作Visual Studio Team System的组产品规划师的时候，他在我身上下了注，现在他已经完全成了一个支持性的管理者。除了Rick之外，还要感谢几百个同事，正是他们把VSTS创造成现在这个产品。每一次和他们的接触都是并且将继续是一次思想的充电。
正如你将看到的，我很依赖于Granville (“Randy”) Miller和David J Anderson的工作，是他们创造了用于敏捷软件开发的MSF和用于CMMI过程改进的MSF。我们在创建MSF v4的实例时有过无休止的争论和发现，我从其中所学到的东西形成了你在这里读到的主要内容。
感谢我的合著者Juan J Perez，以及Personify Design的Kim Tapia St Amant为本书创造了尽可能多的丰富例子和演示。和他们一起工作非常愉快。
最后，我要感谢众多的审阅者，包括Jeff Beehler, James Behling, Charlie Bess, Rossen Blagoev, Rob Caron, Wendy Chun, Kevin P Davis, Cristof Falk, Linda Fernandez, Ken Garove, Bill Gibson, Martin Heller, Bijan Javidi, Yulin Jin, Cem Kaner, Chris Kinsman, Aaron Kowall, Clementino Mendonca, Thomas Murphy, Gary Pollice, Tomas Restrepo, Johanna Rothman, Joel Semeniuk, Will Stott, Dan Sullivan, David Trowbridge, Mike Turner, Kumar Vadaparty 和Peter Williams。AddisonWesley的Kim Boedigheimer, Ben Lawson和Michael Thurston在最后阶段给了我极大的帮助。如果没有所有这些审阅者的建议和意见，本书可能只有现在篇幅的一小部分。
Sam Guckenheimer
华盛顿州雷德蒙德
2006年1月
| 回书目 下一节 |
