敏捷开发

敏捷开发是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种能应对快速变化需求的软件开发能力。敏捷开发以人为核心、以迭代方式循序渐进开发，在这一过程中，软件项目的构建被分成多个子项目，各个子项目之间的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可用状态

敏捷开发的价值观

2001年年初，在美国犹他州雪鸟滑雪胜地，敏捷方法发起者和实践者发起组成了敏捷联盟的聚会，并共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述：

（1）人机交互重于过程和工具
（2）可以工作的软件重于求全责备的文档
（3）客户协作重于合同谈判
（4）随时应对变化重于循规蹈矩

敏捷开发价值观认为，后者的内容虽然也有其价值，但前者的内容最为重要

敏捷开发的十二条原则

（1）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
（2）欣然面对需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。
（3）经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
（4）业务人员和开发人员必须相互合作，项目中的每一天都不例外。
（5）激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。
（6）不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
（7）可工作的软件是进度的首要度量标准。
（8）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
（9）对技术精益求精，对设计不断完善，将提高敏捷能力。
（10）以简洁为本，极力减少不必要工作量。
（11）最好的架构、需求和设计出自于自组织的团队。
（12）团队定期地反思如何能提高成效，并依此调整团队的行为

极限编程

极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的，是一种软件工程方法学，是敏捷软件开发中可能是最富有成效的几种方法学之一。

极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

极限编程的目标

极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更（而这样的需求变更在一些发展极快的领域中是不可避免的）将导致开发成本急速增加。

极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。

极限编程的四个核心价值观

（1）沟通
构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。
（2）简单
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。
（3）反馈
在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
① 来自系统的反馈：通过编写单元测试，程序员能直观的得到修改后系统的状态。
② 来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。
③ 来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户 [1]  。
反馈是与“交流”、“简单”这两条价值紧密联系的。为了弥补沟通的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性测试。
（4）勇气
极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。

开发过程

工作环境

（1）每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务
（2）所有的人都在同一个开放的开发环境中工作，还有茶点供应
（3）每周40小时，不提倡加班
（4）每天早晨，所有人一起站着开个短会
（5）提供用于讨论问题的时候可以在上面写写画画的大白板

需求

（1）客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一直起着很重要的作用。开发人员和客户一起，把各种需求变成一个个小的用户故事
（2）客户根据每个模块的商业价值来指定它们的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；
（3）客户为每个需求模块指定验收测试（功能测试）

设计

（1）从具体开发的角度来看，XP内层的过程是一个个基于测试驱动开发周期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的
（2）随着一个个小的需求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。
（3）XP提倡简单设计，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式，因为这种设计中有很多内容是你现在或最近都根本不需要的
（4）XP还大力提倡设计走查、代码走查以及重构，所有的这些过程其实也是优化设计的过程。在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需求

编程

（1）XP就提倡结对编程
（2）代码所有权是归于整个开发队伍的，任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试
（3）程序员在写程序和重构程序的时候，都要严格遵守编程规范

测试

（1）XP提倡在开始写程序之前先写单元测试
（2）开发人员应该经常把开发好的模块整合到一起，每次整合后都要运行单元测试
（3）做任何的代码走查和修改，都要运行单元测试
（4）发现了BUG，就要增加相应的测试
（5）除了单元测试之外，还有集成测试，功能测试、压力测试和系统测试等
（6）所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一

十二个核心实践

