信管网yan***： [回复]
敏捷开发方法xp的十二个最佳实践分别是现场客户，代码规范，每周40小时工作制，计划博弈，系统隐喻，简单设计，测试驱动，代码重构，成对编程，持续集成，小型发布和集体所有权。
信管网chenxuf***： [回复]
系统的设计要能够尽可能早地交付属于小型发布这个最佳实践。敏捷开发方法xp的十二个最佳实战分别为现场客户，代码规范，每周40小时工作制，计划博弈，系统隐喻，简单设计，测试驱动，代码重构，成对编程，持续集成，小型发布，集体所有权。
信管网wzca***： [回复]
现场客户（on-site customer）。客户的需求不是一成不变的，往往在需求收集阶段事情总是很抽象，就连客户自己都不知道他们具体要什么，他们只是提供一个轮廓，要我们 双方共同去构造理想中的产品。但是我们，包括客户都不可能预测说我们现在定下来的需求就是真正的一成不变的需求，总是有千万个理由会促使需求的变动，也就 是说需求的变动是必不可免的，它不是单纯的可以人为控制的。那现在的问题是，但需求变动时，我们有能力迎接（适应）它吗？现在xp提出了几种最佳实践来迎 接需求的变动，而其中一种既是on-site customer，通过客户在整个项目中的不断参与我们可以保证我们所作的一切都真正是客户想要的，而我们不会浪费时间与精力在不需要的功能上。这是按时 交货，交好货的一种关键做法。注意这个最佳实践要求的并不是客户每天8小时的参与项目，而是但我们需要客户解答某些需求疑问时，客户能及时的提出意见，给 出反馈！
小发行版（small releases）。上面提到了需要客户能及时给出反馈，那么及时得到反馈的一种好的做法就是提供给客户软件的预览版，毕竟没有实物客户很难提出他们对我 们正在做的项目的看法。xp要求小发行版正是这个用意，通过快速的小的迭代开发得到很多的小版本，然后将这些小版本拿给用户体验，收集反馈，再根据用户的 反馈继续下一个小版本的迭代开发，这是一个良性循环，保证了项目不走歪路，保证了客户对我们正在做什么没有偏见，同时也保障了项目的质量，因为直接参与测 试的同时也有我们的客户。
简单的设计（simple design）。上面讲的是从需求的角度出发的，现在让我们来看看开发流程方面。我们都知道设计是好的，而事物总是保持越简单越好，那么为什么不选择简单 的设计呢？通过简单的设计我们可以快速的理解与开发。但是但靠简单的设计往往不是很有作用，很快我们就发现以往的设计已经不再有弹性，很快就不能满足我们 的需要了。这里就是体现xp精华概念的时候了，xp中有极限一词，也就是说不管是做什么，都要做到极限。简单的设计也不例外，同样也要不断的迭代，通过在 简单的设计上重构出另一种简单的设计来不断改变设计与设计质量，会让你在不知不觉间作出与超级设计大师一样优质的设计。（当然，如果你真的很糟糕，那么即 使xp再好我想也帮不了你了）
规划策略（planning game）。既然简单的设计有助于快速的进展那么不断的规划也一定会帮助到项目的方方面面。很难说架构师做好的架构就一定不会在后期改变，既然需求都很有 可能有大改变，那么架构与整体项目规划也不是一成不变的。这是xp的核心，xp告诉你如何迎接变化，如何在快速变化的今天作出最优质的产品，真正满足客户 的需求。
系统隐喻（system metaphor）。说实话，我也是刚刚开始真正了解xp，所以对这个实践还不太了解，所以这里就不谈了，免得败坏xp的名声！^_^
重构（refactoring）。我想很少有人在这个年代没有听到过重构吧？上面所讲的很多方面都是基于这个思想的。既然设计是好的， 那么我们能不能快速的、小步的迭代设计呢？能不能通过不断的改善已有的代码来使它们更健壮呢？目前的项目大多数都会在维护一段时间后变的僵硬，代码越来越 难以维护，有时不得不写一些自己都认为很难看的代码来维护新增或修改的功能，而正是这样的动作导致了下一次维护时的困难，使代码陷于了恶性循环，使的项目 的维护成本越来越高，最后不得不放弃维护而重新开发。xp提出了迭代的重构方案，它使我们每一次都先重构再在重构好的代码的基础上再做修改，这使得我们每 次都不用花太多的精力去完成对代码的维护而又与此同时提高了代码的简易度、健壮度。
结对编程（pair?programming）。既然对设计、对代码的评审是好的，那么为什么不随时评审呢？通过评审，我们可以用 多个人的脑袋想问题，寻找解决方案，无疑这要比只用一个脑袋要好的多，毕竟人多力量大嘛，曾经也有教育家做过试验，证明了在群组讨论学习的环境下学生学到 的知识更深刻，理解的更透彻，思想也更活跃。软件开发又何尝不是如此呢？我不完全赞成“结对”，但是我赞成有问题就问，不管什么样的问题，不管什么样的同 事，只要你有疑问，那么你就可以向大家提出来，看看每个人的想法，这会使你最终得到一个当前最好的解决方案。
集体所有权（collective ownership）。在上个实践中其实已经提到了这个集体所有权的概念，既然你有问题就可以问，别人又都参与你给你他们认为的可能性答案，那么是不是反 过来但别人有问题的时候你也要主动参与提出自己的看法呢？这种把多个大脑运作在一起的模式就是xp中集体所有权的概念了，在这里没有个人的殊荣，只有团体 与团体的共同目标。注意这里就是xp的特点了，xp是以人为本，xp坚信人与人之间的作用要比单纯的依靠技术要更重要的多。毕竟只有最后依靠到人心上，项 目才可能获得最后的成功。而作为一名xp开发人员也意味着你的个人休养与风格。
编码规范（code stａｎｄards）。代码在xp中被看作一项非常重要的在开发人员之间沟通的工具。毕竟软件反映了开发者的心智，开发人员的思想变为一行行代码被写在程 序中，这是一门艺术。但艺术也要有人去欣赏，如果每个人都看不懂其他人的艺术，那么怎么进行沟通呢？集体所有权让我们每个人都可以去改进其他人的代码，那 么如果没有统一的编码规范将不是一件容易的事了。
一周40小时（40-hour week）。xp不主张加班加点，这只能是当有某些环节出问题的前兆。xp在每次快速的迭代中都很明确下一次迭代要做什么，xp有很高的可控性。
测试（testing）。测试是xp的核心部分，是xp重要的环节，也正是处于这种原因，我将两种测试放在了最后面介绍，不是因为它们 不重要，而相反是因为它们太重要了！测试其根本目的是为了保证质量，告诉我们所作的一切没有白做，它的确可行。xp中的自动化测试（常指简单有效的单元测 试）是非常关键的，它有多重目的。其中一个很重要的目的就是给予我们开发人员信心，试想每次系统变动后运行自动化测试时看到一排路灯亮着是那么畅快的一件 事啊！xp主张先测试后编码，每次的测试用例都能够反映出最确切的需求，测试亦是设计的一部分。其中的奥妙真的是只有真正用过才能体会得到。
持续集成（continuous integration）。这是另一种保证质量的测试手段，通过反复快速的集成我们可以及早发现软件中的隐患，同时持续集成也可以提供给我们多个小版本 （small releases）以便客户的反馈。这个概念比较像微软提出的每日编译，只是xp并没有规定必须每日执行一次，xp反而主张每几个小时甚至每几分钟集成一 次，总之就是当有较大变动时就及时集成给出反馈，这一点也能够充分的体现出xp极限编程中的极限来！
|