XP活用原则

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

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

字串9

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

字串7

精益原则

字串8

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

　　二战后的美国，以福特公司为首的汽车制造公司在大肆提倡规模制造（Mass Prodution）的同时，东方的日本，丰田英二等人在考察了美国的制造思路之后，认为美国的制造方式不适合日本，提出了自己的精益制造（Lean Production）的思路，精益制造成就了一代霸主－丰田公司，丰田的制造方式被人称为TPS（Toyota Production System）。丰田公司的丰田英二和大野耐一等人进行了一系列的探索和实验，根据日本的国情，提出了一系列改进生产的方法：及时制生产、全面质量管理、并行工程，逐步创立了独特的多品种、小批量、高质量、低消耗的生产方式。这些方法经过30多年的实践，形成了完整的"丰田生产方式"，帮助汽车工业的后来者日本超过了汽车强国美国，产量达到1300万辆，占到世界汽车总量的30％以上。 字串2

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

　　消除浪费。 任何不能够为最终的产品增加用户认可的价值的东西都是浪费。无用的需求是浪费，无用的设计是浪费，超出了功能范围，不能够被马上利用的代码也是浪费，工件在不同的开发组之间无意义的流转，也是浪费。
强化学习，鼓励改进。软件开发是一个不断发现问题，不断解决问题的过程。而学习能力的强化，能够令软件开发工作不断的获得改进。

　　延迟决策。软件开发如果工作在一个不确定的环境中，变化性会对软件开发本身造成伤害。延迟决策，当环境变得逐渐清晰之后，才有充足的理由来进行决策。而对软件设计而言，如何构建一个可支持变化的系统则成为关键的问题。

　　尽快交付。自从互联网流行之后，速度成为了商业中的至关重要的因素，从而直接影响了快速软件开发的成熟。软件阶段性交付的周期越快，软件的风险就越容易识别，用户的需求就越清洗，软件的质量就越高。
谁做决策。谁做决策？是高高在上的高级经理，还是贴近代码的编码人员。决策取决于准确的信息，但是掌握这些信息的权威者往往就是做实际工作的编码人员，将编码人员的建议、决定和实践纳入到决策的范畴来，是成功决策的关键。 字串4

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

过程

字串2

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

　　一家专门提供外卖的公司，常常被客户投诉说送货的时间太慢了。于是他们加强了送货的力量，包括使用更好的工具，雇佣更多的送货人员。但是成本增加了，客户的投诉依然不断。问题出在了哪里？在对整个流程进行了量化评估之后，他们发现，送货的时间对整个的时间影响很小，而更多的时间是花费在了制作外卖的过程中。所以，原先投入对送货流程改进的投资，算是白费了。

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

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

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

字串3

过程中的人 字串3

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

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

　　这就好像我们骑自行车，设定一个500米外的目标，然后我们把车把固定住，选取好起点，并预先制定好角度和标准路线，然后骑着车子，严格的按照原定路线前进。车子能到终点吗？可能性不大，设定好的标准路线上可能会有障碍物，这是你原先没有想到的；由于无法调节方向来保持平衡，车子可能会摔倒。

字串2

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

　　传统的计划方法和第一种骑车方法一样不切实际，花费大量的时间思考几个月后发生的事情是很难的。只有根据变化不断的调整，才是正确的态度。 注意，不把时间花费在计划上，并不等于不重视计划。计划仍然是软件开发的核心。你必须有一个当前的迭代计划，当前的周计划，甚至当前的计划。只有保证每一个小计划的严谨性，才能够保证整个项目计划的成功。

字串9

　　XP对计划的态度是：你不需要把计划做的多么精密，但是你必须去做计划。计划赶不上变化，这句话说的一点都没错，我们不需要逃避变化，花大力气进行精确的计划既浪费，又没有意义。但是这并不是说不做计划。凡事预则立，我们需要简单明了的计划，然后在软件开发的过程中，不断的修正并完善计划。 学习变化：XP最适合那些需求容易发生变化的过程，在现实中，我们发现这种情况实在是太多了。可能软件的目标市场发生了变化，要求软件同步变化；可能客户对需求没有充分的了解，导致需求的变化；可能客户的组织或业务流程发生了改变，要求软件变化。种种的可能性表示，在一个一成不变的环境下开发软件已经称为一种奢望。在这样一个残酷的环境中，我们不得不去学习变化。