（1）完整团队
XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。
（2）计划对策
XP方法中需要制定两个计划：发布计划和迭代计划。计划是根据业务的优先级和技术评估结果来制定的，早期需要制定的计划往往是不准确的，需要在迭代过程中不断修正
（3）测试
XP方法提倡测试优先，先写测试后写代码，测试优先是为了在编码前使开发人员对代码进行周密思考，使开发人员尽快地检验他们想法的可行性
（4）简单设计
简单设计是指设计刚好满足当前定义的功能即可。它通过所有的测试，没有重复逻辑，表达出了开发者想表达的所有东西，并且包含尽可能少的代码。
（5）结对编程
两个程序员并排坐在一起在同一台机器上编程。一个程序员在开发的同时，另一个程序员负责检查程序的正确性和可读性
（6）小软件版本
经常、不断地发布可运行的，具有商业价值的小软件版本，供现场用户评估和最终使用
（7）改进设计
随时对程序结构进行持续不断的梳理，在不影响程序外部可见行为的情况下，对程序内部结构进行改进，保持代码简洁、无冗余。
（8）持续集成
每完成一个模块的开发后，立即将其组装到系统中，并进行集成测试。持续集成能保证项目组中所有开发好的模块始终是组装完毕、完成集成测试且是可执行的
（9）集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。
（10）编码标准
XP方法强调制定一个统一的编码标准，使系统中所有的代码看起来就好像是被单独一人编写的。
（11）隐喻
将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
（12）可持续的速度
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。

敏捷软件开发与极限编程相关推荐

敏捷软件开发之何为敏捷开发
敏捷开发,Agile Development,就是指能够在需求迅速变化的情况下快速开发软件.我们接触最多敏捷实践方式有:极限编程(XP).结对编程.测试驱动开发(TDD)等. 追究敏捷的历史,就必须要 ...
敏捷软件开发(Agile Software Development)简介之：什么是敏捷软件开发？
http://www.ruby-lang.org.cn/read--tid-604.html 敏捷软件开发(Agile Software Development)简介之:什么是敏捷软件开发? 本文部分 ...
软件工程---3.敏捷软件开发
敏捷软件开发极限编程(XP, Beck1999) Scrum方法(Schwaber and Beedle 2001) DSDM方法(Stapleton 2003) 敏捷软件的开发宣言个体和交互胜过 ...
敏捷软件开发scrum介绍
敏捷软件开发最近几年越来越火.跟传统软件开发相比有什么优点呢.今天我们就来聊一聊. 首先我们来看下什么叫做敏捷. 敏捷软件开发过程软件开发过程是指设计软件开发过程中涉及的一系列活动,指导开发组一步一 ...
读《Scrum敏捷软件开发》笔记
读<Scrum敏捷软件开发>笔记目录读<Scrum敏捷软件开发>笔记第I部分启动第II部分个体第iii部分团队第四部分组织第四部门下一站第I部分启动 ...
《软件工程》第3章敏捷软件开发
敏捷方法都具有以下共同的特性 1.规格说明.设计和实现过程交织在一起: 2.系统按照一系列增量进行开发: 3.使用广泛的工具来支持开发过程. §3.1敏捷方法敏捷方法的原则原则描述客户参与客 ...
《敏捷软件开发(原则模式与实践)》读书笔记
<敏捷软件开发>读书分享由于书是由英文书籍翻译,读起来会难免拗口,本次分享是由<敏捷软件开发>结合网上相关资料总结而成. 传统的瀑布式开发瀑布模型式是最典型的预见性的方法, ...
敏捷软件开发与传统软件工程的比较
敏捷软件开发与传统软件工程的比较软件工程的开发过程中有两种不同的管理和开发体系,一种是基于"瀑布模型"的预设性传统软件工程,另一种是轻量级的适应性敏捷软件 ...
精益与敏捷软件开发概述
广义而言,精益与敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发.Scrum.XP和看板则是将这些原则运用到实践中的三种具体方法.换句话说,它们是精益和敏捷软件开发里轻度重叠的三 ...
敏捷软件开发及devops思想
敏捷软件开发及devops思想敏捷软件开发在目前新形势下,企业面对多重挑战:第一交付频率高,研发周期短,小特性一天交付一次,版本两周交付一次.第二跨地域合作多,部署发布复杂,跨地域沟通协作多.效率 ...

敏捷软件开发与极限编程