XP在很多方面都和我们传统意义上得软件工程不同，同时，它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。

特点如下：

不采用瀑布式得软件工程方法，而采用原型法。将一个软件开发项目分为多个迭代周期，每个周期实现部分软件功能。在每个周期都进行提出需求、设计软件架构、编码、测试、发布得软件开发的全过程。每个周期都进行充分的测试和集成。这样的好处是可以不断的从客户方面得到反馈，更逼近实际的软件需求。通过频繁的重新编码的过程，可以非常适应功能更改的需求，同时增加软件的易维护性。在不断的迭代中，避免架构设计的重大失误造成的软件不能如期交工，避免了软件设计的风险。

在软件设计中，强调简单性，就是坚决不作用不到的通用功能。同时，也不刻意避免重新编码，只有不断得重新编码才能保证软件得合理性。不害怕对整个软件推倒重做。认为重新编码是很正常得现象。每次得重新编码都会大大减少软件中得熵值。

在专业分工中，提出在开发团队中要有全职的客户人员的参与，同时在软件团队中也要有自己的领域专家。这样，可以和客户充分交流，彻底了解应用需求。这种软件需求的提出不是一次性的，而是不断的交流。

也有专门的软件架构的设计师，首先进行软件整体架构的设计。这种设计一般使用UML语言。

在软件开发的顺序上，和传统方法完全相反。传统方法是按照整体设计、编写代码、进行测试、交付客户的方法。而XP是按照交付客户、测试、编码、设计的顺序来开发。首先将要交付客户的软件的界面作出来，先让客户对软件有实际体验，这样，可以获得客户的更多的反馈，使需求可以在开发前确定。在编码前就先把测试程序做好，这样，编码完成后就可以马上进行测试。通过不断的测试来保证软件的质量。在进行软件架构设计之前就进行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。

在项目计划的实现上，每次的计划都是技术人员对客户提出时间表，由最后的开发人员对项目经理提出编码的时间表。这种计划都是从下而上的，不是从上到下的，更容易保证计划的按时完成。同时，多个迭代周期也使工期的估计越来越精确。

在分工上，强调角色轮换，项目的集体负责，分工的自愿性。分工的自愿性就是每个人的工作内容不是由项目经理分派，而是由每个人自愿领取，这样保证了每个人可以发挥自己的特长，适应自己的情况。当然，在每个问题上都要有唯一的决策人，同时，也要经过充分的交流和沟通。角色轮换就是在项目中，一个人在不同的周期中担任不同的角色，可以保证每个人对项目的整体把握，方便项目中的沟通和理解。项目的集体负责，就是每个人不是完成自己的工作就可以了，要对整个项目的完成负责，任何人都可以对工作的任何部分提出自己的建议。任何人都可以从事任何工作。任何人都要对整个项目熟悉。这样做的优点是可以充分的锻炼人、可以发挥每个人的积极性、可以使项目不依赖于某个特定的人，方便今后的软件的维护，通过工作内容的变换可以提高人工作的兴趣。通过角色轮换还可以使每个人都劳逸结合，方便相互理解，避免由于不理解而造成的各种配合问题。

保证8小时工作制，避免加班。

（我加几条：要有充分的培训、要有每个人的提升空间、制定报酬要根据对企业的贡献大小，而不是职位的高低，允许下属比上级薪酬更高，薪酬的高低取决于绩效评定，同时绩效评定要尽可能量化。并且推行淘汰制。同时有有效的招聘制度。有强有力的后勤保障制度和轻松的企业文化。）

提出了成对编程的思路，就是每个模块的编码都是两个人一起干，共用一台电脑。这样，一个人编码时，令一个人就可以检查代码，或对编码的思路进行思考，写文档等。不再有另外的测试人员，两个人同时完成代码的测试，并且使先写测试程序然后再编程。这样避免了编程人员和测试人员的矛盾。也解决了一个人自己检查的局限性。两个人共同检查可以避免大多数的错误。在共同编程中还可以进行经验的交流和传授。也避免了将一个工作一直干下去的无聊，交流增加了情趣。并且两个人共同工作也增加了工作量的弹性，使项目计划的瓶颈工作能尽快解决。根据成对编程的思路，开发小组也可以分为两个小组，一个小组进行开发，另一个小组作改进和bug修正等工作。也有同样的效果。

在人员的分工上要灵活，要保证软件开发中的角色的齐全，但每个角色可以由几个人共同担任，也可以一个人担任几个角色，并且在项目的不同时期，不同角色的人员数量会不断变化。