字串6

　　变化包括两个方面：软件过程如何适应变化，以及软件设计如何适应变化。传统的软件过程往往要求上游的软件阶段确定之后，才能够进行下一个软件阶段。但是变化的需要要求软件过程在多个软件阶段之间切换。 由于变化的残酷性，XP建议开发人员必须建立变化的意识。你必须去改变你的心态，接受变化，变化是合理的，一成不变的东西压根就不存在。

字串5

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

字串3

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

字串9

本文的定位 字串3

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

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

字串5

　　文章没有全面的介绍XP的所有实践。因为作者并不是XP的绝对拥护者，我们以一种客观的态度审视XP，我们介绍的内容，是在采用了XP的实践或是吸收了XP实践中的思想之后的经验；我们没有介绍的部分，是因为环境原因无法实践或是不对其表示赞同（但并不是不赞同）。 其实本文介绍的很多知识并不是XP的专利，其它的敏捷方法也都提到了这些优点，例如自适应软件方法。所以，更准确的描述是本文如何从XP中学习先进的软件开发理念。 字串9

(二)考核和评估之别

字串3

螺旋、迭代、增量，不同的名词代表了同样的含义－分阶段开发软件。众多的方法学都采用了这种思路设计软件过程。但是在实践中，更多时候，分阶段开发软件带来的是痛苦。看来，我们常常被书中优美的叙述所迷惑，却没有真正想过实施中的难题。那么，如何管理分阶段的软件开发呢？如何应对现实中的难题呢？

考核和评估之别 字串1

　　在绩效管理中，有两个名词：考核和评估，分别表示了绩效考核和绩效评估两种绩效管理方式。这两者有什么区别呢？

　　我们说考核是一种制度，而评估是一个过程。怎么理解呢？很多的公司都有绩效考核的制度，这个制度一般是在年底的时候，对员工今年的工作做一个评定。考核是一个点。但是评估不一样，评估是针对某一段时间中员工工作中的不足之处，需要改进之处进行评价。不论是考核还是评估，它们两者虽然都是为了达到评价并改进员工行为的目的而设计的，但是做法是不同的。考核针对过去的事情进行评定，容易实现，但是效果不佳，因为时间一长，大家可能忘记了以前的事情，而要公平的对过去一年的表现做一个评定也不是一件容易的事，评估则不同，评估是不断进行的，针对刚刚发生的事情做出评价，并找到改进方法。就好像我们在第一章中举的外卖店的例子，不断地对过程进行分析和改进，这就是一种评估。评估的效果不错，但难以实现。

软件开发中的考核和评估

字串9

这一思路在软件过程中，直接表现为里程碑和迭代的思路。我们可以想想，里程碑是不是一种制度。在需求结束的时候，我们需要需求规约文档，风险列表等等一系列的文档，在设计结束的时候，我们也需要另一些文档。这种处理方式就是考核的思路。但是很多时候，这种考核起到的作用是有局限性的： 字串9

　　工件的设计原本是为了辅助生成最终的代码，但是往往会演变成为了通过里程碑而设计；

　　里程碑的设计不能够完全捕获所有的问题，部分的风险被隐藏了；

　　难以对工作量和工作价值进行评估；

　　里程碑揭露问题的时间要远远落后于问题出现的时间；

　　这里对里程碑的方式做一些分析。我们对问题的理解往往是逐步深入的。在项目一开始的时候，业务和技术上都存在问题，存在不确定性和风险，这时候往往是最需要评估和验证的。但是里程碑方式往往要求必须深入的分析需求，很多的问题并没有得以解决，而是被悄悄的有意或无意的掩盖了。需求毕竟不是软件，它是一个不同人具有不同理解的模型，这时候，项目中各个角色对它的理解都不相同，但是这并不影响他们做出一致的决定－通过需求里程碑。问题到了设计阶段依然存在，这时候需求阶段隐藏的一些问题开始出现，导致我们不得不补充一些工作量。但是所有的问题也没有得到解决，依然存在未知的风险。那么风险到了什么时候才会暴露出来呢？最乐观的情况是在编码时期发现，最悲观的情况是在交付期发现。我们把这种过程称为固化考核过程。 问题在哪里？除了软件本身，模型也好、文档也罢，都不能够代替最后的代码。在精益原则中，我们说，必须消除浪费。当我们在开发工件的时候，我们的浪费行为已经或多或少的出现了。 字串2

