敏捷开发之XP

敏捷方法论有一个共同的特色，那就是都将矛头指向了“文档”，它们认为传统的软件工程方法文档量太“重”了，称为“重量级”方法，而相应的敏捷方法则是“轻量级”方法。正是由于“轻量级”感受没有什么力量，不但不可以有效体现灵活性，反而显得是不解决问题的方法论似的。所以，就有了一次划时代的会议，建立了敏捷联盟。

在敏捷方法论领域中，比较知名的、有影响力的，是拥有与Microsoft的操做系统相同缩写语——XP的极限编程（eXtreme Programming）。极限编程方法论能够说是敏捷联盟中最鲜艳的一面旗帜，也是被研究、尝试、应用、赞赏、批判最多的一种方法论，也是相对来讲最成熟的一种。

这一被誉为“黑客文化”的方法论的雏形最初造成于1996—1999年间，Kent Beck、Ward Cunninggham、Ron Jeffrey在开发C3项目（Chrysler Comprehensive Compensation）的实践中总结出了XP的基本元素。在此以后，Kent Beck和他的一些好朋友们一块儿在实践中完善提升，终于造成了极限编程方法论。

解析极限编程

那么什么是XP呢？XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学并且充满乐趣的软件开发方式。与其余方法论相比，其最大的不一样在于：

• 在更短的周期内，更早地提供具体、持续的反馈信息。
• 在迭代的进行计划编制，首先在最开始迅速生成一个整体计划，而后在整个项目开发过程当中不断的发展它。
• 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
• 依赖于口头交流、测试和源程序进行沟通。
• 倡导持续的演化式设计。
• 依赖于开发团队内部的紧密协做。
• 尽量达到程序员短时间利益和项目长期利益的平衡。

Kent Beck曾经说过“开车”就是一个XP的范例，即便看上去进行得很顺利，也不要把视线从公路上移开，由于路况的变化，将使得你必须随时作出一些这样那样的调整。而在软件项目中，客户就是司机，他们也没有办法确切地知道软件应该作什么，所以程序员就须要向客户提供方向盘，而且告知咱们如今的位置。

XP包括写什么呢？如图，XP由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联， 并经过行为贯穿于整个生命期。

 

四大价值观

 

XP的核心是其总结的沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）四大价值观，它们是XP的基础，也是XP的灵魂。
此外还扩展了第五个价值观：谦逊（Modesty）。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱；XP精神能够启发咱们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈、勇气和谦逊”的态度来对待XP；轻松愉快地来感觉XP的实践思想；本身认真实践后，经过对真实反馈的分析，来决定XP对本身的价值；有勇气接受它，或改进它。

1. 沟通

通畅程序员给人留下的印象就是“内向、不善言谈”，而后项目中的许多问题就出在这些缺少沟通的开发人员身上。常常因为某个程序员作出了一个设计决定，可是却不能及时地通知你们，结果使得你们在协做与配合上出现了不少的麻烦，而在传统的方法论中，并不在乎这种口头沟通不顺畅的问题，而是但愿借助于完善的流程和面面俱到的文档、报表、计划来替代，可是这同时又引入了效率不高的新问题。

XP方法论认为，若是小组成员之间没法作到持续的、无间断的交流，那么协做就无从谈起，从这个角度可以发现，经过文档、报表等人工制品进行交流面临巨大的局限性。所以，XP组合了诸如对编程这样的最佳实践，鼓励你们进行口头交流，经过交流解决问题，提升效率。

2. 简单

XP方法论提倡在工做中秉承“够用就好”的思路，也就是尽可能地简单化，只要今天够用就行，不考虑明天会发现的新问题。这一点看上去十分容易，可是要真正作到保持简单的工做其实很难的。由于在传统的开发方法中，都要求你们对将来作一些预先规划，以便对从此可能发生的变化预留一些扩展的空间。

