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

　　第1章

　　敏捷共识

　　危机不是用来浪费的。

　　——保罗·诺默尔（Paul Romer）

　　战争和经济衰退成为经济以及多年前已经逐步发展起来的工程趋势的重点。2007—2010年的经济大衰退是一个很好的例子。2008年，丰田，这家全球最年轻的汽车制造商，成为市场的领跑者，因为它在六年前就预测到此次大衰退。1 接着，2009年，三个美国汽车制造商中的两个遭遇破产，第三个侥幸逃脱。此次危机的出现凸显了底特律汽车制造商不能适应几十年来一直可见并有记录的富有竞争力的做法。1990年，沃麦克（Jim Womack）和他的同事在他们精心研究的书籍《改变世界的机器》（The Machine That Changed the World）中创造了术语“精益”（Lean）来描述丰田发明的新式工作方法。2到2010年，精益已经成为经营业务的基本要求。《纽约时报》的头条新闻“G.M. and Ford Channel Toyota to Beat Toyota”3。

　　敏捷的起源

　　软件公司，当然也在2000年2月到2008年10月间纷纷破产，内部IT组织最近也面临挑战以证明其商业价值。在此期间，许多业界领袖都在探讨精益如何才能对软件工程产生同样重大的影响。

　　精益是一种“敏捷流程”。2001年的一个周末，17个软件精英召开会议讨论“轻量级方法”，用它来代替常用的重量级的开发流程。在周末结束时，他们成立了敏捷联盟，最初主要以“敏捷宣言”为主题。4

　　十年后，在2010年对来自91个国家的4770名开发人员的研究中，90%的受访者在某种程度上使用敏捷开发实践的组织中工作（比上一年的84%有所提高）。5 与敏捷初期相反，引入敏捷实践的最常见拥护者现在都处于管理岗位。现在，敏捷是主流。Forrester 研究公司认为：

　　敏捷的采用是现实的。各行各业的组织越来越多地采用敏捷原理，软件工程师和项目组其他成员都正在学习敏捷技术。6

　　似乎每个行业分析师都主张敏捷，每个企业执行官都拥护它，每个人都跃跃欲试，希望尝到敏捷的甜头。

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

　　在先前的数十年中，管理者和工程师一致认为软件工程好比桥梁工程或设计房子。例如，当建造桥梁、道路或房子时，你可以放心地研究数百个非常类似的例子。起始条件、需求、技术以及期望的结果都必须充分理解。事实上，大部分时间都是建筑经济学在指引我们按照前一个非常像的成熟计划建造当前的房子或桥梁。在这种情况下，需求已知，技术已知，所以风险很低。

　　只需要将这些情况添加到一个已定义的过程模型，根据先前实践过的基线提前设计好步骤，基线源自构建先前类似例子时所遵循的过程。

　　商学院和工程学院所教的大部分过程模型，比如项目管理知识体系（PMBOK），7就是定义的过程模型，假设你知道完成项目需要做哪些任务。

　　软件很少这样。对软件来说，如果已经有人构建了一个系统，正好满足你的需求或者很接近你的需求，那么你可以获得它的商业授权（或者甚至免费）。明智的企业不会花钱构建能够以更经济的方式购买的软件。成千上万的软件产品可以发放商业许可，如果你需要的已经有了，那么购买软件产品几乎总是更便宜的做法。

　　因此，值得投资的软件项目是那些之前没有做过的项目。这对于要遵循的过程具有重大意义。Scrum的联合创始人施瓦伯（Ken Schwaber）修改了斯泰西（Ralph D. Stacey）所著的《策略管理与组织动态》（Strategic Management and Organisational Dynamics）中的图，用它来解释管理背景。斯泰西将管理情况分为四类：简单、繁杂、复杂以及混乱（如图1.1所示）。8

　　当需求一致而且充分理解技术后，就像建房子或桥梁那样，项目就落入简单或者繁杂区域。从理论上说，这些简单以及繁杂的区域也包括简单、低风险的软件项目，但正如我前面所说的那样，因为它们之前已经完成，所以不会投资。

