对于“如何保障软件质量”这个问题，极限编程给出的答案是：靠自动化测试保障软件可观察的外部质量，靠重构保障软件内部设计质量。正如前文所说，在通常为期数月的项目交对于“如何保障软件质量”这个问题，极限编程给出的答案是：靠自动化测试保障软件可观察的外部质量，靠重构保障软件内部设计质量。正如前文所说，在通常为期数月的项目交付过程中，能保证不断增加的自动化测试用例始终处于成功状态就已属不易，能持续关注和改进内部质量的团队更是罕见。极限编程保障这些严格的纪律落到实处的办法，是一系列配置管理的实践。
软件配置管理（Software Configuration Management，SCM）也称为变更管理，包括标识变更，控制变更，保证恰当地实施变更，以及向其他可能的相关人员报告变更等活动，其目的是“协调软件开发以最大限度地减少混乱”[105]。在软件从无到有被开发出来的过程中，最核心的变更就是对源代码的添加、修改和删除。在一支软件开发团队中，每个程序员都会对代码做自己的变更，从而产生一个独一无二的代码版本；同时程序员们又会将各自的代码版本合并成团队共同的版本，以便最终发布软件。因此配置管理也常被称为“源码控制”（source control）或“版本控制”（version control）。
配置管理常用树形结构作为比喻：整个团队共同拥有的代码版本被称为“主干”（trunk）；从主干复制出来，专门承载特定人员、特定目的变更的代码版本则被称为“分支”（branch）。在分支上发生的变更只对使用该分支的特定人员可见，对整个团队是不可见的，因此需要通过提交（commit）或合并（merge）等操作将其与主干同步。由于同一时间可能有多个分支在发生变更，且多个分支的变更可能影响同一个文件，因此提交和合并都有可能遇到冲突（conflict）。极限编程的配置管理实践，最具特色的部分就体现在看待主干和分支的态度上。
首先，极限编程提倡采用单一代码库，而不采用多分支开发：程序员可以在一个临时分支（包括在自己电脑上签出的本地代码库）上做开发，但临时分支与团队共有的主干版本应该频繁保持同步，两者不同步的状态不应该超过几个小时[106]。这个实践要求程序员非常频繁地向整个团队提交他们的工作进展，极限编程的团队协作方式（结对编程、轮换结对等）对频繁提交也起到了促进作用。但即使没有结对编程，单一代码库仍然是一个很容易检查、度量和可视化的实践，如果有必要的话，团队领导者可以从配置管理工具（如CVS、Subversion）上很容易地了解到每个程序员是否每天至少有一到两次提交，从而大致了解临时分支与团队主干的同步情况。容易检查、度量和可视化，是极限编程中这一系列配置管理实践的共同特征，也是这些实践能成为纪律保障机制的重要原因。
当程序员能够习惯每天数次提交最新的代码修改，极限编程提出了更进一步的要求：他们不仅应该随时保持团队主干版本的更新，而且应该随时保持团队主干版本的高质量，也就是说，所有自动化测试都应该成功。Martin Fowler在2000年9月题为“持续集成”的文章里介绍了ThoughtWorks一支项目团队的实践：以很高的频率（每天多次）构建整个软件并执行自动化测试[7]。后来Fowler更加明确地阐述了持续集成的实践方式：每当有人向团队主干版本提交新的修改，立即执行完整的软件构建过程，将源代码编译、打包成可执行的状态，并执行所有自动化测试用例[8]。
当持续集成得到严格执行时，也就意味着只要软件代码发生一点变更，持续集成系统就会每天多次全面、自动地测试整个软件。这个机制能有效地保障软件的质量，并且测试用例也不会因为长期失去维护而大面积失效。但如何严格执行持续集成是一个难题。Fowler指出持续集成的实施需要流程和技术的双重保障[9]。
- 从流程上，持续集成的工作方式要求开发者遵循一系列具体的操作规范，尤其是在开始编程之前更新本地代码副本，结束编程任务之后在本地执行完整构建，提交代码之后确保团队主线上的构建成功。
- 从技术上，持续集成的工作方式需要构建自动化、测试自动化、部署自动化等技术手段的支持，并且通常需要用到专门的持续集成服务器工具。
持续集成在版本控制的基础上，用一组流程与技术手段对软件的变更过程进行控制，对接纳变更的方式、保障变更质量的手段、变更通知的机制都给出了明确且可操作的答案。从这个意义上，持续集成应该被视为极限编程方法中核心的配置管理实践。然而，在落地实施时，尽管在流程和技术上的挑战同样不容忽视，但一支刚开始实施敏捷的团队往往会首先面临另一个更直接的问题：为什么需要以这种节奏开发软件？这个问题的背后，是两种项目管理理念的冲突与交锋。
“戚主任，这个问题我们再调一调，花不了多少时间，就这两天，保证给您改好。”何晓东拿着电话，满脸笑容，似乎希望他的笑意能感染电话线另一头的听者。
“两天两天，你们老是这个样子，怎么做点事情就不能按起初定好的时间完成呢？我再给你三天时间，这个星期五之前，把所有的修改都完成并上线。要是星期五还完不成，你就带着人再到局里来驻场吧！”不等何晓东回答，戚红军“砰”的一声挂了电话。
打完电话，戚红军端起茶杯，慢慢喝了两口，脸上并没有怒容。他在杭州工商局信息中心从科员干到主任，经他手采购的信息化项目大大小小也有几十个，项目的拖拖拉拉实在看得太多了，尤其是软件开发、系统集成的项目，严重的可以超期几个月。听其他地市兄弟机关交流，整个项目彻底失败，完全不能上线实用的情况也不罕见。相比之下，北大青鸟这个项目的进度已经算不坏了，至少第一期赶在年底前将年检和注册功能上线并投入使用。对何晓东这个团队的能力，他还算有些信心，在电话里吓唬一下就行，估计他们完成这个阶段修改的问题不大。
这个信心是在过去几个月的项目过程中逐渐形成的。项目签给北大青鸟是在夏天，戚红军本来期望起码到11月以后才会看到软件，再集中提一批修改意见，这是软件项目典型的节奏。不料这个项目才做了一个月，就开始邀请他看功能展示，随后每过两周就给他做一次展示，听取他的意见。起初的两三次展示的功能还很粗糙，等在界面添加上美工设计之后，项目就有了一点成型的样子，戚红军感觉能看到这个系统在逐渐生长成该有的样子。他给项目组提的意见起初多是在纠正他们理解上的偏差，后来常常是在展示和试用的过程中发现自己的想法也有所偏差，或者跟业务口的同事针对测试软件进行交流后有了更好的想法。这样的节奏一直保持到11月，虽然这支团队压力不小，但其实戚红军并不特别担心：照这个势头，即使到年底完不成所有功能或者有些小bug，这个项目大差不差是能成功的。
回想着这个项目的过程，戚红军又拿起手边一份打印出来的项目月报。这是另一家供应商承接的另一个软件实施项目，月报上写着“开发完成80%”“项目整体进度60%”。可是直到今天，戚红军连这个软件的雏形都还没见到一眼，那么这份报告里写的80%和60%到底是什么意思呢？现在项目的开发时间倒是已经过去了大半，剩下的工作能在40%的时间里完成吗？想到这儿，戚红军起身拿起外套，打算去这家公司走走。
本文摘自《敏捷中国史话》
《敏捷中国史话》用生动、翔实的语言，辅以情景描述，循序渐进地讲解了敏捷软件开发在中国的发展历程。本书从敏捷的发展背景讲起，延伸到描述世纪之交的中国软件业的发展状况、敏捷的传入、敏捷的低谷以及敏捷实践者为敏捷发展所做的艰苦奋斗，还介绍了敏捷在通信行业和互联网企业的实施状况、敏捷软件开发的发展和Scrum的流行。
本书既适合广大的敏捷方法的爱好者阅读，也适合对软件开发方法发展历程和对中国敏捷技术普及历史感兴趣的人员阅读。
作者简介