正如对传统开发方法的认识同样，许多开发人员也会质疑XP，保持系统的扩展性很重要，若是都保持简单，那么如何使得系统可以有良好的扩展性呢？其实否则，保持简单的理由有两个：

• 开发小组在开发时所作的规划，并没有法保证其符合客户须要的，所以作的大部分工做都将落空，使得开发过程当中重复的、没有必要的工做增长，致使总体效率下降。
• 另外，在XP中提倡时刻对代码进行重构，一直保持其良好的结构与可扩展性。也就是说，可扩展性和为明天设计并非同一个概念，XP是反对为明天考虑而工做，并非说代码要失去扩展性

并且简单和沟通之间还有一种相对微妙的相互支持关系。当一个团队之间，沟通的越多，那么就越容易明白哪些工做须要作，哪些工做不须要作。另外一方面，系统越简单，须要沟通的内容也就越少，沟通也将更加全面。

3. 反馈

是什么缘由使得咱们的客户、管理层这么不理解开发团队？为何客户、管理层老是喜欢给咱们一个死亡之旅？究其症结，就是开发的过程当中缺少必要的反馈。在许许多多项目中，当开发团队经历过了需求分析阶段以后，在至关长的一段时间内，是没有任何反馈信息的。整个开发过程对于客户和管理层而言就像一个黑盒子，进度彻底是可见的。

并且在项目的过程当中，这样的现象不只出如今开发团队与客户、管理层之间，还包括在开发团队内部。这一切问题都须要咱们更加注重反馈。，反馈对于任何软件项目的成功都是相当重要的，而在XP方法论中则更进一步，经过持续、明确的反馈来暴露软件状态的问题。具体而言就是：

• 在开发团队内部，经过提早编写单元测试代码，时时反馈代码的问题与进展。
• 在开发过程当中，还应该增强集成工做，作到持续集成，使得每一次增量都是一个可执行的工做版本，也就是逐渐是软件长大，整个过程当中，应该经过向客户和管理层演示这些可运行的版本，以便及早地反馈，及早地发现问题。

同时，咱们也会发现反馈与沟通也有着良好的配合，及时和良好的反馈有助于沟通。而简单的系统更有利于测试盒反馈。

4. 勇气

在应用XP方法论时，咱们每时每刻都在应对变化：因为沟通良好，所以会有更多需求变动的机会；因为时刻保持系统的简单，所以新的变化会带来一些从新开发的须要；因为反馈及时，所以会有更多中间打断你的思路的新需求。

总之这一切，使得你马上处于变化之中，所以这时就须要你有勇气来面对快速开发，面对可能的从新开发。也许你会以为，为何要让咱们的开发变得如此零乱，可是其实这些变化若你不让它早暴露，那么它就会迟一些出现，并不会所以消亡，所以，XP方法论让它们早出现、早解决，是实现“小步快走”开发节奏的好办法。

也就是XP方法论要求开发人员穿上强大、自动测试的盔甲，一往无前，在重构、编码规范的支持下，有目的地快速开发。

勇气能够来源于沟通，由于它使得高风险、高回报的试验成为可能；勇气能够来源于简单，由于面对简单的系统，更容易鼓起勇气；勇气能够来源于反馈，由于你能够及时得到每一步前进的状态（自动测试），会使得你更敢于重构代码。

5. 四大价值观以外

在这四大价值观之下，隐藏着一个更深入的东西，那就是尊重。由于这一切都创建在团队成员之间的相互关心、相互理解的基础之上。

5个原则

1. 快速反馈

及时地、快速地获取反馈，并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该经过较短的反馈循环迅速地了解如今的产品是否知足了客户的需求。这也是对反馈这一价值观的进一步补充。

2. 简单性假设

相似地，简单性假设原则是对简单这一价值观的进一步补充。这一原则要求开发人员将每一个问题都看得十分容易解决，也就是说只为本次迭代考虑，不去想将来可能须要什么，相信具备未来必要时增长系统复杂性的能力，也就是号召你们出色地完成今天的任务。

