内 容 简 介

本书以Visual Studio Team Foundation Server 2012为软件开发生命周期(ALM)的平台，着重从Scrum等敏捷方法和Visual Studio工程实践的角度诠释.NET开发人员如何充分利用敏捷方法和VS管理工具更快交付产品。书中提供最真实的开发技巧与最先进的敏捷实践，旨在帮助解决软件工程所面临的困境与挑战，有系统地终结浪费、改善透明度，让软件开发成为一种轻松愉快的工程过程。

本书适合.NET程序员阅读和参考，可以帮助他们更快构建更多价值的软件产品，提高用户满意度。

 

　　

前 言

　　七年前，我们将Microsoft Visual Studio进行了扩展，以包含应用程序生命周期管理(ALM)，使我们的几十万用户以及数万名微软同事的生活更轻松，生产力更高。2010年，当我们发布了Visual Studio 2010高级版、旗舰版、专业测试版以及Team Foundation Server之后，我们已经实现了成为广泛公认的行业领导的目标。2012年，我们给服务器补充了托管团队基础服务的公共预览，并开始更频繁地给软件团队提供更多价值。

　　过去七年中，我们从客户身上学到了很多东西。Visual Studio使得高性能的敏捷软件开发团队能够更频繁地发布更高质量的软件。它被广泛公认为提供给软件团队的市场领先的创新解决方案。我们系统地深入研究了浪费应用程序生命周期的主要根源，提升了团队广泛参与的透明度，并专注于最终用户的价值流。我们已经消除了角色之间不必要的筒仓，专注于建设一个多学科的自我管理的团队。下面是一些例子。

* 没有更多的无法再现。软件开发中浪费的最大一个来源是开发人员无法重现报告的缺陷。传统上，这就是所谓的“无法再现”bug。测试人员或用户提出一个bug，稍后收到“无法重现”或“它在我的机器上工作”或“请提供更多信息”或类似的响应。通常，这是Bug Ping-Pong持久战的第一次迸发，虽然软件没有得到改进，但产生了巨大的挫折感。

Bug Ping-Pong对地理分布的团队尤其困难。正如第1章和第8章详细介绍的那样, VS 2012缩短或消除了这场没有赢家的游戏。

* 不再等待构建建立。很多开发团队已经掌握了持续集成的实践方法，从而一天中能多次产生软件的定期构建，甚至是高度分布式的基于Web的系统。虽然如此，测试人员经常等待数天得到一个新的构建来测试，因为将此构建部署到现实生产实验室中很复杂。通过虚拟化测试实验室并将自动化部署作为构建的一部分，VS 2012使得测试人员能够每日或当日没有中断地获取新鲜构建。第7章将描述如何构建和实验室自动化。

* 没有更多的UI回归。最有效的用户界面(UI)测试往往是探索性的，无脚本的手动测试。然而，当bug修正后，往往很难说它们是实际已修复，还是仅仅没被再次发现而已。VS 2012通过捕获测试人员探索的操作日志并允许它转换成自动测试，从而消除了这种不确定性。现在，修复可以重新测试，并且自动化能够专注于实际观察到的bug，而不是猜想的bug。第8章涵盖探索和自动化测试。

* 没有更多的性能回归。大多数团队都知道失去客户最快捷的方式是缓慢的应用程序或网站。然而，团队不知道如何量化性能需求，因此，直到发布前才测试负载能力，这时修正发现的bug为时已晚。VS 2012使得团队能够尽早开始负载测试。性能量化并不需要提前进行，因为测试能够回答这个简单问题“什么变慢了？”从端到端结果，VS能够分析代码中的热路径，并直接为开发人员指出故障点。第6章和第8章涵盖性能分析和负载测试。

* 没有更多遗漏的变更。软件项目有许多活动部件，迭代越多，部件变动得越多。开发人员和测试人员很容易误解需求或者忽略变更的影响。为解决这个问题，Visual Studio专业测试版引入了测试影响分析。此功能比较任意两个构建之间的变更，通过查看构建之间完成的工作，并基于先前覆盖情况分析哪些测试覆盖了变更代码，从而建议运行哪些测试。第3章和第4章分别介绍了产品待办工作和变更管理，第6章到第8章从单元测试显示测试影响分析以及相应的安全网，构建自动化，和验收测试。

* 不再计划黑盒。过去，团队往往不得不猜测他们的历史速度和未来容量。VS 2012直接从Team Foundation Server数据库绘制这些并建立一个Excel工作表，允许团队查看冲刺中个人的负载有多重。然后，团队可以根据需要透明地转移工作。敏捷计划的例子在第2章和第4章讨论。

