敏捷开发与极限编程

敏捷开发与极限编程

简介

      2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟，敏捷开发过程的方法很多，主要有：SCRUM, Crystal,特征驱动软件开发(Feature Driven Development, 简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme programming ,简称XP).极限编程(XP)是于1998由Smalltalk社群中的大师级人物Kent Beck首先倡导的。

极限编程(XP)

      极限编程(XP)是敏捷软件开发中最著名的一个，它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

极限编程 是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。XP实际上是一种经历过很多实践考验的一种软件开发的方法，它诞生了大概有5 年，它已经被成功的应用在许多大型的公司，如：Bayeris che Landesbank，Credit Swis s Life，DaimlerChrysler，First Union National Bank　Ford Motor Company and UBS.XP 的成功得益于它对客户满意度的特别强调，XP 是以开发符合客户需要的软件为目标而产生的一种方法论，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。同时，XP 也很强调团队合作。团队包括：项目经理，客户，开发者。他们团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。XP 强调四种价值：交流，简易，回馈，勇气。XP 程序员之间紧密的相互交流，XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，XP 就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。
XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
XP属于轻量开发方法中较有影响的一种方法。轻量开发方法是相对于传统的重量开发方法而言。简单地理解，“量”的轻重是指用于软件过程管理和控制的、除程序量以外的“文档量”的多少。XP等轻量开发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方面需要消耗大量开发资源，同时却已失去帮助“ 预见、管理、决策和控制的依据”的作用。因此必须重新审视开发环节，去除臃肿累赘，轻装上阵。
一、XP的核心思想
      从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块，并且强调测试、代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。
二、XP的十二种方法
      规划策略(The Planning Game)；
      结对编程(Pair programming)
      测试(Testing)
      重构(Refractoring)
      简单设计(Simple Design)
      代码集体所有权(Collective Code Ownership)
      持续集成(Continuous Integration)
      现场客户(On-site Customer)
      小型发布（Small Release）
      每周40小时工作制（40-hour Week）
      编码规范（Code Standards）
      系统隐喻（System Metaphor）
三、XP的四个核心价值
      极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。

XP用“沟通、简单、反馈和勇气”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈和勇气”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。

四、XP 带给我们的变化

通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。这是真的吗？XP认为事实并非如此。

一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说：“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，这是你客户一定会注意到的一些事情。

另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到 bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。

一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP 中，你的客户应该明确的知道这一点。

XP开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。

五、我们什么时候用XP

XP方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。

XP方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。

XP方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。

另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法。

在XP方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。假如对于你的开发来说，这是很重要的方面，你就可以选择XP 了。

下面是极限编程的有效实践：

1.     完整团队XP项目的所有参与者(开发人员，客户，测试人员)一起工作在一个开放的场所中，他们是同一个团队的成员，这个场所的墙壁上随意悬挂着大幅的，显著的图表以及其它一些显示他们进度的东西。

2.     计划游戏计划是持续的，循序渐进的，每两周，开发人员就为下两周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

3.     客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

4.     简单设局团队保持设计恰好和当前的系统功能相匹配，它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西。并且包含尽可能少的代码。

5.     结对编程所有的产品软件都是由两个程序员，并排坐在一起在同一台机器上构建的。

6.     测试驱动开发编写单元测试是一个验证行为，更是一个涉及行为。同样，他是一种编写文档的行为，编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

7.     改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净，具有表达力。

8.     可持续的速度，团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑，极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程，极限编程是一种优良的，通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

 

敏捷开发

人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。

敏捷软件开发宣言：

① 个体和交互      胜过  过程和工具

② 可以工作的软件  胜过  面面俱到的文档

③ 客户合作        胜过  合同谈判

④ 响应变化        胜过  遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值

◆ 我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。

◆ 即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。

◆ 经常性地交互可以工作的软件，交互的间隔可以从几个星期到几个月，交互的时间间隔越短越好。

◆ 在整个项目开发期间，业务人员和开发人员必须要天天都在一起工作。

◆ 围绕被激励起来的个体构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。

◆ 在团队工作内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

◆ 工作的软件是首要的进度度量标准。

◆ 敏捷过程提倡可持续的开发速度，责任人，开发者和用户应该能够保持一个长期的，恒定的开发速度。

◆ 不断地关注优秀的技能和好的设计增强敏捷能力。

◆ 简单是最根本的。

◆ 最好的构架，需求和设计出于自组织团队。

◆ 每隔一定的时间，团队会在如恶化才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

◆ 敏捷团队依靠变化来获取活力，团队几乎不进行预先设计，因此，不需要一个成熟的初始设计，他们更愿意保持设计尽可能的干净，简单，并使用许多单元测试和验收测试作为支援，这保持了设计的灵活性，易于理解性，团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计，为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则加以避免，这些原则是：

◆  单一职责原则(SRP)

就一个类而言，应该仅有一个引起它变化的原因

◆ 开放-封闭原则(OCP)

软件实体应该是可以扩展的，但是不可修改。

◆ Liskov替换原则(LSP)

子类型必须能够替换掉它们的基类型。

◆ 依赖倒置原则(DIP)

抽象不应该依赖于实现细节，细节应该依赖于抽象。

◆ 接口隔离原则(ISP)

◆ 重用发布等价原则(REP)

重用的粒度就是发布的粒度

◆ 共同封闭原则(CCP)

包中所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生产生影响，而对于其他的包不造成任何影响

◆ 共同重用原则(CRP)

一个包中的所有类应该是共同重用的

◆ 无依赖原则(ADP)

在包的依赖关系图中不允许存在环

◆ 稳定依赖原则(SDP)

朝着稳定的方向进行依赖

◆ 稳定抽象原则(SAP)

包的抽象程度应该和其稳定程度一致

敏捷设计是一个过程，不是一个事件，它是一个持续的应用原则，模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能简单，干净和富有表现力。