3. 逐步修改

就像开车打方向盘同样，不要一次作出很大的改变，那样将会使得可控性变差，更适合的方法是进行微调。而在软件开发中，这样的道理一样适用，任何问题都应该经过一系列可以带来差别的微小改动来解决。

4. 提倡更改

在软件开发过程当中，最好的办法是在解决最重要问题时，保留最多选项的那个。也就是说，尽可能为下一次修改作好准备。

5. 优质工做

在实践中，常常看到许多开发人员喜欢将一些细小的问题留待后面解决。例如，界面的按钮有一些不平整，因为不影响使用就先无论；某一两个成员函数暂时没用就不先写等。这就是一种工做拖泥带水的现象，这样的坏习惯一旦养成，必然使得代码质量大打折扣。

而在XP方法论中，贯彻的是“小步快走”的开发原则，所以工做质量决不可打折扣，一般采用测试先行的编码方式来提供支持。

13个最佳实践

在XP中，集成了13个最佳实践，有趣的是，它们没有一个是创新的概念，大多数概念和编程同样老。其主要创新点在于提供一种良好的思路，将这些最佳实践结合在一块儿，而且确保尽量完全地执行它们，使得它们可以在最大程度上相互支持，紧接下来，咱们就对每一种最佳实践进行一番了解。

1. 计划游戏

计划游戏的主要思想就是先快速地制定一份概要的计划，而后随着项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。

“客户负责业务决策，开发团队负责技术决策”是计划游戏得到成功的前提条件。也就是说，系统的范围、下一次迭代的发布时间、用户故事的优先级应该由客户决定；而每一个用户故事所需的开发时间、不一样技术的成本、如何组建团队、每一个用户故事的风险，以及具体的开发顺序应该有开发团队决定。

好了，明白这些就能够进行计划游戏了。首先客户和开发人员坐在同一间屋子里，每一个人都准备一支笔、一些用于记录用户故事的纸片，最好再准备一个白板，就能够开始了。

• 客户编写故事：由客户谈论系统应该完成什么功能，而后用通俗的天然语言，使用本身的语汇，将其写在卡片上，这也就是用户故事。
• 开发人员进行估算：首先客户按优先级将用户故事分红必需要有、但愿有、若是有更好三类，而后开发人员对每一个用户故事进行估算，先从高优先级开始估算。若是在估算的时候，感到有一些故事太大，不容易进行估算，或者是估算的结果超过2人/周，那么就应该对其进行分解，拆成2个或者多个小故事。
• 肯定迭代的周期：接下来就是肯定本次迭代的时间周期，这能够根据实际的状况进行肯定，不过最佳的迭代周期是2~3周。有了迭代的时间以后，再结合参与的开发人数，算出能够完成的工做量总数。而后根据估算的结果，与客户协商，挑出时间上够、优先级合适的用户故事组合，造成计划。

2. 小型发布

XP方法论秉承的是“持续集成，小步快走”的哲学，也就是说每一次发布的版本应该尽量的小，固然前提条件是每一个版本有足够的商业价值，值得发布。

因为小型发布可使得集成更频繁，客户得到的中间结果也越频繁，反馈也就越频繁，客户就可以实时地了解项目的进展状况，从而提出更多的意见，以便在下一次迭代中计划进去。以实现更高的客户满意度。

3. 隐喻

相对而言，隐喻这一个最佳实践是最使人费解的。什么是隐喻呢？根据词典中的解释是：“一种语言的表达手段，它用来暗示字面意义不类似的事物之间的类似之处”。那么这在软件开发中又有什么用呢？总结而言，经常用于四个方面。