* 没有更多迟来的意外。敏捷团队，迭代递增地工作，经常使用燃尽图来评估他们的进展。不仅VS 2012自动化燃尽图，项目仪表板也从很多维度超越了燃尽图：需求、任务、测试、bug、代码改动、代码覆盖率、构建健康和障碍提供质量和进度的实时视图。第4章将介绍运行项目的“快乐路径”并讨论如何解决项目“臭味”。

* 不再担心旧版本。很少有软件项目是真正的“新建”，在新项目上开发全新的软件。更经常的情形是，团队扩展或改进现有系统。不幸的是，较早版本的工作人员往往已经无法解释他们留下的资产。VS 2012通过引入架构发现工具使得现有代码的使用更加容易。VS 2012在软件中显示这种模式，使我们能够自动执行减少或消除不必要依赖性的规则。这些规则可以成为签入政策的一部分，确保团队的“完成”定义能够防止意外的架构漂移。架构变化也能够被捆绑到bug或工作以保持透明度。第5章介绍现有架构的发现，第7章告诉我们如何自动化“完成”的定义。

* 没有分布式开发的痛苦。分布式开发是必需的，原因有很多：地理分布、项目复杂性和版本演变。VS 2012前瞻性回顾性地去除了分布式开发过程的痛苦。门控式签入在接受签入之前强制执行带有验证测试的干净构建。分支可视化允许回顾性地观察已应用的变更。代码变更和描述变更的工作项更新(例如，bug修复)都可见。可以直观地发现哪里已经变更以及哪里仍然需要提升。第6章和第7章告诉我们如何在分布式团队中使用源、分支和积压。

* 没有更多的技术筒仓。越来越多的软件项目使用多种技术。过去，团队往往不得不根据他们的运行时目标选择不同的工具。因此，.NET和Java团队无法跨筒仓共享数据。Visual Studio Team Foundation Server 2012通过分别为.NET和Java在Visual Studio和Eclipse集成开发环境(IDE)中提供客户端集成了二者。这样就将二选一的选择变成了兼容并蓄，双赢了。同样，第6章和第7章包含使用Java资产以及.NET的例子。

　　这些场景并不是详尽的清单，而是VS 2012开发动机的代表。所有这些都说明了简单优先级：减少浪费，提高透明度，加快终端客户的价值流。本书是为考虑使用VS 2012运行软件项目的软件开发团队而写的。本书更多的是关于根源而非方式。

　　本书总体上是为团队写的。它以一种帮助所有团队成员了解对方观点的方式展示信息。我一直试图保持主题能够吸引所有团队成员。我喜欢爱因斯坦的名言“尽量简单，而不是更简单。”我试着这样写。我希望你会同意并且在看完本书后向你的同事(也许是老板)推荐。

 

关于Visual Studio 2012

　　我所指的Visual Studio(或VS)，指的是完整的产品线。如下图所示，VS 2012 系列由一台服务器和一小部分的客户端工具组成，VS旗舰版上都有。

 

　　

　　Team Foundation Server(TFS)是ALM的主干，提供源代码控制管理、构建自动化、工作项跟踪、测试用例管理，报告和仪表板。TFS的一部分是实验室管理，扩展TFS的构建自动化，将物理和虚拟测试实验室集成到开发过程。

　　如果你只有TFS，那么可以得到一个叫Team Explorer的客户端，独立或者作为插件启动Visual Studio Professional IDE。Team Explorer Everywhere，一个用Java写的类似客户端，作为Eclipse插件启动。你还可以得到Team Web Access以及允许连接到Microsoft Excel或Project的插件SharePoint托管仪表板。

　　Visual Studio高级版添加了第6章中描述的围绕使用代码的场景。Visual Studio专业测试版尽管具有VS的名字，但实际上是一个IDE之外的独立应用程序，是为测试人员设计的。可以在第8章看到大量专业测试例子。VS旗舰版包括专业测试，增加了架构建模和发现，在第5章讨论。

　　还有丰富的合作产品，使用可扩展性在TFS上提供额外的客户端体验。下图显示一些第三方扩展的例子，启动MindManager、Microsoft Word以及Microsoft Outlook作为TFS的客户端。可以在www.visualstudiowidgets.com/找到一个目录。

　　当然，所有的客户端读取并输入数据到TFS，仪表板上的趋势面通常托管到SharePoint。使用 Excel Services或SQL Server Reporting Services可以自定义这些仪表板。仪表板示例是第4章的重点。

