XP、SCRUM、CMM 、RUP 的比较
RUP是一套管理方法，用于项目从需求到发布的管理
而敏捷则是一种思想，一种价值观：价值迭代交付，以人为本
有一些基于敏捷思想的实践比如Scrum、XP等也都是管理方法或开发方法层面的内容
RUP可以与敏捷的思想结合，可以在敏捷思想指导下进行管理，那就是敏捷的RUP
1、XP 与CMM 的比较
CMM
告诉组织为了系统化地建立、实施和改进软件开发过程应该做些什么，但没有说明如何去做以及采用哪些具体的技术、策略和方法。CMM 是一套通用的过程实践标准，适用面很广。实施CMM 要求组织在过程的制度化建设上付出大量努力，通常被认为是重载（heavy-weight）的模型。
XP
是一个针对某种特定环境（需求变化快的小型团队）的具体过程实施模型和方法论。它其实是一种演进式的原型化方法（evolutionary
prototyping）[MCNL96]，具有沟通高效、设计简单、反馈迅速等特点，因而是一种轻载（light-weight）、敏捷（agile）的过程方法。
Mark Paulk 在他的文章中把XP 的实践方法与CMM
的KPA（关键过程域）进行了对照。得出的结论是，XP部分满足或大部分满足了CMM
2-3 级KPA的要求，而基本上没有涉及CMM 4-5 级的KPA。这说明XP
的做法基本符合了CMM 的目标和KPA，但还不完备。总体上看，XP
侧重于具体的过程和开发技术，而CMM 更关注组织和管理上的问题。XP
缺少的一个重要内容是“制度化（institutionalization）”，它不含有被CMM
认为是使良好的工程和管理实践制度化的关键基础设施和管理要件。[PALK01]
2、XP 与RUP 的比较
RUP（Rational Unified Process）
是一个风险驱动的基于UML
和构件式架构的迭代递增型开发过程（框架）。RUP 定义了4
个阶段（起始、细化、构造、移交）和9
个科目（业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境）。这些阶段对应着关键里程碑的划分，而不同科目的工作流和活动
在生命周期的迭代中可以并发进行，具体执行的程度则可以调节。RUP
对于角色、流程、工件和活动的要求是灵活的、可配置的，所以它广泛地适用于各种类型和规模的项目。RUP
集中体现了6
个软件开发的最佳实践方法：迭代式开发、需求管理、构件式架构、基于UML
的可视化建模、持续校验质量、变更管理。RUP
是一种以架构为中心的开发过程，而这正是大、中型项目成功的关键。
## XP
编码和设计活动融为一体，弱化了架构的概念，这是它与强调架构设计的RUP
的最大不同。架构的内涵要远大于一些简单的隐喻，它要考虑结构、行为、环境、使用、功能、性能、可靠性、弹性、重用、可理解性、约束和权衡乃至美学等诸多
方面的因素。设计架构的目的不是为了完美地表示系统的全部细节，而是为了消除最主要和最关键的架构风险。RUP
细化阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。另外，XP
没有包含业务建模、部署等概念，反映了它以编程为中心、节省一切的哲学。
当然两者也有不少共同点。例如，它们的基础都是面向对象方法（取代传统的结构化方法），都重视代码、文档的最小化和设计的简化，采用动态适应变化的演进式迭代周期（取代传统的瀑布型生命周期）、需求和测试驱动并鼓励用户积极参与等等。
由 于RUP
提供了非常丰富的内容，所以常常被误解为一个重载的过程。通过定制RUP
这个通用的过程框架，去掉项目不必要的工件（artifacts）和中间环节，把XP
的做法（比如短小的迭代周期、结对编程、测试优先的设计和重构）吸收进来，也可以实现RUP
过程的敏捷和轻量化[SMTH01]。“Bob 大叔”（Robert
Martin）甚至从RUP中裁剪出了一个酷似XP 的最小化RUP
过程——dx[MART01]。我设想，XP、RUP
乃至其他工程和管理方法可以统一起来使用，姑且成之为统一软件过程（Unified
Software Process，USP）。例如，一个大项目团队在起始和细化阶段采用RUP
方法完成需求分析和架构设计，在构造和移交阶段采用XP
的做法来实现部分子系统或模块。
“轻载”、“敏捷”是美丽的词汇，无人会拒之于门外。我想XP、RUP
的目标是一致的——提高团队效率、开发出高质量的软件，而区别就在于各自的侧重点不同，从而导致两者的适用情况和应用范围有差异。然而，它们是可以互补
的，无论是以架构为中心，还是以代码为中心，灵活运用的关键就在于掌握其中的最佳实践方法，实施RUP、XP
或者融合了两者的过程（比如USP）都将有助于组织更好地实现CMM 目标。
3、XP 与Scrum 的比较
敏捷(Agile)作为一种开发流程， 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum, 两者的区别如下：
- 区别之一： 迭代长度的不同
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.
- 区别之二: 在迭代中, 是否允许修改需求
XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队收到干扰
- 区别之三: 在迭代中，User Story是否严格按照优先级别来实现
XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.
- 区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
Scrum没有对软件的整个实施过程开出工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。因此，原作者认为， 这点上，XP的做法值得认同的，但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念，结合敏捷模式，表达给团队的信息是“你是一个完全自我管理的组织， 但你必须要实现TDD, 结对编程, ...等等”
不难发现，这四个区别显见的是：** Scrum非常突出Self-Orgnization,
XP注重强有力的工程实践约束**
作者建议， 在管理模式上启用Scrum，
而在实践中，创造一个适合自己项目组的XP(“start with Scrum and then invent
your own version of XP.”)
非常不错， 文武之道，有张有弛。