• 寻求共识：也就是鼓励开发人员在寻求问题共识时，能够借用一些沟通双方都比较熟悉的事物来作类比，从而帮助你们更好地理解解决方案的关键结构，也就是更好地理解系统是什么、能作什么。
• 发明共享词汇：经过隐喻，有助于提出一个用来表示对象、对象间的关系通用名称。例如，策略模式（用来表示能够实现多种不一样策略的设计模式）、工厂模式（用来表示能够按需“生产”出所需类得设计模式）等。
• 创新的武器：有的时候，能够借助其余东西来找到解决问题的新途径。例如：“咱们能够将工做流看作一个生产线”。
• 描述体系结构：体系结构是比较抽象的，引入隐喻可以大大减轻理解的复杂度。例如管道体系结构就是指两个构件之间经过一条传递消息的“管道”进行通讯。

固然，若是可以找到合适的隐喻是十分快乐的，但并非每种状况均可以找到恰当的隐喻，你也没有必要强求

4. 简单设计

强调简单设计的价值观，引出了简单性假设原则，落到实处就是“简单设计”实践。这个实践看上去彷佛很容易理解，但却又常常被误解，许多批评者就指责XP忽略设计是不正确的。其实，XP的简单设计实践并非要忽略设计，并且认为设计不该该在编码以前一次性完成，由于那样只能创建在“状况不会发生变化”或者“咱们能够预见全部的变化”之类的谎话的基础上的。

Kent Beck概念中简单设计是这样的：

• 可以经过全部的测试程序。
• 没有包括任何重复的代码。
• 清楚地表现了程序员赋予的全部意图。
• 包括尽量少的类和方法
• 他认为要想保持设计简单的系统，须要具有简单思考的能力，拥有理解代码和修改的勇气，以及为了消除代码的“坏味道”而按期重构的习惯。
• 那么如何开始进行简单的设计呢？XP实践者们也总结也一些具体的、可操做的思考方法。
• 首先写测试代码：具体将在后面详细描述。
• 保持每一个类只负责一件事：SRP（单一职责原则）是面向对象设计的基础原则之一。
• 使用Demeter（迪米特）法则：迪米特法则，也称为LoD法则、最少知识原则。也就是指一个对象应当对其余对象尽量少地了解。用隐喻的方法来解释的话就是“只与你直接的朋友通讯”、“不要和陌生人说话”。
• 使用CRC卡片进行探索。

5. 测试先行／测试驱动开发

当我第一次看到“测试先行”这个概念的时候，个人第一感受就是不解，陷入了“程序都尚未写出来，测试什么呀？”的迷思。我开始天马行空地寻求相关的隐喻，终于找到了可以启发个人工匠，首先，咱们来看看两个不一样的工匠是如何工做的吧。

• 工匠一：先拉上一根水平线，砌每一块砖时，都与这跟水平线进行比较，使得每一块砖都保持水平。
• 工匠二：先将一排砖都砌完，而后再拉上一根水平线，看看哪些砖有问题，对有问题的砖进行适当的调整。

你会选择哪一种工做方法呢？你必定会骂工匠二笨吧！这样多浪费时间呀！然而你本身想一想，你平时在编写程序的时候又是怎么作的呢？咱们就是按工匠二的方法在工做呀！甚至有时候比工匠二还笨，是整面墙都砌完了，直接进行“集成测试”，常常让整面的墙倒塌。看到这里，你还会以为本身的方法高明吗？这个连工匠都明白的道理，本身却画地为牢呀。

不只咱们没有采用工匠一的工做方法，甚至有的时候程序员会以“开发工做太紧张”为理由，而忽略测试工做。但这样却致使了一个恶性循环，越是没有空编写测试程序，代码的效率与质量越差，花在找Bug、解决Bug的时间也愈来愈多，实际产能大打下降。因为产能下降了，所以时间更紧张，压力更大。你想一想，为何不拉上一根水平线呢？难道，咱们不可以将后面浪费的时间花在单元测试上，使得咱们的程序一开始就更健壮，更加易于修改吗？不过，编写测试程序固然要比拉一条水平线难道多，因此咱们须要引入“自动化测试工具”，免费的xUnit测试框架就是你最佳的选择。