　　当然，在开发者中心还可以进一步了解VS。

 

　　

目  录

第1章  敏捷共识 1

敏捷的起源 1

敏捷的出现是为了处理复杂性 2

经验过程模型 3

新的共识 4

关于Scrum 5

潜在可上市 6

减少软件开发中的浪费 8

透明性 9

技术债务 9

一个例子 10

自管理团队 11

回到基础 11

小结 12

尾注 13

第2章  Scrum、敏捷实践和

Visual Studio 15

Visual Studio和过程制定 16

过程模板 16

团队 18

过程周期和TFS 19

发布 20

冲刺 21

由下而上的周期 25

个人开发准备 25

测试周期 26

每个周期对“完成”的定义 29

检查和调整 29

任务板 30

看板 30

为项目适配过程 31

地理分布 32

小结 34

尾注 34

第3章  产品所有权 37

什么是产品所有权 38

商业价值问题：花生酱 38

客户价值问题：死鹦鹉 39

范围蔓延问题：下沉的船 40

Scrum的产品所有权 41

发布计划 42

兴奋、满意和不满意：卡诺分析 44

客户验证 52

服务质量 57

安全和隐私 57

性能 58

用户体验 58

可管理性 58

需求有多少层次 60

工作分解 60

小结 61

尾注 62

第4章  运行冲刺 65

来自定义过程控制的经验 66

精通Scrum 67

团队规模 68

快速估算(计划扑克) 68

对比的类比 72

使用描述性而非规定性指标 72

使用仪表板回答日常问题 76

燃尽图 76

质量仪表板 78

Bug仪表板 82

测试仪表板 82

构建仪表板 83

选择和自定义仪表板 83

使用微软Outlook来管理冲刺 84

小结 85

尾注 86

第5章  架构 89

敏捷共识中的架构 90

检查和调整：涌现式架构 90

架构和透明度 91

可维护性设计 92

探索现有架构 92

了解代码 92

维护控制 98

了解域 101

小结 109

尾注 110

第6章  开发 111

敏捷共识中的开发 112

冲刺周期 113

每日周期中要警惕避免 113

保持代码库干净 114

在签入时捕获错误 114

搁置而非签入 119

代码协作 120

早期检测编程错误 123

测试驱动的开发提供清晰度 123

代码未经测试 125

通过改变数据来优化测试 127

将单元测试重用为构建验证测试 128

有冗余代码时 130

使用自动化代码分析捕获编程错误 131

捕获副作用 133

隔离意外行为 133

隔离生产中的根本原因 135

优化性能 137

防止版本偏差 140

版本控制什么 140

分支 141

并行工作在不同版本 142

合并及跟踪分支间的变更 144

使用Eclipse或直接使用Windows 

Shell 145

使工作透明 146

小结 147

尾注 148

第7章  构建和实验室 149

周期时间 150

定义“完成” 151

持续集成 152

自动构建 154

每日构建 155

BVT 155

构建报告 155

维护构建定义 156

维护构建代理 157

自动部署到测试实验室 158

建立测试实验室 159

在生产中是否能像在实验室中一样

正常工作 160

自动部署与测试 164

消除浪费 170

完成PBI 170

尽可能频繁地集成 170

检测流程中的低效率 171

小结 173

尾注 174

第8章  测试 175

敏捷共识中的测试 176

测试和价值流 177

检查和调整：探索性测试 177

测试和减少浪费 178

测试和透明度 178

测试产品积压工作项 179

最重要的首先测试 180

可操作的测试结果和错误报告 182

不再“无法再现” 184

使用探索性测试以避免错误的

信心 185

处理bug 188

哪些测试应该自动化 189

自动场景测试 189

使用HTTP测试 191

负载测试，冲刺的一部分 193

了解输出 197

诊断性能问题 197

生产-现实测试环境 198

报告 199

基于风险的测试 200

像工作项那样捕获风险 201

安全测试 202

小结 202

尾注 203

第9章  微软开发部门的经验教训 205

规模 206

商业背景 207

文化 207

浪费 208

债务危机 209

2005年之后的改进 210

做到并保持干净 210

集成与隔离 211

产品积压工作 212

迭代积压工作 215

工程原则 217

结果 217

敏捷共识行动 218

经验教训 218

社会契约需要重建 219

经验教训 219

庆祝成功，但不宣告胜利 221

Visual Studio 2012之路 221

尾注 223

第10章  持续反馈 225

敏捷共识在行动 226

小结 230

生活在混沌的边缘 231

尾注 232