XP作为敏捷方法的一种，拥有很多优秀的实践，用好这些实践，在软件组织中能够起到很好的效果。问题在于，要用好这些实践并不简单，本系列文章的目标就是围绕着 XP 的实践，讨论隐藏在实践内部的敏捷性实质，研究如何灵活的应用 XP 的实践，从而达到改进软件过程的目的。
软件开发虽然有多个环节，但是我们不能只强调某些环节，任何一个环节出问题最终都会影响产品的质量。因此我们在软件开发中应该考虑整个过程，并且重视人这个因素。

质检员的工作

在以前的工厂作业流程中，产品在生产出来之后，都需要经过质检员的检查。在质检员身边，有两个筐，一个筐上写着合格，一个筐上写着不合格。对于合格的产品，贴上合格证，进入销售的环节，对于不合格的产品，禁止出厂。很久以来，我们一直采用在产品的最终阶段进行质量检验的方式，这种方式用来避免有质量缺陷的产品出厂，但是既没有办法提高产品的质量，也没有办法降低差错率。这种质检方法的基本思想是，产品出现废品是正常的，只要能够找出废品，产品的质量就不受影响。

那我们看看软件开发的工艺流程。当软件经历了需求、分析、设计、编码之后，质检员同样需要检验软件是否满足质量要求。各种各样的测试人员共同担任了质检员的角色。而质检员的工序也不简单。黑盒测试、白盒测试、集成测试、用户测试、并行测试。和工厂不同的是，出现问题的软件并不能够简单的扔到不合格的产品堆中。另一个不同，软件产品一定会出现质量的问题。既然不能简单的抛弃产品，那么只好把产品退回到生产线上。于是，需求人员、分析人员、设计人员、编码人员开始对软件进行调整，力图使软件能够出厂。这个反复的过程往往要持续上一段时间。幸运的软件可以顺利出厂（交付），否则，可能会遭到项目失败的命运。

很明显，我们发现这种做法不够聪明。把问题堆积起来，直到最后才来集中解决，这种做法的代价是非常高昂的。软件开发的特性，决定了越是后期的变更，成本越高。那么，我们应该如何调整我们的做法，来降低成本，提高质量呢？

精益原则

软件开发总是从其它学科中借鉴管理思路。最早的软件工程从土木工程中借鉴经验，但是后来人们发现建筑和软件开发有很大的差异性。故而新的软件开发方式开始兴起，其中就包括了XP方法论。同样的，新的软件开发方式仍然在理论上寻找立足点，这一次众人的焦点落在了现代管理理念上。土木工程管理的一个很大的问题就在于忽视了人的作用，而现代的管理理念将人的作用提到了一个新的高度，这和新兴的软件开发思想是相同的。而对软件开发思路影响最大的，应该算是丰田公司提出的精益生产（Lean Production）的概念。

回顾这段历史，和软件开发的历史何其相似。大规模制造理论认为，一定程度的浪费，一定程度的废品是正常的，允许的。而在软件开发中，浪费、成本居高不下也同样成为阻止软件开发迈向工程化的一大障碍。像XP这样的敏捷方法从精益制造的思路中吸取了很多的优秀思想，例如，不断改进质量，设计决策应该交给最贴近生产的人员，根据客户的需求来推动生产。虽然我们一直在强调软件开发和制造行业截然不同，但是，处于变革的十字路口的软件开发行业，总是不断的从其它的行业中寻找可借鉴的理论。这种借鉴来的思路就被称为精益编程（Lean Programming）。精益编程的思路包括：

• 消除浪费。 任何不能够为最终的产品增加用户认可的价值的东西都是浪费。无用的需求是浪费，无用的设计是浪费，超出了功能范围，不能够被马上利用的代码也是浪费，工件在不同的开发组之间无意义的流转，也是浪费。
• 强化学习，鼓励改进。软件开发是一个不断发现问题，不断解决问题的过程。而学习能力的强化，能够令软件开发工作不断的获得改进。
• 延迟决策。软件开发如果工作在一个不确定的环境中，变化性会对软件开发本身造成伤害。延迟决策，当环境变得逐渐清晰之后，才有充足的理由来进行决策。而对软件设计而言，如何构建一个可支持变化的系统则成为关键的问题。
• 尽快交付。自从互联网流行之后，速度成为了商业中的至关重要的因素，从而直接影响了快速软件开发的成熟。软件阶段性交付的周期越快，软件的风险就越容易识别，用户的需求就越清洗，软件的质量就越高。
• 谁做决策。谁做决策？是高高在上的高级经理，还是贴近代码的编码人员。决策取决于准确的信息，但是掌握这些信息的权威者往往就是做实际工作的编码人员，将编码人员的建议、决定和实践纳入到决策的范畴来，是成功决策的关键。