为了鼓励程序员原意甚至喜欢在编写程序以前编写测试代码，XP方法论还提供了许多有说服力的理由。

• 若是你已经保持了简单的设计，那么编写测试代码根本不难。
• 若是你在结对编程，那么若是你想出一个好的测试代码，那么你的伙伴必定行。
• 当全部的测试都经过的时候，你不再会担忧所写的代码从此会“暗箭伤人”，那种感受是至关棒的。
• 当你的客户看到全部的测试都经过的时候，会对程序充满史无前例的信心。
• 当你须要进行重构时，测试代码会给你带来更大的勇气，由于你要测试是否重构成功只须要一个按钮。

测试先行是XP方法论中一个十分重要的最佳实践，而且其中所蕴含的知识与方法也十分丰富。

6. 重构

重构时一种对代码进行改进而不影响功能实现的技术，XP须要开发人员在闻到代码的坏味道时，有重构代码的勇气。重构的目的是下降变化引起的风险，使得代码优化更加容易。一般重构发生在两种状况之下。

• 实现某个特性以前：尝试改变现有的代码结构，以使得实现新的特性更加容易。
• 实现某个特性以后：检查刚刚写完的代码后，认真检查一下，看是否可以进行简化。

在《重构》一书中，做者Martin Fowler提示咱们：在考虑重构时，应该要养成编写并常常运行测试代码的习惯；要先编写代码，再进行重构；把每一次增长功能都当作一次重构的好时机；将每个纠正错误当作一次重构的重要时机。同时，该书中也列出大量须要重构的状况和重构方法。

最后相似地，给尚未足够勇气进行重构的程序员打几剂强心针：

• XP提倡集体代码全部制，所以你能够大胆地在任何须要修改的地方作改动。
• 因为在XP项目组中有完整的编码标准，所以在重构前无须从新定义格式。
• 在重构中遇到困难，和你结对编程的伙伴可以为你提供有效的帮助。
• 简单的设计，会给重构带来很大的帮助。
• 测试先行让你拥有了一个有效的检验器，随时运行一下就知道你重构的工做是否带来了影响。
• 因为XP在持续集成，所以你重构所带来的破坏很快就可以暴露，而且得以解决。

重构技术是对简单性设计的一个良好的补充，也是XP中重视“优质工做”的体现，这也是优秀的程序员必备的一项技能。

7. 结对编程

“什么！两我的坐在一块儿写程序？那岂不是对人力的巨大浪费吗？并且我在工做时可不喜欢有一我的坐在边上当检察官。”是的，正如这里列举出来的问题同样，结对编程技术仍是被不少人质疑的。

不过，自从20世纪60年代，就有相似的实践在进行，长期以来的研究结果却给出了另一番景象，那就是结对编程的效率反而比单独编程更高。一开始虽然会牺牲一些速度，但慢慢的，开发速度会逐渐加快，究其缘由，主要是结对编程大打下降了沟通的成本，提供了工做的质量，具体表如今：

• 全部的设计决策确保不是由一我的作出的。
• 系统的任何一个部分都确定至少有2我的以上熟悉。
• 几乎不可能有2我的都忽略的测试项或者其余任务
• 结对组合的动态性，是一个企业知识管理的好途径。
• 代码老是可以保证被评审过。
• 并且XP方法论集成的其余最佳实践也可以使得结对编程更加容易进行：
• 编码标准能够消除一些无谓的分歧。
• 隐喻能够帮助结对伙伴更好地沟通。
• 简单设计可使得结对伙伴更了解他们所从事的工做。

结对编程技术被誉为XP保持工做质量、强调人文主义的一个典型的实践，应用得当还可以使得开发团队以前的协做更加流畅、知识交流与共享更加频繁，团队的稳定性也会更加稳固。

8. 集体代码全部制

