设计体现沟通和最简化
尽管实现过程在不同的环境中可能完全不一样，但是在任何现代软件项目中，XP的价值都能得到体现。沟通和最简化原则是不可或缺的，没有他们甚至很小的项目都面临不可克服的难题。XP的沟通和最简化原则对采用软件CMM的企业来说也是基本的设计原则。当定义过程时，企业应该获取所需要的基本信息的最小集，利用良好的软件设计原则（比如信息隐藏和抽象）来构造这些定义，并且强调可用性和有效性。
当一个系统逐渐变得庞大的时候，一些XP实践也就变得很难实现。当项目变得庞大时，好的体系架构对于项目的成功也就变得日益关键。基于体系结构的设计、变更设计、精化和相似的设计哲学强调以一种系统化的方式来处理变更的需要。这些概念包括基于体系结构的设计和整合的产品团队，可能在一个大项目的环境中更加合适，也许在团队中再结合XP。在某种意义上来说，强调灵活性的体系化设计是任何好的面向对象方法论的目标，所以XP（包括精化）和面向对象是互相合适的。多纪律的团队也是有问题的，因为XP针对的是只有软件的项目。
极限编程过程严谨
使用XP进行过程改进的重要原因是，它几乎不触及软件CMM强调的管理和组织问题。在XP假设的这种高度合作的环境中合适地使用它要求初步进化的管理和合适的组织架构。CMM风格的过程纪律——甚至是到了刻板的程度，XP是严谨的过程，而且XP过程是一个定义明确的过程。
CMM和XP可以被认为是互补的。软件CMM指出了通常要做什么，但是没有说怎么样去做，而XP是一系列的最佳实践，包括了相当精确的“怎样做”的信息——是一个对某种特定环境的实现模型。
在级别2层次上，需求管理被故事、共同工作的客户和持续的集成描述。软件项目计划，被计划比赛和小型发布描述。XP的计划策略隐含着Humphrey的谚语：“如果您不能更好地计划，那就更多地计划”，软件项目跟踪和勘误被“大型可视表格”、项目速率和小型发布的承诺描述出来。承诺过程为XP中的客户和XP团队设置了在战术层面上的明确期望，并且在项目战略层面上最大化了灵活性。在XP中对每周40工时的强调是一个没有在CMM中描述但是被考虑为一个最佳实践的通用管理关注点。XP也强调了在CMM范围之外的开放的工作空间，人以群分的观点。
然而一个独立的SQA组不太可能成为XP文化的一部分。软件质量保证可以被结对编程的文化来描述；在XP环境中结对编程以保证对编码规则的遵从是一个典型的SQA的责任。
软件配置管理被团队所有权、小型发布和持续集成部分描述。虽然没有完整和明确的描述，配置管理隐含在这些XP实践中。团队所有权对大型系统也许是有问题的，在这样的环境下沟通渠道需要正规化以保证有效性，否则可能导致SCM的失败。
在级别3这个层次上，组织过程焦点被团队层面上而不是组织层面上描述，但是在一次采用一个XP的实践和“公正的规则”的哲学上后面隐含着关于过程的焦点。因为XP聚焦在软件工程过程而不是组织架构方面，这个或者其他组织层面上的过程是采用XP的企业需要描述的范围。同样的，过程定义和培训程序被在XP的多种书、文章、教程和网站中部分描述，但是企业资产是在XP范围之外。
软件产品工程化被XP用很多方式描述出来，它们包括隐喻、简单设计、精化、封存过程、编码标准、单元测试和功能测试。设计文档的缺乏在很多诸如高实时、大型系统或者虚拟团队的环境下应该是一个问题。在这样的环境中，良好的设计是成功的关键，而精化策略将冒很大的风险。
跨组合作以共同工作的客户和结对编程来描述。虽然仅限于软件的内容促使多纪律的环境，但是XP在沟通的重点看来会导出一个和集成产品和过程开发一样的基于跨组合作的解决方案。
虽然缺乏组织结构可能会减少它的有效性，但是在代码阅读和编程的意义上，结对编程可能比结对回顾更强。目前在结对编程上的经验数据虽然稀少但是看上去却是非常有效的。对照和比较结对编程和结对回顾这两项技术仍然是一个基于经验进行研究以作为做出具有充分数据支持的结论的领域。
虽然缺陷防止可能在快速的（迭代）循环中的反馈得到了部分描述，但是很少的级别4和级别5的关键过程域被XP以严谨的统计方式来描述。
许多在XP中部分或者根本没有描述的关键过程域在实际项目中毫无疑问是存在的。尽管这样的结论不是那么显而易见，XP不能在没有管理和基础架构支撑的情况下生存。
结论
大多数XP的项目方法是由充分考虑了任何环境的成功实践构成。然而任何这样的实践的价值在和处理同样问题的其他方法相比较的时候都存在争议，所以它们中间的任何一个都不应该被武断地拒绝。
把这些实践按照方法论组合在一起可能是一个和并发工程一样意义上的范例进化。并发工程中的概念已经（存在）数十年了；集成这些范例为一个系统导致一个在如何构建产品中的范例进化。与此相同，XP也提供了一个在编程方面的系统视角，正如软件CMM提供了一个在组织过程改进方面的系统视角一样。需要改进它们能力的组织应该利用它们良好的思想的优点并在选择和实现这些思想中实践常识（规则）。
软件CMM关注于设置有效和高效过程的管理问题，伴随着系统化的过程改进。XP是一个特殊的实践集——一个方法论——它在小的、共同办公的环境中是有效的。特别是和其他的好的工程和管理实践相结合的时候，它们都有可以协作增效的思路。XP是否应该效仿出版物中所说的一样被用于性命相关或者高可靠性系统是有疑问的。虽然缺乏设计文档和对体系结构的不重视可能被大多数现有知识的专家认为是冒险的决定，但是XP的好处之一就是它可以改变和改进以适应不同的环境。
改变XP的风险就是在它的环境中快速提供价值（功能）的特性可能不再出现。选择和改进软件过程的重点仍然应该是让常识（规则）起主要作用——而且当回答具有挑战性的问题时尽可能地利用数据以提供有力的洞察力。
可以得出结论，诸如XP的敏捷方法论提倡很多好的工程化实践，虽然其中一些实践在一个狭小的领域之外可能是有争议的和反产业化的，但是当在一个合适的环境中被充分实现的时候，XP从事了许多CMM级别2和级别3的实践。对于那些对过程改进感兴趣的人来说，应该慎重考虑在组织的业务环境中采用XP中的那些思想，因为XP可以被用来从事许多CMM级别2和级别3的实践。反过来，正在采用XP的组织应该仔细考虑那些在CMM中描述的管理和基础架构的问题。
