敏捷过程与极限编程（XP）

一、敏捷过程

为了使软件开发团队具有高效工作和快速响应变化的能力，17位著名的软件专家于2001年2月联合起草了敏捷软件开发宣言。敏捷软件开发宣言由下述4个简单的价值观声明组成。

（1） 个体和交互胜过过程和工具

优秀的团队成员是软件开发项目获得成功的最重要因素；当然，不好的过程和工具也会使最优秀的团队成员无法发挥作用。团队成员的合作、沟通以及交互能力要比单纯的软件编程能力更重要。

正确的做法是：首先致力于构建软件开发团队（包括成员和交互方式等），然后再根据需要为团队配置项目环境（包括过程和工具）。

个人理解：一个好的团队是获得成功的前提，这往往比个人的编程能力更重要。

（2） 可以工作的软件胜过面面俱到的文档

软件开发的主要目标是向用户提供可以工作的软件而不是文档；但是，完全没有文档的软件也是一种灾难。开发人员应该把主要精力放在创建可工作的软件上面，仅当迫切需要并且具有重大意义时，才进行文档编制工作，而且所编制的内部文档应该尽量简明扼要、主题突出。

个人理解：在软件开发过程中，提供给用户切实可用的软件是主要目的，但是，如果没有文档的软件是一种灾难。开发好可用的软件是研究人员的主要目标。

（3） 客户合作胜过合同谈判

客户通常不可能做到一次性地把他们的需求完整准确地表述在合同中。能够满足客户不断变化的需求的切实可行的途径是，开发团队与客户密切协作，因此，能指导开发团队与客户协同工作的合同才是最好的合同。

个人理解：如果把精力放在合同谈判上固然可以为团队争取到更多利益，但是如果因此而忽略了最根本的开发软件的需求，等到需要提交软件的时候，发现提交的文档与客户的要求不符，就会产生不良的后果。

（4） 响应变化胜过遵循计划

软件开发过程中总会有变化，这是客观存在的现实。一个软件过程必须反映现实，因此，软件过程应该由自购的能力及时响应变化。然而没有计划的项目也会因陷入混乱而失败，关键是计划必须有足够的灵活性和可塑性，在形式发生变化时能迅速调整，以适应业务和技术等方面发生的变化。

个人理解：俗话说:计划赶不上变化，这个原则也是如此，不要去死守计划，要懂得适当变通。

在理解上述4个价值观声明时应该注意，这些声明只不过是对不同因素在保证软件开发成功方面所起作用的大小做了比较，说一个因素更重要并不是说其他因素不重要，更不是说某个因素可以被其他因素代替。

根据上述价值观提出的软件过程统称为敏捷过程，其中最重要的是极限编程（xp）。

二、极限编程（XP）

极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能性以及面临的困难。1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。适用于小团队开发。

极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

1.开发

●工作环境

为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，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开发过程中最重要的文档之一，也是最终交付给用户的内容之一。

2.极限编程的有效实践

1、完整团队
    XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
2、计划游戏
    计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
3、客户测试
    作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
4、简单设计
    团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
5、结对编程
    所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
6、测试驱动开发
    编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
7、改进设计
    随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。
8、持续集成
    团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。
9、集体代码所有权
    任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。
10、编码标准
    系统中所有的代码看起来就好像是被单独一人编写的。
11、隐喻
    将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
12、可持续的速度
    团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。