　　当需求不一定一致或者技术不为人所熟知时（至少对当前团队来说），项目就落在复杂区域。这正是许多软件项目投资的地方，因为这是竞争性业务差异的最大机会。

　　图1.1  斯泰西矩阵区分了简单、繁杂、复杂以及混乱管理场景，是Scrum和其他敏捷实践的灵感来源

　　经验过程模型

　　因为不确定性，这些项目被放入斯泰西的复杂类，常称为“混沌的边缘”。不确定性也使得规定的过程模型非常不适合这些项目。在这些情况下，与其制定一个已知会变的详细计划，还不如创建更流畅的选项，尝试该模型非常有效，检查结果，并根据经验调整下一个步骤。事实上，这正是所谓的“经验过程模型”，来源于有流程控制的产品开发和制造行业。9

　　经验过程控制的一个日常例子是恒温器。我们不用每小时都查看天气预报并根据预期温度的甘特表设置加热器和空调。相反，我们依赖于一种简单的反馈机制，在它过热或过冷时微调温度。精密的系统可能会考虑响应的延迟，例如，在预计人多时调低礼堂温度，或者在预计寒流时加热，根据实际温度做出调整。这就是一个基于“检查和调整”的简单控制系统。

　　新 的 共 识

　　由于软件经济学一直偏爱复杂的项目，所以经验模型越来越多地被应用于软件过程。自1992年以来，敏捷、精益、Scrum、10 Kanban、11 约束理论、12 系统思考、13 极限编程（XP）以及14 基于流程的产品开发15，这些形成了一个趋势。所有这些重叠并融合为软件工程的新范式。没有一个术语能够概括这个新兴范式，不过，为了简单起见，我将其称作“敏捷共识”。

　　敏捷共识强调三个基本原则，彼此相得益彰。

　　1.  价值流，这里，价值由资助或使用该项目的客户定义。

　　2.  持续减少阻碍流的浪费。

　　3.  透明，使团队成员能够持续改善前两项。

　　这三项原则相辅相成（如图1.2所示）。“价值流”能够实现透明，便于我们衡量什么对客户来说是重要的（即，潜在可上市的软件）。“透明”使我们能够发现浪费。反过来，减少浪费加速了流，能够实现更大的透明度。这三个方面形成合力，就像一条凳子的三只腿。

　　微软的Visual Studio Team System 2005及其后来的版本都属于支持软件团队应用这些实践的第一代商业产品。Visual Studio 2012 （VS 2012，微软去掉了单词“Team System”）取得了另一个伟大的飞跃，旨在创建透明度、改进工作流及减少软件开发中的浪费。VS 2010也是解决端到端敏捷工程和项目管理实践的首批产品之一。我们将在后文看到，VS 2012通过他们提供了一个引人注目的工作流。关键的一套实践来自Scrum。

　　图1.2  价值流、透明和减少浪费是敏捷共识的基础

　　关于Scrum

　　正如Forrester研究公司最近发现的那样：“临到选择敏捷方法时，Scrum无疑是首选。”16 Scrum凭借三个因素领先于竞争对手。Scrum已经获得认可，因为它很容易将价值流、减少浪费以及透明度的原则付诸实践。

　　Scrum确定了三个环环相扣的节奏：版本或产品规划；冲刺（一般为2～4周）；每天。

　　对于每个节奏，它规定了具体的会议和会议的最长时间，以保持会议时间在项目总时长的10％以下。为确保价值流，每个冲刺生成一个潜在可上市的软件增量，交付产品积压工作中的功能特性（以可正常运行的形式）。图1.3显示了这个周期。17

