软件过程改进4（敏捷开发）

1、软件工程一级学科硕士研究生学位课程软件过程改进河海大学计算机与信息学院第四讲敏捷开发方法与极限编程XP敏捷开发方法极限编程XP总结目 录敏捷方法的含义敏捷：轻巧、机敏、迅捷、灵活、活力、高效敏捷开发是一种面临迅速变化的需求快速开发软件的能力敏捷过程很容易适应变化并迅速做出自我调整，在保证质量的前提下，做到文档、度量适度适用于各类软件企业核心思想 敏捷软件开发方法的思想是现代管理理念的延伸，其核心是以人为本，迭代、循序渐进的开发方法。敏捷软件开发方法认为，对项目最重要的影响因素是人，而不是过程和技术。不能把人员当做由过程驱动的“可插拔替换的编程单元”，而要发挥人的能动性，建立紧密协作的、自组织的

2、团队。敏捷软件开发宣言我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为： 人和交互 重于 过程和工具 可以工作的软件 重于 面面俱到的文档 客户合作 重于 合同谈判 随时应对变化 重于 遵循计划 虽然右项也有其价值，但我们认为左项更加重要。敏捷软件开发宣言 人和交互重于过程和工具只有好的过程而缺乏合格的人员，不能保证项目不失败。优秀的人员不一定是顶尖的技术人才，但一定能和其它人员良好地协作。拥有一般的技术人才，但能够有效沟通、紧密协作的团队比那种虽拥有技术精英，但不能有效沟通的团队更有可能取得成功。敏捷软件开发宣言 人和交互重于过程和工具工具虽然重要，但那种

3、最先进的、大而复杂的工具不一定适合组织的需要，而且可能会给组织带来负面影响。先尝试小而灵便的工具。首先要致力于建立团队，然后让团队根据自己的需要配置工具环境。敏捷软件开发宣言可以工作的软件重于面面俱到的文档过多的文档会带来许多负面影响。需花费许多资源来产生这些文档并保持它们之间的一致性（特别是文档与编码之间的一致性）。如果不一致，文档将成为产生混乱的根源。应该书写一些文档来描述系统的基本结构和原理，但文档一定要短而精炼，只用来描述总体设计原理和最高层次的系统结构。敏捷软件开发宣言 可以工作的软件重于面面俱到的文档代码已包含了最丰富的、且无歧义的系统信息。当有新的成员加入项目团队，通过与他不断地

4、交流和密切地合作来使他熟悉当前项目，而不是让他阅读大量文档。不要去产生文档，除非有紧迫而明显的需求。敏捷软件开发宣言 客户合作重于合同谈判软件项目的成功依赖于客户频繁的反馈，而不是依赖于与客户达成的合同或协议。合同中所规定的需求、进度和成本很容易变得没有意义，因为项目处在持续不断的变化中。客户必须每天与开发团队一起工作，对开发团队的工作及时提供反馈。敏捷软件开发宣言随时应对变化重于遵循计划由于项目中存在很多不确定因素，应对变化的能力常常决定了项目的成败。计划必须是灵活的，能够适应业务和技术的变化。一个比较好的计划策略是：对未来两星期的工作制定详细的计划；对未来3个月的工作制定很粗略的计划；对更

5、远的时间段，则制定最初级的计划。敏捷开发原则由敏捷软件开发宣言的思想衍生出敏捷软件开发的12条原则。（1）我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户的需要有统计数字表明，越早、越频繁地向用户交付软件，软件的质量就越好。敏捷开发方法力求项目开始几周后，就向用户交付一个最初的系统，以后每隔两周就交付一个增加了功能的系统。（1）我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户的需要对于每次交付的软件，客户可以将其投入应用，如果软件的功能还不足以满足应用的需要，就只对其进行审查，并提出修改意见。敏捷开发原则（2）欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，

6、为客户创造竞争优势使用敏捷过程的开发组织欢迎需求的变化，因为他们认为需求变化可以让它们更多地了解市场。敏捷开发组织采用各种方法和技术，使软件的结构高度灵活，需求的变化对系统的影响被最小化。敏捷开发原则（3）频繁交付可以工作的软件，从几个星期到几个月，时间越短越好敏捷开发组织不满足于交付文档和计划，他们的目标是频繁地交付可以工作的软件，从而满足客户的需要。敏捷开发原则（4）在整个项目开发期间，业务人员和开发人员必须每天工作在一起软件项目必须被不断地调整和引导，这要求用户、开发者和其他利益干系人要频繁地交流。敏捷开发原则（5）围绕斗志高昂的人构建项目，给他们提供所需的环境和支持，并且信任他们能够完

