Amazon畅销技术图书
　　微软公司选定培训用书
　　为准备使用VSTS的开发团队量身定做
　　本书论述了软件开发价值增加的思维方式。这一思维方式构成了VSTS的基础，包括VSTS的指导思想，为什么这些指导思想会以某些方式表现，以及它们如何才能与管理软件生命周期的过程紧密结合。本书如同一个现场教练，带领开发团队以一贯的流程走完整个软件生命周期。
　　读者通过学习本书能够了解使用VSTS所必需的知识，包括：
　　■ 价值增加的思维（相对于工作消减）在软件开发生命周期中的角色，以及“流”的意义和重要性。
　　■ 用于敏捷软件开发的MSF和用于CMMI过程改进的MSF的应用。
　　■ VSTS中用于计划和管理待处理队列（backlog）的工作项。
　　■ 多维的每日度量维护了项目的流，也为估计提供了参考数据。
　　■ 使用人物和应用场景来创建需求。
　　■ 使用迭代、可信任的透明度和无矛盾的度量来管理项目。
　　■ 使用价值增加的观点、面向服务的架构、约束和服务质量来进行架构设计。
　　■ 使用单元测试、代码覆盖度、特征分析和构建自动化进行开发。
　　■ 使用应用场景、服务质量、配置、数据、探索和度量来测试客户价值。
　　■ 高效地进行缺陷报告和缺陷评估。
　　■ 项目问题解析：识别和纠正共同的隐患和反模式。

无

