第十三章敏捷软件开发与极限编程.pptVIP

第十三章 敏捷软件开发与极限编程 13.1 敏捷软件开发概述 13.2 敏捷方法与规范化方法的关系 13.3 极限编程实践案例 一些经验丰富的软件设计师在应对快速交付、需求易变的开发要求实践中分别总结出自己独特且有效的软件开发方法，被业界概括为敏捷软件开发方法。其中以“极限编程”最为流行。 13.1 敏捷软件开发概述 敏捷软件开发方法其实不是一个具体的过程， 而是一个涵盖性术语。用于概括那些应需而生的 具有类似价值观的软件开发方式和方法，这些方 法一般都具有以人为核心、循环迭代、响应变化 等特点，着眼于能高质量地快速交付客户满意的 工作软件。 代表性的敏捷开发方法 极限编程(eXtreme Programming，简称XP) 特征驱动软件开发（Feature Driven Development，简称FDD） 动态系统开发（Dynamic Systems Development Methodology，简称DSDM) 自适应软件开发(Adaptive Software Development，简称ASD) SCRUM Crystal “敏捷联盟”的价值观 个体与交互重于过程与工具 可以工作的软件重于面面俱到的文档 与客户的合作重于与其合同的谈判 对变化的响应重于对计划的遵循 敏捷软件开发的原则 敏捷开发而言，最重要的是通过尽早和不断交付有价值的软件来满足客户的需求。 敏捷开发欢迎需求的变化，即使是开发后期。敏捷过程能够驾驭变化并以此为客户创造竞争优势。 经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。 业务人员和开发人员应该在整个项目过程中始终朝夕在一起工作。 围绕斗志高昂的人进行软件开发，给他们提供适宜的环境，满足他们的需要，并相信他们能够完成任务。 敏捷软件开发的原则 在团队中，最有效率也最有效果的信息表达方式是面对面的交谈。 可以工作的软件是进度的主要度量标准。 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该总是维持不变的节奏。 对优秀的技能与好的设计的不断追求将有助于提高敏捷能力。 简单——尽可能减少工作量的艺术是至关重要的。 最好的架构、需求和设计都源自自组织的团队。 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。 典型敏捷方法：极限编程(XP) XP方法的基础是4个价值观念： 沟通。大多数项目的失败源于沟通不畅，所以要进行一些能够推动积极沟通的实践。 简单。开发能够满足客户需要的最简单的产品。 反馈。开发者必须要获取并且重视来自客户、系统的反馈以及相互之间的反馈。 勇气。准备好做出支持其他原则和实践的艰难决定。 典型敏捷方法：极限编程(XP) XP在4个价值观之上，又定义了12个的必须遵循的实践： 1. 完整团队：XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。 2. 计划游戏：计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。 3. 客户测试：作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。 典型敏捷方法：极限编程(XP) 4. 简单设计：团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 5. 结对编程：所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。 6. 测试驱动开发：编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。 典型敏捷方法：极限编程(XP) 7. 改进设计：随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。 8. 持续集成：团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。 9. 集体代码所有权：任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。 典型敏捷方法：极限编程(XP) 10. 编码标准：系统中所有的代码看起来就好像是一人单独编写的。 11. 隐喻：将整个系统联系在一起的全局视图的概念。它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。 12. 可持续的速度：团