　　Scrum的核心是自我管理团队这个概念。自我管理团队以透明的方式使用可用指标来控制流程中自己的工作和提高自己的效能，不依赖传统项目管理的传统分级结构。鼓励团队成员在任何需要的时候做出改进以减少浪费。冲刺节奏从形式上确保了至少每月“回顾”一次以识别并优先排列可行的流程改进。Scrum将此周期描绘为“检查和调整”。 尽管比恒温器更微妙，但想法相似。对实际过程的观察及其结果驱动着流程的增量变化。

　　图1.3  Scrum方法中间的这个图是从管理角度对价值流的最好说明

　　潜在可上市

　　Scrum也能通过在每个冲刺结束时规定交付可运行软件的“潜在可上市增量”来实现透明度。例如，电商网站的工作团队可能会将冲刺集中于目录搜索。如果没有可行的签出过程，网站就不能完成，实际上不可上市或不可公开部署。不过，如果目录搜索可用且运用了产品数据库、业务逻辑和显示页面，它就是一个合理的潜在可上市的增量。项目干系人和团队双方可以评估这次冲刺的结果，提供反馈信息，在下次冲刺之前提出一些修改建议。根据这些修改，产品负责人可以调整产品积压工作，团队可以调整其内部流程。

　　增强软件的价值流

　　敏捷共识的中心是对流的强调。客户价值流是对交付系统的主要衡量。安德森（David J. Anderson）在《软件工程的敏捷管理》中总结了这个观点：

　　流意味着交付系统一直都有稳定的价值流。客户价值功能通过这样的转换阶段和稳定的流通，随着可工作代码的交付而定期实现。18

　　在这种模式下，不以计划任务的完成作为衡量进展的主要指标，而是计算交付的价值单元。

　　Scrum引入了“产品积压工作”的概念，即“产品可能需要的所有特性的优先级列表。”19这是一个由产品负责人基于项目干系人需求来维护的需求排名列表。产品积压工作包含对预期客户价值的定义。产品积压工作将在第3章中深入介绍。

　　产品积压工作提供了价值流测量标准。与Scrum一致，Visual Studio 2010提供一个总是可见的产品积压工作以增强可上市客户价值流的沟通。产品积压工作是项目干系人和开发团队之间针对下一个增量构建的当前协定，是项目干系人可以理解的术语。通常情况下，产品积压工作中的事项被写成用户故事，详情参见第3章。图1.4中的报告显示了产品积压工作以及产品积压工作的测试状态。冲刺进度鸟瞰图使团队能看到产品积压工作中的工作项当前的流动情况和阻塞情况。第4章中将讨论详细显示进度和障碍的通用仪表板。

　　图1.4  Stories Overview报告中行显示每个产品积压工作项

　　减少软件开发中的浪费

　　价值流的敌人是浪费。这种对立相当强烈，使得减少浪费是精益最受广泛认可的一方面。精益之父丰田的大野耐一，开发了muda （日语“浪费”）、mura（“不一致”）以及muri （“不合理”）分类，并使之成为常见的商业术语。20 大野归纳出七种类型的浪费以及减少每种浪费的方法。Mary和Tom Poppendieck夫妇在他们的处女作中将浪费分类引入软件行业。21 表1-1显示了这种分类的升级版，它提供了一个有价值的思考软件开发过程中阻碍的视角。

　　表1-1  大野耐一的浪费分类，升级到软件开发实践

　　浪费

　　在制品

　　已部分实现的用户故事、bug债务及未完成的工作。需要多加处理，产生开销和压力

　　生产过剩

　　团队创建低优先级的功能，并使其直观易懂。这项工作挤压了高优先级的工作能力

　　额外处理

　　bug债务、再激活、分类、冗余测试、再学习别人的代码，处理已中断的依赖性

　　交接

　　角色、团队、部门等之间的交接

　　动态

　　管理工具、访问权限，数据传输、实验室设置，并行发布工作

　　等待

　　延迟、阻塞bug、未完成的新入组件或依赖关系

　　修正

　　代码的废弃和返工

　　不一致

　　不均匀

　　不同的工作粒度，产生流的多样化

　　不一致

