XP在很多方面都和我们传统意义上得 软件工程不同，同时，它也和传统的管理和项目计划的方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。
特点如下：
不采用瀑布式得软件工程方法，而采用原型法。将一个软件开发项目分为多个迭代周期，每个周期实现部分软件功能。在每个周期都进行提出需求、设计软件架构、编码、测试、发布得软件开发的全过程。每个周期都进行充分的测试和集成。这样的好处是可以不断的从客户方面得到反馈，更逼近实际的软件需求。通过频繁的重新编码的过程，可以非常适应功能更改的需求，同时增加软件的易维护性。在不断的迭代中，避免架构设计的重大失误造成的软件不能如期交工，避免了软件设计的 风险。
在软件设计中，强调简单性，就是坚决不作用不到的通用功能。同时，也不刻意避免重新编码，只有不断得重新编码才能保证软件得合理性。不害怕对整个软件推倒重做。认为重新编码是很正常得现象。每次得重新编码都会大大减少软件中得熵值。
在专业分工中，提出在开发 团队中要有全职的客户人员的参与，同时在软件团队中也要有自己的领域专家。这样，可以和客户充分交流，彻底了解应用需求。这种软件需求的提出不是一次性的，而是不断的交流。
也有专门的软件架构的设计师，首先进行软件整体架构的设计。这种设计一般使用UML语言。
在软件开发的顺序上，和传统方法完全相反。传统方法是按照整体设计、编写代码、进行测试、交付客户的方法。而XP是按照交付客户、测试、编码、设计的顺序来开发。首先将要交付客户的软件的界面作出来，先让客户对软件有实际体验，这样，可以获得客户的更多的反馈，使需求可以在开发前确定。在编码前就先把测试程序做好，这样，编码完成后就可以马上进行测试。通过不断的测试来保证软件的质量。在进行软件架构设计之前就进行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。
在项目计划的实现上，每次的计划都是技术人员对客户提出时间表，由最后的开发人员对 项目经理提出编码的时间表。这种计划都是从下而上的，不是从上到下的，更容易保证计划的按时完成。同时，多个迭代周期也使工期的估计越来越精确。
在分工上，强调角色轮换，项目的集体负责，分工的自愿性。分工的自愿性就是每个人的工作内容不是由项目经理分派，而是由每个人自愿领取，这样保证了每个人可以发挥自己的特长，适应自己的情况。当然，在每个问题上都要有唯一的决策人，同时，也要经过充分的交流和 沟通。角色轮换就是在项目中，一个人在不同的周期中担任不同的角色，可以保证每个人对项目的整体把握，方便项目中的沟通和理解。项目的集体负责，就是每个人不是完成自己的工作就可以了，要对整个项目的完成负责，任何人都可以对工作的任何部分提出自己的建议。任何人都可以从事任何工作。任何人都要对整个项目熟悉。这样做的优点是可以充分的锻炼人、可以发挥每个人的积极性、可以使项目不依赖于某个特定的人，方便今后的软件的维护，通过工作内容的变换可以提高人工作的兴趣。通过角色轮换还可以使每个人都劳逸结合，方便相互理解，避免由于不理解而造成的各种配合问题。
保证8小时工作制，避免加班。
（我加几条：要有充分的 培训、要有每个人的提升空间、制定报酬要根据对企业的贡献大小，而不是职位的高低，允许下属比上级薪酬更高，薪酬的高低取决于绩效评定，同时绩效评定要尽可能量化。并且推行淘汰制。同时有有效的招聘制度。有强有力的后勤保障制度和轻松的企业文化。）
提出了成对编程的思路，就是每个模块的编码都是两个人一起干，共用一台电脑。这样，一个人编码时，令一个人就可以检查代码，或对编码的思路进行思考，写文档等。不再有另外的测试人员，两个人同时完成代码的测试，并且使先写测试程序然后再编程。这样避免了编程人员和测试人员的矛盾。也解决了一个人自己检查的局限性。两个人共同检查可以避免大多数的错误。在共同编程中还可以进行经验的交流和传授。也避免了将一个工作一直干下去的无聊，交流增加了情趣。并且两个人共同工作也增加了工作量的弹性，使项目计划的瓶颈工作能尽快解决。根据成对编程的思路，开发小组也可以分为两个小组，一个小组进行开发，另一个小组作改进和bug修正等工作。也有同样的效果。
在人员的分工上要灵活，要保证软件开发中的角色的齐全，但每个角色可以由几个人共同担任，也可以一个人担任几个角色，并且在项目的不同时期，不同角色的人员数量会不断变化。
文章来源于领测软件测试网 https://www.ltesting.net/