　　与固化考核过程相对的，我们认为存在另一种动态评估过程。里程碑或是检查点并不是不重要。但是我们需要转换思路，来将里程碑的实践做的更好一些。我们上面提到说里程碑方式最大问题就在于一定要等到问题都积累起来了才解决问题，而这个时候往往已经错过了解决问题的最佳时机。而动态评估过程的含义就是在过程进行中不断的发现并解决问题，而不是等到问题累积到一定程度才批量解决。过程随着环境的变化不断的调整，以适应变化性和不确定性的需要。而里程碑实践重在提供一个复审的机会，能够从一个较高的层次上来评价软件。 这种过程就是分阶段开发软件的思路，我们也可以称呼它为迭代、螺旋、增量，都没有关系。关键在于，我们需要不断的发现导致客户不满意的问题，发现改进接电话的方法，发现改进做菜的方法，发现更快送货的方法。

实现策略 字串5

　　动态评估过程有一些基本的实现思路，第一个基本思路是尽可能早的发现所有的问题，如何发现呢？进行一次探险式的过程。这个过程周期不能够太长，太长的周期容易失控，而且项目初期人员未必能够全部到位；但这个周期也不能够太短，太短的周期无法发现足够数量的风险，无法为后续的过程提供丰富的数据。

　　有时候，我们运用原型法来实现这个Mini过程。原型法包括了需求原型和技术原型，分别用于解决业务风险和技术风险。一个典型的需求原型是建立一个界面原型，来帮助客户理解未来的软件，避免抽象的思考。我看过很多界面原型的做法，有使用HTML的，有使用画图软件的，有使用规范的XML的。但是不管如何，界面原型能够帮助用户直观的理解需求。技术原型的主要目标是解决技术风险，任何一个项目都可能存在这样或那样的技术风险。对待风险的基本态度是尽早的评估风险并制定解决方案，而不是束之高阁。技术风险的解决方案视具体情况而定，但是，值得注意的是，一个项目中，技术风险不能够过多。如果确实存在这种情况，想办法找到有经验的导师或培训师，这要比自己摸索节省许多的成本。 字串7

　　XP对探险式过程的评估主要包括两个方面，spike solution和迭代。spike solution其实就是我们在上面提到了的技术原型。它的目的是让不明确的评估成为明确的评估（参见XP的过程图中的Spike）。只有评估准确了，计划才能够准确。因此它是计划和迭代的输入项。

　　而迭代则是改进或修正软件质量。这也是第三个基本思路。我们注意看XP过程图中的迭代，多次的迭代才构成一次的增量（小版本），每一次的迭代都是对上一次迭代的改进，其中可能是修正了设计错误，或是需求缺陷。值得注意的是，迭代中可能会出现新的需求变更（新需求或需求改变），并令项目人员对项目的进展速度更加的了解（Project Velocity），这些将会反过来影响计划的修正。这体现了我们在上一章所讲述的XP对待计划的态度。 字串8

　　并没有法律规定迭代需要和增量一起使用，但很明显，结合这两种方式是一种有效的做法。增量的目标是让项目得以向前推进（这就像是修路的时候，路的长度变长了），而迭代的目标是令软件的质量更优（就像是在一段路上架设路基、铺上水泥，建设路面设施）。这让我们想起了什么，不错，重构的两顶帽子。一顶帽子是为软件增加新功能，一顶帽子是改进软件的质量。非常的相似，只不过一个是过程级别的，一个是程序级别的。这里有一个基本的假设，不要同时增加功能和改进质量。团队也好，个人也好，一次只完成一个目标效率是最高的。 字串1

思考 字串1

和传统的先定义问题，然后再解决问题的做法不同，XP偏重于逐步的精化问题。软件开发中的问题定义和数学中不同，它往往是模糊的，动态的，需要在解决问题的过程中不断的调整解题的思路。对XP来说，这种解题思路，体现了其反馈的价值观－尽快获得客户对软件的反馈。