为什么要写这本书
　　在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类选民（选区），或者说视点，如图P1所示。MSF还包括了对于上调和下调伸缩性的建议。在本书中，我始终会强调这些视点，并使用下面这样的一个图标：
　　图P-1微软方案框架引入了一个团队同行的模型，锚定在一个成功项目所需要表现出的7个视点之上。用于CMMI过程改进的MSF把这7个视点细化为18个，而用于敏捷软件开发的MSF把产品管理和用户体验合并在了一起，从而使用6个角色实现了这7视点，它同时还提供了将它们减至为3个的指南
　　这本书是写给整个团队的。它展示信息的风格是为了能让所有团队成员感知彼此的视点。不过，本书还是针对角色来划分章节，这样就使读者能够根据自己对特定角色的需要而关注某些章节或略过某些章节。我已经努力将这些主题保持在这样一个级别上：既对团队的所有成员都有吸引力，又对任何人都不晦涩难懂（我的这一选择可能更会使某些人要批评我讲的过于简化）。在当今这个专业化的年代中，你与同事的专长各有不同，而你们之间的约定和对他们的预期也应该至少保持在这样一个级别上，我认为这很重要。如果你很忙，可以根据这些图标阅读那些与你最感兴趣的角色相关的主题。
　　文档提示
　　正如我所说的，这不是一本讲如何做的书。在那些需要VSTS的细节或它的文档的地方，你会看到一个文档提示，就像下面这个例子：
　　Microsoft Developer Network（MSDN）订阅
　　每套VSTS中都包括了一个微软开发者网络（MSDN）的订阅。请从链接http://msdnmicrosoftcom/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/zhcn/library/ms242882　　(VS.80).aspx）我做出这样的选择是因为我假设在你读本书的大多数时间里，你没有坐在一台电脑前，你只是偶尔才会想要回到电脑桌前去做一些动手操作。当你只是阅读时，你可以跳过这些提示。
　　其他人的思想
　　我在本书中的目标是介绍VSTS背后的思想，但不是原样宣读这些思想。重新设计VSTS就是为了使不同的过程能够合适地应用到不同的组织和项目上。VSTS和本书都大量使用了软件社区已制定出的优秀实践。我已经在尾注中尽可能地包括了相应的资源。如果你对于这些参考书目没有兴趣，就不必去读这些尾注了。
　　在你开始之前需要对VSTS了解的内容
　　本书初稿的评审者曾经抱怨我没有把VSTS中有什么解释得足够清楚，因此我就把这个直接来自微软网站的产品介绍放到了下面的板块中。现在已经有了4个VSTS的客户端产品，并且以后可能还会更多，但是我并没有区分它们，因为价值是在Team Suite中的。当然，微软让你按菜单点菜的方式来购买功能，但我想保持简单。
　　因此，在我写到“VSTS”或“Team System”的时候，我所写的就是指Team Suite。
　　微软解决方案框架（Microsoft Solutions Framework，MSF）是VSTS的一部分，如图P2中的“过程指导”框所示。MSF在框外分为两种形式，并能定制成无数的变种。这两个标准形式是：
　● 用于敏捷软件开发的MSF（MSF for Agile Software Development）
　● 用于CMMI过程改进的MSF（MSF for CMMI Process Improvement）
　　稍后我会对这两种MSF描述得略微深入一些，但是基本上，如果你的组织对软件过程比较陌生，请从用于敏捷软件开发的MSF开始。如果出于地理上的分布、过程改进计划、一致性审计或期望通过CMMI评估等原因，你需要更为正式的过程的话，那么你应该考虑用于CMMI过程改进的MSF。
　　只有在有必要的时候，我才会区别这些产品，除此之外，我将保持关注于它们的公共概念。
　　图P2Visual Studio 2005 Team System由4个客户端产品和一个服务器产品组成
　　声明
　　最后，我需要澄清一下，本书中的观点仅是我个人的观点，并不一定是微软公司的观点。虽然我是微软的一名雇员，但是我的写作是我的个人行为，不是为了公司而写作。不要为了我在这里所表达的观点和所犯的错误而责备微软（除非你想告诉他们雇佣我是一个错误），请来向我抱怨。你可以直接来我的博客http://blogsmircosoftcom/sam/与我讨论。
　　参考资料
　　［1］ 关于如何操作VSTS的书, 请参见Will Stott 和James Newkirk编写的《Visual Studio Team System  Better Software Development for Agile Teams 》(Boston, MA: AddisonWesley, 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。AddisonWesley的Kim Boedigheimer, Ben Lawson和Michael Thurston在最后阶段给了我极大的帮助。如果没有所有这些审阅者的建议和意见，本书可能只有现在篇幅的一小部分。
　　Sam Guckenheimer
　　华盛顿州雷德蒙德
　　 2006年1月

Amazon畅销技术图书
　　微软公司选定培训用书
　　为准备使用VSTS的开发团队量身定做
　　本书论述了软件开发价值增加的思维方式。这一思维方式构成了VSTS的基础，包括VSTS的指导思想，为什么这些指导思想会以某些方式表现，以及它们如何才能与管理软件生命周期的过程紧密结合。本书如同一个现场教练，带领开发团队以一贯的流程走完整个软件生命周期。
　　读者通过学习本书能够了解使用VSTS所必需的知识，包括：
　　■ 价值增加的思维（相对于工作消减）在软件开发生命周期中的角色，以及“流”的意义和重要性。
　　■ 用于敏捷软件开发的MSF和用于CMMI过程改进的MSF的应用。
　　■ VSTS中用于计划和管理待处理队列（backlog）的工作项。
　　■ 多维的每日度量维护了项目的流，也为估计提供了参考数据。
　　■ 使用人物和应用场景来创建需求。
　　■ 使用迭代、可信任的透明度和无矛盾的度量来管理项目。
　　■ 使用价值增加的观点、面向服务的架构、约束和服务质量来进行架构设计。
　　■ 使用单元测试、代码覆盖度、特征分析和构建自动化进行开发。
　　■ 使用应用场景、服务质量、配置、数据、探索和度量来测试客户价值。
　　■ 高效地进行缺陷报告和缺陷评估。
　　■ 项目问题解析：识别和纠正共同的隐患和反模式。

近10年中，我一直鼓励Sam Guckenheimer写一部关于软件工程的书。“噢不，我还没有准备好。”他始终这样回答我。
　　随着Visual Studio Team System的发布，Sam再也没有借口了：他真的不得不解释一下他的那些软件工程的观点了，这样才能帮助人们弄懂这个体现了这些观点的产品。本书的优点在于实验课程和理论占据了相同的分量，既不是整本的产品广告，也不是对于软件工程的哲学进行的一次含糊的讨论。我喜欢书中那些具体的例子：它们使得概念变得有生命了。
　　本书中的一个关键概念是价值增加的过程。Sam相信我们在与软件打交道的方式上面临着一个思维方式的变迁，这看来是正确的。工作消减的思维方式已经给软件开发过程带来了很多问题，并最终导致项目失败的比例很高。价值增加的思维方式是否能够解决这些问题而又不会造成新的问题呢？当然，这还需要我们拭目以待。
　　过去，软件度量的实践没有充分发挥其潜力，很大程度上是因为数据收集的成本很高。正如Sam在本书中所解释的，使用工具进行日常活动使得数据收集不再痛苦，这也为有意义的度量开创了一组新的机会。Sam所做的还不止这些；他还运用一些来自精益（lean）项目管理的更有趣的技术，来演示如何以日报为基础对软件项目进行问题解析。这也使我们能够可靠地应用价值增加的过程。
　　近10年来，很多思想都渗透到了软件工程的不同领域，包括编程、用户体验、测试和架构方面。Sam把这些思想中最好的内容聚集在一起，应用到整个的软件生命周期中。
　　我相信你会像我一样喜欢这些内容。
　　Ivar Jacobson博士
　　Ivar Jacobson Consulting LLC

Sam Guckenheimer Juan J.Perez：Sam Guckenheimer Juan J.Perez: Sam Guckenheimer 曾经是VSTS的首席客户代言人，负责VSTS外部设计的整个过程。本书描述了他对软件项目思考方式的一个框架，这一思考方式能够得到VSTS工具的直接支持。本书运用基本理论和实际例子为IT项目描述了一种现实的过程。

苏南 贺洁：暂无简介

对于软件过程的实践，存在着敏捷过程和以CMM/CMMI为代表的正式过程这两大黑白分明的阵营。本书从一个崭新的、客观的高度来看待这两大阵营之间的争论，使你了解到这黑白两色不过是五彩光谱的两端；没有正确的过程，只有适合的过程。
　　作为VSTS的主要设计者，作者一直站在软件工程领域的最前沿。本书不仅包括了最新的软件工程领域的思想和概念，还为软件开发提出了一种崭新的思维方式，这便是价值增加。价值增加是本书的核心思想，同时也是VSTS的核心设计理念。
本书不是一本讲述如何具体操作VSTS的书，它所讲述的重点是VSTS的思想及其实践。在理解了VSTS的思想之后，你才能够根据自己项目本身的特点正确地使用VSTS，发挥出VSTS最大的潜力，使你的软件项目顺利地进行，为客户提供可感知的价值。
　　本书理论与实践并重，图文并茂，运用大量实例详实地论述了如何将最现代的软件工程思想和价值增加思想应用到需求、项目管理、架构设计、开发和测试等软件开发生命周期中。
　　如果你正在使用VSTS或计划使用VSTS，本书能够帮助你了解如何在软件开发过程中运用VSTS。如果你并不使用VSTS，书中丰富的具体实例也能帮助你对现代的软件工程思想有一个透彻的认识，并且对于管理软件开发也有指导意义。
　　感谢作者Sam Guckenheimer先生。在本书的翻译过程中，他回答了我们很多关于对原文的理解和文化背景方面的问题。感谢本书繁体版的译者蔡焕麟先生，他在网上分享了一些本书的章节和翻译心得。这些都给本书的翻译工作提供了参考和启发。
　　参加本书翻译的人员除封面署名外还有尚计升、史红伟、祝国志、张峰峰、张文军、张艳军、王小财和周宝华。本书翻译力求忠于原著，但由于时间仓促，译者水平有限，翻译的错误和不妥之处在所难免，欢迎广大读者批评指正。
　　苏南
　　2006年11月于北京

译者序
序言
前言
第1章价值增加的思维方式1
11思维变迁2
111有待和谐的三股力量2
112什么软件值得构建3
12思维方式的对比4
13对流的关注6
131与工作消减的对比8
132透明度10
14一个工作项数据库12
15使过程适合于项目19
16小结21
参考资料21
第2章价值增加的过程24
21微软解决方案框架25
22迭代27
221为什么迭代27
222长度29
223不同的视野，不同的粒度30
224优先排序30
225修改过程32
23风险管理33
24让过程适合项目34
241自适应与计划驱动35
242要求的文档与隐含的知识36
243隐式与显式的审核关卡和管理模型37
244审计与法规关注39
245规定的组织与自组织39
246一次一个项目与一次多个项目40
247地理边界与组织边界42
25小结43
参考资料43
第3章需求46
31什么是你的愿景47
311战略项目48
312自适应项目48
32何时细化需求49
321需求是易变质的49
322谁关心需求50
33人物和应用场景51
331从人物开始51
332应用场景53
333研究技术54
334提早具体化55
335故事板57
336应用场景的宽度58
337客户验证59
338制定应用场景60
34人物、应用场景及它们的替代术语61
341参与者和用例61
342用户故事62
35兴奋点、满意点和不满意点62
36服务质量63
361安全性和隐私64
362性能64
363用户体验65
364可管理性65
37卡诺分析66
371技术接受生命周期68
372收集数据69
38小结70
参考资料71
第4章项目管理73
41理解偏差74
42使用描述性的而非规定性的度量元76
43项目健康的多个维度79
44回答日常问题81
441剩余工作82
442项目速度84
443计划外工作85
444质量指示器85
445缺陷率88
446重新激活89
447缺陷的优先级90
448实际质量与计划速度92
45估计迭代93
451自顶向下93
452自底向上94
453精细化95
454 估计的质量96
455回顾97
46优先分配98
461优先分配的练习98
462让优先分配有效率：红线101
463在优先分配中发生了什么102
464逐步增强和解决问题103
465迭代和优先分配103
47让审计者满意104
48小结106
参考资料107
第5章架构设计108
51架构的价值增加观点109
52面向服务的架构109
521Web服务和SOA111
522契约优先的设计111
ⅩⅤⅡ53自由度的约束111
531基线架构112
532验证架构决策113
533精细化基线113
534参考架构114
54 VSTS和面向服务的架构116
55服务质量的理念117
551安全性119
552性能119
56公民权理念119
57针对运行而设计120
58小结122
参考资料122
第6章开发124
61开发的价值增加观125
62从开发人员的视点看质量125
63使用测试驱动的开发来确保需求的清晰126
64通过自动和手动代码评审来解决编程错误128
641自动的代码分析129
642手动的代码评审131
65用单元测试和代码覆盖度提供立即的反馈132
651先测试还是先编码133
652代码覆盖度134
66使单元测试更好135
661使用数据137
662配置137
663构件集成测试138
664构建确认测试138
665性能调整141
67防止版本扭曲143
671签入143
672搁置146
673分支146
674哪些文件需要版本管理146
675自动化构建147
68让工作保持透明151
69小结152
参考资料152
第7章测试154
71测试的价值增加观155
72基本问题157
73我们交付了客户价值吗158
731自动应用场景测试161
732让你的测试与UI变更无关164
74服务质量适合使用吗165
741负载测试165
742安全性测试169
743易用性测试170
75我们测试了变更吗170
76我们没测试过什么吗171
761需求171
762代码172
763风险174
77软件在生产环境和实验室环境中运行一样吗176
ⅩⅤⅢ78我们测试的足够吗178
781定义“足够好”178
782探索测试179
783为发现而测试180
784 错误的自信181
79我们什么时候应当测试181
791签入循环183
792每日构建循环184
793验收构建循环184
794迭代循环184
795项目循环186
710哪些测试应当自动化186
711我们的团队或外包团队的效率怎么样187
712小结187
参考资料188
第8章报告缺陷190
81警示性的故事192
82软件缺陷的生命周期193
821报告缺陷就像写新闻195
822主观数据198
823客观数据199
824评估数据200
825计划202
83小结202
参考资料202
第9章项目问题解析203
91低估205
911不均匀的任务分解206
912架构盲点206
913范畴蠕变208
914不充分的缺陷分配210
915资源漏洞210
92开发实践过于松弛211
921构建失败211
922不充分的单元测试212
923重新激活214
924虚报214
93测试通过了，解决方案却不能工作215
931高缺陷发现率216
932测试失去时效性217
94解决方案停留在测试218
941测试失败218
942过少的测试219
95小结221
参考资料221
第10章总结222
101预料中的批评223
102再论价值增加224
参考资料226