请告诉我什么是RUP方法，什么是XP。

rup- www.rational.com

人都是这么过来的，你不用烦恼……
用google查一把，资料多得要命。然后再来问。

xp-eXtreme Programing
rup-rational unified process

我来给中文解释：

极限编程和rational统一开发过程

呵呵……

Study use google at first.

up

他（她）的要求是希望有人简介地讲一下大概。
sorry，偶两者都不太清楚。

偶知道一般谁都明白可以去google查，当然那样需要很多时间而且还要运气。
给出一个网站的作用相当于对一个问某某商店在那里的人说：这个地方在某某个城市里。

如果不能给于实质性的帮助，但又想给予的话，鼓励一下或许更好。
-------------------------------------------------------------------
这些是长久以来对于bbs的牢骚,借地发泄,大家多包涵.

二者的共同点是都鼓吹迭代开发的方式

RUP：rational统一开发过程

rational公司提供的软件开发过程方法，RUP告诉你软件开发应该做那些事情，分为哪些阶段，每件事情应该做到什么程度。RUP基本是一种根据风险大小安排次序的迭代过程，强调在开发早期找到相对稳定的构架，以免后期因为修改构架而增加太多工作量，另外RUP使用use case捕获需求作为每一次迭代开发的开始。

XP：极限编程

是一种指导你如何去开发的思想，按我的理解，XP的核心是尽可能把所有的事情简化。XP反对在开发过程中生成太多文档，不鼓励过多考虑未来的需求，鼓吹尽可能早期进行尽可能全面的测试，鼓吹周期尽可能小的迭代开发以便是系统尽可能早的投入使用。另外还注重双人编程、CRC和重构之类的技术。

up

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

特点如下： 

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

rational统一开发过程和极限编程

学习

XP 与CMM 、RUP 的比较
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]
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 目标。

-----

:)

学习。

to john2003() ：
  老兄，你的论述很精彩，希望你继续

to  panq(漫随天外):
  你的论述也很精彩，继续啊

没有办法还是我来说明一下吧 
首先XP没有明确指示必须使用原型 但是你使用原型是可以得到支持的 这里有一个原则就是你的原型一定要是快速建立的 我的建议最好是在几分钟或者几十分钟内建立 以便快速得到客户的反映 当然你如果把前面的迭代的产品看作一个原型 我也没有办法 XP是的迭代是强制性的 但是我见过在一个非常小的项目中实施XP 但是没有使用迭代 这是因为没有时间去迭代项目就结束了 其实XP强调的是短周期的迭代 当然周期短 那么迭代的次数必然会多 XP并不要求你每一个迭代都要完成同样的过程 例如XP强调的小版本多次发布并不是要求你每一个迭代都发布一个版本 其实你如果你发布的频率过于频繁并没有得到客户的仔细研究 那么得到的反馈也不会充分 这不是好的策略 所以在几个迭代周期后（比如我的周期是2个星期 那一个月发布一个版本我觉得合适）同时XP非常反对重复对一些事情编码 因此才有了REFACTORING 而由于有了这个强有力的工具所以基本上是没有所谓的框架设计 而有一些所谓纯粹的XPER非常反对去设计一个框架 
XP强调简单 其实更准确的说是强调刚好 也就是刚刚好 不多也不少 包括反对为未来设计 反对作框架设计 这是建立在勇气的基础上的 也就是有勇气认为明天的问题 在明天会有解决的办法 
XP所说的现场客户 并不是说你必须要真的有一个客户在场 而是说要有一个人起到客户在场的作用 当然有真正的客户去担任这个角色会更好 
XP基本上不做框架设计 所以也就没有所谓框架设计师这个角色 而很多纯粹的XPER反对使用UML 比如KENT BACK 
XP强调测试先行 也就是说在编码前要先写好测试 需求的确立也要有测试作为必须的一个步骤 所谓客户对他们提出的USERSTORIES 提出测试方案 而编程的效果就是看是不是通过了这些测试
关于项目的计划 XP认为计划不是为了要按照去执行的 而是指出项目进行的进度 而计划的制定 不是单纯由一方 而是认为客户可以制定成本 时间 质量 范围中的三个方面 开发者去确定另外一个 
任务指派会采取自愿的原则 而且任务会在迭代结束后进行轮换 而对结对也会轮换 但是这也是有原则的 不是要求所有的人都要轮换过所有的角色 这也是体现对开发者的意愿的尊重 
XP强调每周40小时工作 尽量避免加班 但是没有禁止你去加班 它只是告诉你长期的加班对项目开发只有坏处没有好处 
结对编程是说一对人使用统一台机器共同编写同一段代码 关于结对编程的讨论非常多 建议大家自己去找资料看 
建议大家还是去WWW.CHINAXP.ORG自己去看全面的XP介绍 

对于 panq(漫随天外) 转载的文章我的看法如下
作为从已经成为半垃圾的CMM角度看如日中天的XP 是一种有意思的做法 
CMM其实主要的是一种标准 而后来由于一些人为了谋求利益 是其成为一种方法 并且随着发展慢慢进化成一种骗局类似的东西 而且其所体现的思想基本是在上个世纪80年代的思想 如果你使用静室方法 我想你通过5级 会没有任何问题 而其实CMM在美国所处的地位历来是非常尴尬的 这种尴尬和ADA的情况还有所不同 至少你应该知道有些人认为CMM的级别越高说明其软件开发水平越低 CMM简直就是耻辱的标志 至少你可以看看Tom DeMarco是怎么说的
而RUP的不受欢迎其实也是因为起过多的商业色彩 它所提出的更是一种框架 一种模板 它要解决一切环境下 一切组织的开发过程问题 所以变得针对性不强 
同时大家注意其实如果你是彻底的实施这些方法 基本上不会通过CMM的评估 特别是高级评估 当然主要原因还是商业上的 

UP