精益编程代表了一种思想，很多的Agile方法都从各自的理论基础出发，支持了这种思想。而在我们的讨论中，讨论的重点就是放在XP上。XP方法论中最有价值的是他的思想。我们研究、学习XP，不能够光了解他的实践活动，还需要时刻注意XP的价值观，并仔细的思考，在实践活动的背后，到底隐藏着什么样的思想。就好像我们在阅读设计模式一书的时候，书中给出的是各种各样的关于面向对象的设计方法，但是书中仍然有一条主线贯穿其中，那就是面向对象的编程原则。

过程

前一段时间，书店中很畅销的书大多数都和6σ相关。6σ是全面质量管理理论的发展。其中一个很重要，和软件开发非常类似的思路是，过程的每一个步骤，都会对产品最后的质量产生影响，要提高质量，降低成本，提升客户的满意度，最关键的是要对过程进行研究和分析，发现对产品影响较大的步骤，并制定改进的措施。

做任何一件事情，都需要经历一个过程。从外卖店接到客户的订货电话开始，一个过程就已经启动了。记录客户的地址、地址特征、菜名，给厨房下单，分配外送人员，将地址信息传递给外送人员，送货，寻找目的地，交付外卖并收款，后续过程忽略。一个似乎平常的生活活动，其背后都包含了复杂的过程。对软件开发而言也是一样的。从客户提出软件的构想，一直到客户真正开始使用软件，其间的过程非常的复杂，充满了各种各样的不可预测的因素。

送外卖的过程，每一步都会对最终的质量（客户满意度）产生影响。对客户来说，从打电话到收到外卖的时间，外卖的好吃程度，这些都是属于满意度的组成成分。接到电话后，可能客户的口音较重，记录员听错了地址，导致后续过程全部白费，除非客户等的不耐烦，打电话来重新记录一次地址。下单给厨房之后，可能厨房的电风扇会将单子吹到了地上，客户的要求就被忽略了。记录员把客户的地址描述信息写的很潦草，送货人员可能看不懂，这时候他需要打电话回来问，这就担搁了送货时间。送货人员可能对客户所在不熟悉，找到地址花费了很多的时间。好不容易送到了客户手上，客户已经等的不耐烦了，更糟的是，由于时间太长，外卖已经凉了。客户决定，下一次更换一家外卖店。虽然每一个环节出错的概率都不是很大，但是各个环节组合起来之后，出错的概率就大的惊人。在分析了这样一个流程之后，我们的感慨往往是，居然能够送到，真是不容易！软件开发的过程难道不是这样吗？每一个环节都有可能出问题，需求未必就代表了客户的需要，设计不能够很好的代表需求，反而对编码增加了一些不稳定的因素，由于进度较紧，编码的工作也比较马虎。这样的过程，我们能够开发出客户满意的软件，那么只有一个解释，以前客户接触的软件开发人员，比我们还要烂。

好吧，我们如何改善这一情况呢？对了，对过程进行改进。既然记录员可能会和客户之间出现错配的情况，那我们就要求记录员在听完客户的要求之后，重复一遍。既然，菜单可能会遗失，我们就在厨房中专门设计一个位置，按先进先出的顺序排列这些菜单，而且保证菜单不会被遗失。既然送货员可能会看不懂记录员的字，那么就让送货员和记录员花费一些时间沟通，要么送货员能够习惯记录员的字，要么记录员写出送货员能够理解的字。既然送货员可能未必认识路，那么就对送货员划片，有专门送A区的，有专门送B区的，每个人熟悉的范围减小了，熟悉的程度自然就上升了。好吧，有了这样的思想，我们也准备对软件过程进行改进了。不过，并不是现在，本文的剩余部分将会围绕着这一点来进行。

过程中的人

除了过程的重要性，我们还需要考虑人的因素，过程是要依靠人去推动的，没有人，过程就没有任何意义。对软件开发更是如此，开发过程的每一个环节都需要人的参与。从来没有一个方法论象XP这样充分的强调人的作用。因此，在XP的全过程中，人的因素是始终处于首位的。而XP的实践也是根据人的优点和弱点进行精心的设计。我们这里做一些简单的讨论：