因为XP方法论鼓励团队进行结对编程，并且认为结对编程的组合应该动态地搭配，根据任务的不一样、专业技能的不一样进行最优组合。因为每一个人都确定会遇到不一样的代码，因此代码的全部制就再也不适合于私有，由于那样会给修改工做带来巨大的不便。

也就是说，团队中的每一个成员都拥有对代码进行改进的权利，每一个人都拥有所有代码，也都须要对所有代码负责。同时，XP强调代码是谁破坏的（也就是修改后发生问题），就应该由谁来修复。

因为在XP中，有一些与之匹配的最佳实践，所以你并没有须担忧采用集体代码全部制会让你的代码变得愈来愈乱：

• 因为在XP项目中，集成工做是一件常常性得工做，所以当有人修改代码而带来了集成的问题，会在很快的时间内被发现。
• 因为每个类都会有一个测试代码，所以不论谁修改了代码，都须要运行这个测试代码，这样偶然性的破坏发生的几率将很小。
• 因为每个代码的修改就是经过告终对的两个程序员共同思考，所以一般作出的修改都是对系统有益的。
• 因为你们都坚持了相同的编码标准，所以代码的可读性、可修改性都会比较好，并且还可以避免因为命名法、缩进等小问题引起常常性得代码修改。

集成代码全部制是XP与其余敏捷方法的一个较大不一样，也是从另外一个侧面体现了XP中蕴含的很深厚的编码情节。

9. 持续集成

在前面谈到小型发布、重构、结对编程、集体代码全部制等最佳实践的时候，咱们屡次看到“持续集成”的身影，能够说持续集成是对这些最佳实践的基本支撑条件。

可能你们会对持续集成与小型发布表明的意思混淆不清，其实小型发布是指在开发周期常常发布中间版本，而持续集成的含义则是要求XP团队天天尽量屡次地作代码集成，每次都在确保系统运行的单元测试经过以后进行。

这样，就能够及早地暴露、消除因为重构、集体代码全部制所引入的错误，从而减小解决问题的痛苦

要在开发过程当中作到持续集成并不容易，首先须要养成这个习惯。并且集成工做每每是十分枯燥、烦琐的，所以适当地引入每日集成工具是十分必要的。XP建议你们首先使用配置管理服务器将代码管理起来，而后使用Ant或Nant等XP工具，编写集成脚本，调用xUint等测试框架，这样就能够实现每当程序员将代码Check in到配置服务器上时，Ant就会自动完成编译和集成，并调用测试代码完成相应的测试工做。

10. 每周工做40小时／可持续的速度

这是最让开发人员开心的、管理者反对的一个最佳实践了，加班、再加班早已成为开发人员的屡见不鲜，也是管理者最常使用的一种策略，而XP方法论认为，加班最终会扼杀团队的积极性，最终致使项目失败，这也充分体现了XP方法关注人的因素比关注过程的因素更多一些。

Kent Beck认为开发人员即便可以工做更长的时间，他们也不应这样作，由于这样作会使他们更容易厌倦编程工做，从而产生一些影响他们效能的其余问题。所以，每周工做40小时是一种顺势行为，是一种规律。其实对于开发人员和管理者来讲，违反这种规律是不值得的。

• 开发人员：若是不懂得休息，那么就没法将本身的节奏调整到最佳状态，那么就会带来很大的负面影响。并且在精神不集中的状态下，开发质量也得不到保证。
• 管理者：也许这能够称得上“第二种人月神话”，那就是你不得不经过延长天天的工做时间来得到更多的人月。这是由于，每一个开发人员的工做精力是有限的，不可能无限增加，在精力不足的时候，不只写出来的代码质量没有保障，并且还可能为项目带来退步的效果。所以采用加班的方式并非一个理性的方式，是得不偿失的。

不过有一点是须要解释的，“每周工做40小时”中的40不是一个绝对数，它所表明的意思是团队应该保证按照“正常的时间”进行工做。那么如何作到这一点呢？

首先，定义符合你团队状况的“正常工做时间”。