每天或隔天，开一个站立会议（保证开会时间尽量短），来解决工作时间不一致和相互打扰工作的情况。在每个迭代周期也有一个计划和分工等的全体大会。

XP的实施方法就要求能适应工作中出现的问题，不断对xP进行改进，而不能照搬套用。

XP的目标就是发挥人的最大积极性，保证充分的交流。

XP得优势是能很好得适应需求得更改、设计框架得更改。

XP采用和建立一个通常框架相反得方法来适应需求，而是尽量简单。

--------------------------------------------------------------------------------

问题：
有没有感觉实施xp的前提条件很多，如果这些条件不能满足就不能充分事实xp.例如8小时工作，工作环境等。

8小时工作可以说即是前提又是结果，如果不能8小时工作，让开发队伍有充分休息，大家怎么能结成pair，高效的开发？而如果开发效率低下，大家有怎么可能只8小时工作。--notyy

XP可以说是各种思想的大集合，实际上XP的核心特点就是原型法的软件开发方法。其它的各种特点可能不一定是XP独有的，只是针对目前软件工程中存在的问题，分别提出了很多思路独特的方法。这些方法并不是一个紧密的整体，相互直接有可能分离、独立。因此，了解了XP的方法，可以只应用它的几个特点，不一定全部照搬。比如成对编程、8小时工作制、轮岗等，都可以单独实施。－－tomz

这个观点不认同，XP核心特点并不是原型法的开发方法。原型法的关键是在通过原型获取需求后，要毫不犹豫的抛弃原型，重新开发，因此原型可以是很粗糙的，代码质量可以是很拙劣的。而且因为原型是用来获取整体需求，所以要求原型要完整，覆盖到整个项目的各功能点。 而xp是迭代开发，并没有一个包含所有功能的“原型”版本，而且对每一个“小版本”都有很高的质量要求，比如总共有10个功能点，原型法要求做一个覆盖所有10个功能点的粗糙版本，而XP要求先做一个有2个功能点的版本，然后再每个开发周期往上面加两个功能点，并且这包含两个功能点的版本是要“确实完成”的，是要经过充分的测试，重构、提炼的，让人放心的小版本。这一点与原型法有很大差别。 ----notyy

啊，我是门外汉，确实没有搞清“迭代”和“原型”的区别。用词有误。那就是说：“XP的核心特点是迭代”。－－tomz

我感觉部分岗位的集体主义的软件开发也是XP的很有用的方法。但不知道在中国是否符合国情。－－tomz

本文是根据IBM一个开发团队的XP故事总结的，在www.linuxaid.com.cn网站上看到的。但现在在IBM和linuxaid网站上都找不到这个文章了。－－tomz

精彩文章，可否转载？--notyy

转载没问题，这只是我的一个读书心得，没有发表过。不过你要转载到哪里？这里不是你的网站吗？已经贴上来了啊？－－tomz

--------------------------------------------------------------------------------

question:
“在进行软件架构设计之前就进行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。 ”
notyy兄，能详细讲一下吗？ 先编码后设计，有点不理解他的优点。。你先讲一下好吗？ 踏冰
世界上并没有先编码后设计的开发方法。xp的开发方法是边设计边编码。
所谓先编码后设计里的设计是指软件架构的设计，指先设计（和编码）局部的功能，在进行了几个周期的开发，有了足够多的需求和经验后再提炼出体系架构，是一种自下而上的设计方式。
好处是避免了先设计软件架构后编码的方式中容易出现的设计脱离实际，无法编码实现等问题。
缺点是早期设计变化剧烈，不断的refactoring，可能几个开发周期后，经过大量修改后设计会和第一个开发周期时所做的设计相差巨大。 但另一方面，这也正好说明，在编码前先设计软件架构，是非常困难的，很容易在后期发现难以克服的问题。--notyy

--------------------------------------------------------------------------------

2002-8-30 23:51:13 tomz
极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接，前两者容易和最终编程产品脱节，容易做很多无用工，而对编程者来说，代码是最好的表达工具，所有的结构设计思想都马上可以用代码来表达，因此，不需要先对别人描述架构，只要编出来，别人自然懂了。

使用架构来表达毕竟了用编程直接表达在结构上会有脱节的地方。

另外，极端编程不明确区分设计者和编程者，编程者就是设计者，自然，程序代码就成了比较方便的架构表达工具。将两步并作一步，自然节省设计时间。

当然，并不是事先没有沟通，而是极端编程认为口头交流是最有效的，因此，就用不到架构描述工具。