计划游戏：我们常常挂在嘴边的一句话是计划赶不上变化。计划，往往都是很多软件组织的一块心病。所有人都知道计划的重要性，可是计划又是最难做的。没有计划，软件过程无从遵循；有了计划，软件过程又常常偏离计划。在变化越来越频繁的现在，计划更是难上加难。对待捉摸不定的计划，XP的态度是：与其在一开始就费时耗力地制定一堆不切实际的计划，倒不如花费少量的精力做一个简单的计划，然后在随后的软件过程中不断的进行调整。

车子，应该这样骑。看看远处的目标，估算距离和时间，得出一个粗糙的速度，然后我们就上路了。在前进的过程中，我们不断的目测目标，察看时间，并调整速度和方向。目标越来越接近，我们的调整越来越熟练，最后，我们成功的抵达的目标点。

传统的计划方法和第一种骑车方法一样不切实际，花费大量的时间思考几个月后发生的事情是很难的。只有根据变化不断的调整，才是正确的态度。

注意，不把时间花费在计划上，并不等于不重视计划。计划仍然是软件开发的核心。你必须有一个当前的迭代计划，当前的周计划，甚至当前的计划。只有保证每一个小计划的严谨性，才能够保证整个项目计划的成功。

XP对计划的态度是：你不需要把计划做的多么精密，但是你必须去做计划。计划赶不上变化，这句话说的一点都没错，我们不需要逃避变化，花大力气进行精确的计划既浪费，又没有意义。但是这并不是说不做计划。凡事预则立，我们需要简单明了的计划，然后在软件开发的过程中，不断的修正并完善计划。

学习变化：XP最适合那些需求容易发生变化的过程，在现实中，我们发现这种情况实在是太多了。可能软件的目标市场发生了变化，要求软件同步变化；可能客户对需求没有充分的了解，导致需求的变化；可能客户的组织或业务流程发生了改变，要求软件变化。种种的可能性表示，在一个一成不变的环境下开发软件已经称为一种奢望。在这样一个残酷的环境中，我们不得不去学习变化。

变化包括两个方面：软件过程如何适应变化，以及软件设计如何适应变化。传统的软件过程往往要求上游的软件阶段确定之后，才能够进行下一个软件阶段。但是变化的需要要求软件过程在多个软件阶段之间切换。

由于变化的残酷性，XP建议开发人员必须建立变化的意识。你必须去改变你的心态，接受变化，变化是合理的，一成不变的东西压根就不存在。

这里插一句题外话。强烈建议在XP的项目中使用面向对象技术。虽然面向对象并没有对软件过程或是软件管理提出任何的要求。但是，一个使用面向对象的团队（注意，是使用面向对象技术，而不是使用面向对象语言，这么说是因为有着大量的开发人员使用面向对象的编程语言编码面向过程式的代码），其管理过程也会随之变化。用户参与、迭代开发、重用、使用框架。这些都是在使用了面向对象技术之后自然而然出现的变化。使用面向对象技术，能够和XP方法进行更加紧密的衔接。

除了上面讨论的两个简单的思路，本文的其它部分都会针对XP中过程和人两方面的因素进行讨论。

本文的定位

本文不是一篇介绍XP基本知识的文章，这方面的资料已经很多了，要想全面的了解XP，人民邮电的一套XP系列丛书是非常好的一个开始。而本书的定位是讨论在实际的软件开发中，如何灵活的应用XP，如何遵循XP的思想，但又根据实际情况进行折衷。虽然本文没有介绍任何的XP基础知识，但是仍然适合XP的初学者阅读，刚接触XP的人往往都有各种各样的困惑，而从国外翻译过来的注解却未必适合国内的环境，因此阅读本文能够从实践的角度更深的理解XP的思想。

和其它的方法论一样，XP不是万能的。一个软件组织能否从XP中获益，不是取决于XP，而是取决于这个软件组织自身。正如我们在一开始就强调的，学习XP，关键在于学习思想。软件组织应该根据自身的情况，活学、活用XP，而不是人云亦云。XP可不是制作一堆卡片。切记，切记。

文章没有全面的介绍XP的所有实践。因为作者并不是XP的绝对拥护者，我们以一种客观的态度审视XP，我们介绍的内容，是在采用了XP的实践或是吸收了XP实践中的思想之后的经验；我们没有介绍的部分，是因为环境原因无法实践或是不对其表示赞同（但并不是不赞同）。

其实本文介绍的很多知识并不是XP的专利，其它的敏捷方法也都提到了这些优点，例如自适应软件方法。所以，更准确的描述是本文如何从XP中学习先进的软件开发理念。