　　对“完成”的不同定义，过程变化使得对“潜在可上市”的预估变得不可靠

　　不合理

　　荒谬

　　超出范围所造成的压力

　　不合理

　　期待英勇行为和承诺英勇行为

　　负担过重

　　过多开销所造成的压力

　　与大野的分类相一致，“在制品”“交接”“动态”及“等待”在软件开发中经常被忽视。尤其是涉及很多专家角色时，浪费以很多不易察觉的方式出现。正如贝克（Kent Beck）所发现的那样：“价值流越大，越需要各个活动间的转换。”22一些转换需要几秒或几分钟，比如开发人员在编码和单元测试周期中所花的时间。其他转换往往需要几天、几周或者几个月。所有微不足道的延迟都会滚雪球一般累加起来。

　　透明性

　　Scrum和所有敏捷过程都强调自我管理团队。成功的自我管理需要透明度。透明度，反过来，需要开销最小的测量。任务中剩余工作的燃尽图是早期透明度图标。Visual Studio进一步借此想法来提供仪表板，不仅测量任务，而且测量质量的多维指标。

　　Visual Studio启动并利用了该过程，捆绑源代码，测试工作项和指标。工作项包括项目需要跟踪的所有工作，比如脚本、开发任务、测试任务、错误以及阻碍。这些都能够在Team Explorer，Team Web Access，Visual Studio， Microsoft Excel或者Microsoft Project中查看和编辑。

　　技术债务

　　2008年，金融行业的困境使世界经济陷入过去70年来最急剧的经济衰退。经济学家广泛认同，问题出自一个影子银行系统，被阴暗的衍生品所隐藏的未公开的和不可测的金融债务。幸运的是，这场危机使立法者记住了美国最高法院大法官布兰迪斯（Louis Brandies）的话：“据说，阳光是最好的消毒剂，灯是最高效的警察。”23

　　对于软件团队来说，这些未知债务对应的是技术性债务。技术债务是指需要完成以实现潜在可上市阈值的工作，比如，修正bug、单元测试、集成测试、性能提升、安全加固或者为可持续性进行的重构。不幸的是，技术债务是常见的浪费形式。意料之外的技术债务可以毁掉一个软件项目，导致不可预测的延迟、成本以及后期的取消。和意外的金融债务类似，技术债务往往直到不可挽回时才会被揭示或考量。

　　技术债务的问题表现为妨碍项目干系人看到软件实际处于潜在可上市状态这样的事实。基于此，Scrum规定必须根据团队同意的“完成”定义交付每个产品积压工作项。

　　关于这点，将在第2章更详细地讨论。像大法官所说的灯那样思考透明性，它使得警察变得可有可无。同时，对“完成”的共同定义以及进度的透明视图可以防止技术债务日积月累，使团队和项目干系人能够评估团队的真实速率。

　　一 个 例 子

　　考虑使一个新的build可用于测试所付出的努力。或者考虑一个报告已修正，然后又不得不重新激活的bug的处理成本。或者考虑为最终被砍掉的需求规范。所有这些浪费对软件项目来说很常见。

　　VS 2012致力于减少软件开发过程中浪费的主要来源。VS Team Foundation Server中的构建自动化允许连续或者定期的构建，“封闭签入”能够在接受修改代码之前强制构建。Lab Management能够自动将这些构建部署到虚拟测试环境。这些将在第7章中讨论。

　　浪费的一个极端例子是“bug乒乓”。每个测试人员或者产品负责人都有着说不完的故事，用细致的描述提交bug，从程序员那里却只得到一个“无法重现”的响应。这种“无法重现”响应有很多种变体，比如“需要更多的信息”或者“在我的机器上正常”。这通常会导致一个重复循环，即当测试人员和程序员试图隔离错误时，会涉及各种类型的浪费。这样的循环往往会导致团队沮丧、怨声载道和士气低落。

　　bug乒乓的发生不是因为测试人员或者开发人员不胜任或者懒惰，而是因为软件错误常常很难隔离。

