什么是RUP,XP,敏捷过程

RUP

RUP（Rational Unified Process），统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。
瑞理统一过程（RUP）是Rational软件公司（Rational公司被IBM并购）创造的软件工程方法 。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。

六大经验

迭代式开发
       在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程都以可执行版本结束，可以鼓舞开发人员。

管理需求
       确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用已被证明是捕获功能性需求的有效方法。

体系结构
        组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于降低管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

可视化建模
        RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。

验证软件质量
        在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。

控制软件变更
        迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。

二维开发模型
        RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle）、阶段（Phase）、迭代（Iteration）和里程碑(Milestone）；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动（Activity）、产物（Artifact）、工作者（Worker）和工作流（Workflow）。

开发过程

         RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑（Major Milestones）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

初始阶段

        初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑评价项目基本的生存能力。

精化阶段

        细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

构建阶段

        在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

移交阶段

        交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

迭代开发模式编辑
        RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期。这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。
        一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目。

RUP的迭代模型与传统的瀑布模型相比较，迭代过程具有以下优点：
        降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
        降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
        加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

XP

      极限编程（Extreme Programming，XP）是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。

极限编程的有效实践

1.   客户作为团队成员：客户参与到开发工作中来，负责确认需求、回答开发人员的问题并且设计功能验收测试方案。

2.   用户素材：对项目需求的简单的、模糊的概括，而不是详细的需求细节

3.   短交付周期：迭代计划——两周；发布计划——三个月（大约六次迭代）

4.   验收测试：使用简单脚本，在迭代开始前或迭代过程中逐步完成

5.   结对编程：结对的关系每天至少要改变一次

6.   测试驱动的开发：首先编写一个单元测试，然后编写代码使测试通过

7.   集体所有：每个程序员对项目的每个模块都有接触，都编写有自己的代

8.   持续集成：每隔一到两个小时就进行一次签入（check-in）,并使所有测试都通过

9.   可持续的开发速度：团队必须保持旺盛的精力和敏锐的警觉，不允许加班工作（发布前一周例外）

10.  开放的工作空间：全体参与者在一个开放的场所中工作，成员在这个场所中自由地交流和讨论。

11.   及时调整计划：计划应该是灵活的、循序渐进的。制定出项目计划之后，必须根据项目进展情况及时进行调整，没有一成不变的计划。

12.   简单的设计：1.考虑能够工作的最简单的事情；2.你将不需要它；3.一次，并且仅有一次

13.   重构：经常性地重构：每隔一个小时或半个小时一次

14.   隐喻：构造一个将整个系统联系在一起的全局视图（一个恰当的比喻），这有助于从整体上考虑系统。 

开发
工作环境
        为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也做得最好。每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房子中工作，还有茶点供应；每周40小时，不提倡加班；每天早晨，所有人一起站着开个短会；墙上有一些大白板，所有的Story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；下班后大家可以一起玩电脑游戏……
需求
        客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一直起着很重要的作用。开发人员和客户一起，把各种需求变成一个个小的用户故事（UserStory），例如“计算年级的总人数，就是把该年级所有班的人数累加。”；这些模块又会根据实际情况被组合在一起或者被分解成更小的模块；它们都被记录在一些故事卡（StoryCard）上，之后分别被程序员们在各个小的迭代中（Iteration，通常不超过3个星期）实现；客户根据每个模块的商业价值来指定它们的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；客户为每个需求模块指定验收测试（功能测试）。
每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面实现了相应的计划中的所有需求。而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发完成后才能开始使用。
设计
        从具体开发的角度来看，XP内层的过程是一个个基于测试驱动开发（TestDrivenDevelopment）周期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试（UnitTest）。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的；随着一个个小的需求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。XP提倡对于简单的设计（SimpleDesign），就是用最简单的方式，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式（BigDesignUpFront），因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计走查（Review）、代码走查以及重构（Refectory），所有的这些过程其实也是优化设计的过程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需求。
编程
        既然编程很重要，XP就提倡结对编程（PairProgramming），而且代码所有权是归于整个开发队伍（CollectiveCodeOwnership）。程序员在写程序和重构程序的时候，都要严格遵守编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。结对编程的好处是，一个人编写代码时另一个人在思考。思考者的头脑中保持总体概念，不仅手头问题的这一段，而且还有XP指导方针。例如，如果两个人都在工作，就不太可能会有其中一个说“我不想首先写测试”而离开。如果编码者遇到障碍，他们就交换位置。如果两个人都遇到障碍，他们的讨论可能被在这个区域工作的其他人听到，可能给出帮助。这种结对方式，使事情顺畅、有章可循。也许更重要的是，他能使程序设计更具有社交性和娱乐性。
测试
        既然测试很重要，XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到一起（ContinuousIntegration），每次整合后都要运行单元测试；做任何的代码走查和修改，都要运行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。除了单元测试之外，还有集成测试，功能测试、压力测试和系统测试等。所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一。

敏捷过程

敏捷过程的提出

       许多公司软件团队陷入了不断增长的过程泥潭.

       为矫正某些繁琐的软件过程

2001年2月，17个著名的软件专家达成一致并发起敏捷软件开发联盟

敏捷软件开发宣言

四条价值观：
个体和交互 胜过 过程和工具：
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 商务谈判
响应变化 胜过 遵循计划

工作细节

1，几乎每个周五，我们都会把软件提交给客户，到下一个周一或者周二，客户会给我们一份关于软件的变更列表。我们把这些变更排定一个优先级，然后把他们安排到随后几周的工作中。
2，为下两周做详细的计划，为下三个月做粗略的计划，至于一年以后的系统将要做什么，有个模糊的想法就行了。

十二条原则：
1，尽早、持续交付有价值的软件：初期交付功能要少，要频繁交付；
2，即使到了开发的后期，也欢迎需求的改变；
3，经常性交付，交付间隔越短越好；
4，在整个项目开发期间，业务人员和开发人员必须天天都在一起工作；
5，围绕被激励起来的个人来构建项目。给他们提供所需要的环境、支持和信任；
6，最具效果效率的沟通就是面对面交谈；
7，进度度量标准：客户需求的数量；
8，责任人、开发者和用户应该能够保持一个恒定的、长期的开发速度；
9，不断地关注优秀的技能和好的设计；
10，以最高地质量完成最简单的工作
11，最好的架构、需求和设计出自于自组织的团队
12，每个一段时间，团队会在如何更有效的工作方面进行反省，然后相应地对自己的行为进行调整。

结论：构成了一个可以帮助团队打破过程膨胀循环的方法。
(可供选择的敏捷过程：SCRUM, Crystal, FDD, ADP, XP)