其次，逐步将工做时间调整到“正常工做时间”。

再次，除非你的时间计划一团糟，不然不该该在时间妥协。

最后，鼓起勇气，制定一个合情合理的时间表。

正如米卢说过的“享受足球”同样，一样地，每个开发人员应该作到“享受编程”，那么“每周工做40小时”就是你的起点。

团队只有持久才有获胜的但愿。他们以可以长期维持的速度努力工做，他们保存精力，他们把项目看做是马拉松长跑，而不是全速短跑。

11. 现场客户

为了保证开发出来的结果与客户的预想接近，XP方法论认为最重要的须要将客户请到开发现场。就像计划游戏中提到过的，在XP项目中，应该时刻保证客户负责业务决策，开发团队负责技术决策。所以，在项目中有客户在现场明确用户故事，并作出相应的业务决策，对于XP项目而言有着十分重要的意义。

也许有人会问，客户提交了用户故事以后不就完成工做了吗？其实不少尝试过用户故事的团队都会发现其太过简单，包含的信息量极少，XP方法论不会不了解，所以，不会把用户故事当作开发人员交付代码的惟一指示。用户故事只是一个起点，后面的细节还须要开发人员与客户之间创建起来的良好沟通来补充。

做为一名有经验的开发人员，绝对不会对现场客户的价值产生任何怀疑，可是都会以为想要实现现场客户十分困难。要实现这一点，须要对客户进行沟通，让其明白，想对于开发团队，项目成功对于客户而言更为重要。而现场客户则是保障项目成功的一个重要措施，想一想在你装修房子的时候，你是否是经常在充当现场客户的角色呢？其实这隐喻就是让客户理解现场客户重要性最好的突破口。

其实现场客户在具体实施时，也不是必定须要客户一直和开发团队在一块儿，而是在开发团队应该和客户可以随时沟通，能够是面谈，能够是在线聊天，能够是电话，固然面谈是必不可少的。其中的关键是当开发人员须要客户作出业务决策是，须要进一步了解业务细节时可以随时找到相应的客户。

不过，也有一些项目是能够不要现场客户参与的：

• 当开发组织中已经有相关的领域专家时。
• 当作一些探索性工做，并且客户也不知道他想要什么时（例如新产品、新解决方案的研究与开发）。

去尝试吧，现场客户不只能够争取获得，并且还能使得团队面目一新，与客户创建起良好的合做与信任。

12. 编码标准

编码标准是一个“雅俗共享”的最佳实践，无论是表明重型方法论的RUP，PSP，仍是表明敏捷方法论的XP，都认为开发团队应该拥有一个编码标准。XP方法论认为拥有编码标准能够避免团队在一些与开发进度无关的细节问题上发生争论，并且会给重构、结对编程带来很大麻烦。试想若是有人将你上次写的代码的变量命名法作了修改，下次你须要再改这部分代码时，会是一种什么感受呢？

不过，XP方法论的编码标准的目的不是建立一个事无巨细的规则表，而是只要可以提供一个确保代码清晰，便于交流的指导方针。

若是你的团队已经拥有编码标准，就能够直接使用它，并在过程当中进行完善。若是尚未，那么你们能够先进行编码，而后在过程当中逐步总结出编码规则，边作边造成。固然除了这种文字规范之外，还能够采用一些如自动格式化代码工具之类的方法进行代码规范。，事实上，你只须要很好地贯彻执行其余的实践而且进行沟通，编码标准会很容易地浮现出来。

13. 配合是关键

有句经典名言“1+1>2”最适合表达XP的观点，Kent Beck认为XP方法论的最大价值在于在项目中融会贯通地运用12个最佳实践，而非单独地使用。你固然可使用其中的一些实践，但这并不意味着你就运用了XP方法论。XP方法论真正可以发挥其效能，就必须完整地运用12个实践。

转载文章，原文连接 http://www.cnblogs.com/luoht/archive/2011/05/20/2051714.html