　　一些错误可能仅出现在成千上万次的异步事件发生之后，精确的重现序列无法确定重建。这样的bug通常是手工或者探索性测试发现的，而不是通过测试自动化。

　　测试人员归档bug时，VS 2012自动调用以下六个机制从故障隔离中消除猜测。

　　1. 所有测试人员与被测软件的交互均按照规定的测试步骤（如果有的话）记录在action log中。

　　2.  full-motion video记录测试人员的所见，按测试步骤时间索引。

　　3. Screenshots高亮显示测试人员在顺序过程中需要指出的任何东西。

　　4.  System con？gurations由测试环境中涉及的机器自动捕获。

　　5.  IntelliTrace log记录应用程序事件以及服务器上执行代码的顺序，使将来的调试能够基于这个实际执行历史。

　　6.  Virtual machine snapshots记录发生故障时测试环境中所有机器的实际状态。

　　消除bug乒乓是最明确的方法之一，VS 2012减少了过程工作，并允许快速周转和小批量测试。另一个是测试影响分析，建议基于已完成工作和历史代码覆盖率为每个构建做最高优先级测试。详细介绍参见第8章。

　　自管理团队

　　过去20年中，已经有很多关于软件开发管理概念的论述。例如，我们来考虑如下来自IBM红皮书的引文：

　　开发治理解决的是组织范围内的测量规程，其目的是在开发规程内推动一致性规程评估，以及使用一致性控制机制。[重点]24

　　大多数讨论都在传达一种偏见，即软件质量中的问题可以追溯到整个开发过程缺少集中控制。如果我们更好地度量开发人员的活动，从道理上讲就可以更好地控制他们。敏捷共识对命令和控制采取了一种非常不同的态度。将如下分析与上述引用对比：

　　丰田一直认为，一线员工并非乏味的制造业中无足轻重的成员，相反，他们是问题的解决者、创新者和变革推动者。美国公司依靠专家提出过程改进，而丰田给予每个员工技能、工具以及发生问题时解决问题的权限，防止发生新问题。其结果是，年复一年，丰田相比其竞争对手而言能够从员工那里得到更多。这就是管理正统的力量，以致美国汽车制造商在用尽对丰田成功的所有其他解释（日元升值、训练有素的劳动力、日本文化、优越的自动化）之后终于承认，丰田的真正优势是能够利用“普通”员工的智慧。25

　　态度上的差异也达到最大值。“普通”员工——软件团队的成员——能够针对如何做好本职工作做出最佳判断。他们需要工具、适当的过程和有利的环境，而不是命令和控制。

　　精益把治理换了一个角度，相信团队会齐心协力并使用度量透明度，使得团队可以提高价值流并减少浪费。在VS中，这种透明度很重要，对软件团队及其项目干系人都可用。指标和仪表板是团队用来检测自己过程及调整自己工作方式的工具，而不是为控制上述行为而设计的工具。

　　回到基础

　　我们非常认同精益专家沃麦克（Jim Womack）的话：

　　精益思想的关键出发点是价值。唯有最终客户才能定义价值。26

　　与软件相似，敏捷共识改变了我们的工作方式，专注于客户价值，减少阻碍价值流的浪费，并且做到透明沟通、度量和改进过程。汽车工业花了50年吸取精益的经验教训，直到客户和投资者失去耐心。2009年年中，在通用汽车破产保护的那天，公司首席执行官亨德森（Henderson）在底特律举行新闻发布会并发表如下讲话：

　　在新通用汽车公司，我们打算一切以客户为中心。我们将执着于此，因为如果这一点做不好，其他将无从谈起。27

　　六个月后，通用汽车失守，亨德森离职。退出自己一手造成的底特律困境可能比较容易，但是处于软件行业，我们自己也背负着大量的技术债务。这些技术债务同样使许多首席信息官的工作付之东流。

　　……

第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

第7章  构建和实验室 149

第8章  测试 175

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

第10章  持续反馈 225