7、成任务在一个敏捷项目中，人员被认为是最重要的因素，其它所有因素（过程、环境、管理等）都被认为是次要的，当这些因素对人员造成不利影响时，就必须对其做出改变。例如，如果某些过程步骤对团队人员来说是个障碍，那么过程就必须改变。敏捷开发原则（6）在团队内部，最有效率和最有效果的信息传达方式就是面对面的交流在敏捷项目中，主要的交流方式是面对面的交谈。文档在必要的时候会被创建，但不会试图用文档来捕获所有项目信息。在敏捷项目组中，默认的交流方式是交谈，而不是文档。敏捷开发原则（7）可以工作的软件是进度的主要度量标准对于敏捷项目来说，进度的度量标准是当前可满足用户需求的软件的量，而不是当前项目所处的阶段、文档

8、数量或基础代码的数量。项目完成了30%的含义是30%的用户所需功能已被实现。敏捷开发原则（8）敏捷过程提倡可持续开发。出资人、开发者和用户应该共同维持一个稳定的开发速度敏捷小组会在整个项目开发期间保持一个适当的、可持续的开发速度，从而维持最高的质量标准。敏捷项目不会使开发者感到疲惫不堪。敏捷开发原则（9）对卓越技术和良好设计的不断追求有助于提高敏捷性敏捷开发团队认为提高质量会加快开发进度。因此要保持软件的精简和健壮。敏捷开发团队的每个成员都致力于开发高质量的代码，不能把混乱的、低质量的代码留到以后去修改。敏捷开发原则（10）简单：尽量减少工作量的艺术是至关重要的敏捷开发方法总是选择达到目标的最

9、简单途径。敏捷开发团队并不花费大量精力去预防将来可能出现的问题，而是专注于对当前工作采用最简单、最高质量的解决方案，并相信将来如果问题出现，可以很方便地进行修改。敏捷开发原则（11）最好的架构、需求和设计都出自于自组织的团队敏捷开发团队是自组织的团队。职责并非是从团队外部加给每一个团队成员，而是团队作为一个整体接受职责并自己决定怎样去完成它。敏捷开发团队成员在项目的各个方面（架构、需求、测试等）都是共同负责的，不会出现某一人单独负责一方面任务的情况。敏捷开发原则（12）每隔一定时间，团队都要总结怎样更有效率地工作，然后相应地调整自己的行为敏捷开发团队认识到环境在不断地改变，因此团队也需要不断地

10、对组织、规则、惯例和各种关系进行调整，以保持自身的敏捷性。敏捷开发原则敏捷开发方法的代表瑞理统一开发过程（Rational Unified Process）极限编程（XP）、敏捷建模Agile Modeling 、迭代式增量软件开发 Scrum、水晶方法体系Crystal Methods、自适应软件开发Adaptive Software Development 敏捷开发方法极限编程XP总结目 录极限编程XP 极限编程XP（Extreme Programming）是最著名的敏捷开发方法，它由一系列简单的、互相依赖的最佳实践组成。 XP团队使用现场客户、特殊计划方法和持续测试来提供快速的反馈和全面

11、的交流。这可以帮助团队最大化地发挥他们的价值。极限编程XP 极限编程引入一系列优秀的软件开发方法，并将它们发挥到极致。 比如：为了能及时得到用户的反馈， XP 要求客户代表每天都必须与开发团队在一起。 XP 要求所有的编程都采用结对编程的方式。这种方式是传统的同行审查的一种极端表现，或者可以说是它的替代方式。核心思想沟通：问题往往是开发人员与设计人员，设计人员和客户之间沟通不畅导致的。团队成员之间通过日常沟通，简单设计，测试，系统隐喻以及代码本身来沟通产品需求和系统设计。团队成员不是通过文档来交流，文档不是必须的。反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户

12、的需要。核心思想简单：XP提倡简单的设计，简单的解决方案。应该尽量保持代码的简单，与其实现一个复杂的的系统，不如设计一个能够满足目前需要的、简单的系统，因为你所考虑的情况可能永远都不会发生。勇气：XP鼓励一些有较高风险的良好的做法。例如，它要求程序员尽可能频繁地重构代码，必须删除过时的代码，不解决技术难题就不罢休，等等。团队：XP 提倡团队合作，相互尊重。适用环境 XP弱化针对未来需求的设计，非常注重当前的简化 它的实践，有一个非常关键的假设就是：开发人员只注重眼前需求，依赖重构来适应需求的变动，这样所带来的风险、开销要小于需求变化使得事先充分设计失效的代价；反之，实施XP就是不明智的。适用范

13、围 XP适合规模小、进度紧、需求变化大、质量要求严的项目。 它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求，XP在平衡短期和长期利益之间做了巧妙的选择。不适用的领域中大型的项目（项目团队超过10人）；重构会导致大量开销的应用；需要很长的编译或者测试周期的系统；不容易进行测试的应用；团队人员异地分布的项目；不能接收XP文化的组织和团队；XP的活动编码作为一种轻量级方法论，XP明确放弃了系统建档和分析以外的任何外在活动分析保留为一种相当简单，但是在和客户的日常沟通中发生的持续活动文档则明确不予鼓励，所以编码成为XP最主要的活动XP的活动测试为了确保编写

14、好的代码能实践工作，XP提倡编写大量测试来检查代码是否正确倾听XP编程人员倾听客户和其他编程人员的需求和意图XP的活动设计从日常的编码中返回来进行一些一般性设计，小的设计成为XP编程人员日常事务的一部分核心实践1.现场客户（On-site Customer）2.计划游戏（Planning Game）3.系统隐喻（System Metaphor）4.简单设计（Simple Design）5.代码集体所有（Collective Code Ownership）6.结对编程（Pair Programming）核心实践7.测试驱动（Test-driven）8.小型发布（Small Releases）9.

15、重构（Refactoring）10.持续集成（Continuous integration）11.每周40小时工作制（40-hour Weeks）12.代码规范（Coding Standards）核心实践的层次结构过程团队实践编程现场客户、测试、计划游戏、小型发布简单设计、测试、重构、编码标准代码集体所有、持续集成、隐喻、编码标准、每周40小时工作制、结对编程、小型发布核心实践之间的互相支持客户也是开发团队成员On-site Customer客户作为开发团队的成员，与开发人员密切合作，共同解决存在的问题。始终在开发团队中有一位客户。现场客户的工作：回答问题编写验收测试运行验收测试指导迭代接受版

16、本计划游戏 XP项目计划的主导思想是将业务责任和开发责任相分离。业务人员（客户）确定哪些产品特征是重要的，开发人员确定实现这些特征需花费多少成本。在每个迭代或发布周期的开始，开发人员交给客户一个预算，说明在该迭代或发布周期中能够完成多少工作，客户根据这个预算选择需实现哪些产品功能。系统隐喻将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的 隐喻是一种概念框架并提供名称的描述系统，类似于其他方法中的体系结构（或体系结构基准），共识，共享的术语空间。简单设计团队保持设计恰好和当前的系统功能相匹配

17、。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 集体所有权代码归集体所有，团队中的所有成员都有权访问和改进项目的所有模块代码。没有一个人单独负责某一模块或技术。集体所有权可促进交流，增强团队凝聚力和发挥集体创造力。结对编程两个程序员用一台电脑一起工作，其中一人操作键盘，输入程序，另一人与他密切交流，检查错误和需要改进的地方。两人的角色频繁互换。所编写的代码由两人共同负责。每个程序员至少每天更换一次配对的对象，这样当一个迭代结束后，每个程序员都与小组中所有其它程序员配过对，工作涉及到本次迭代的所有内容。结对编程结对编程能够极大地促进知识在团队中的传

18、播，没有任何一个程序模块由单独一人完成，这样就保证了任何人的工作在必要时都可由其他人代替完成。经验证明，结对编程没有降低开发团队的效率，而且大幅度地减小了缺陷率。测试驱动开发先测试，再编码；代码未动，测试先行 XP： 强调“测试先行”。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。短交付周期 XP项目每两周向客户交付一次软件，所交付的软件涉及客户的一部分需求，客户要及时作出反馈。为了实现短交付周期，项目组需要制定迭代计划和发布计划。短交付周期两周为一个迭代周期，迭代代表向用户的一次产品交付，是用户所需功能的一个集合。六个迭代（约三个月时间）形成一个发布（Release），发布是一个主要的产品交付，会被集成到最终产品中。项目组必须为每次迭代和发布制定预算。用户根据预算来选择迭代和发布中所包含的功能。重构 重构是XP的一个重要组成部分。所谓重构是指在不改变代码外在行为的前提下对代码做出的修改，以改进代码的内部结构。 重构是一种有纪律的、经过训练的、有条不紊的代码整理方法，可以将整理过程中不小心引入错误的可能性降到最低。 重构的实质是在代码写好之后改进它的设计。持续集成 持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反