敏捷开发
1、敏捷的含义
敏捷开发是一种以人为核心、迭代、增量的开发方法。在敏捷开发中，把一个大项目分为多个相互联系，可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
上面提到3个关键词，下面做个阐述：
以人为核心：众所周知在瀑布开发模型中，会出现大量的文档，开发人员往往都是根据文档进行开发，一切以文档为依据；而敏捷开发倡导少写文档，注重人与人面对面的交流，用沟通解决项目问题，所以它强调以人为核心
迭代开发：是指把一个复杂且开发周期很长的大任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代；同时每一次迭代都可以生产或开发出一个可以交付的软件产品
增量开发：是指软件每个发布的版本，都会新增一个用户可以感知的完整功能。可以理解成，按照新增功能来划分迭代
2、如何敏捷？
上面阐述的敏捷更多的是一种理念，但要实现敏捷开发有哪些实现方式呢？常见方式有两种Scrum和XP，在讲解具体步骤前，先说说它们的区别。
网上随处可查的区别是：Scrum偏重于过程，XP则偏重于实践。简单解释一下这句话，Scrum是从管理上，流程上设计一些方法来定义敏捷。XP是从具体的细节和某一工作的实现方法上深度挖掘了敏捷思想。区别详细如下：
1. Scrum 和 XP 团队都在迭代的方式下工作，但Scrum的周期一般是从两周到一个月，XP的周期是一两周
2. Scrum 团队在一个sprint中是不接受任何任务变更的。而XP的团队在一个迭代中，如果新的用户故事跟原来的规模和大小差不多，可以用新的进行替换。
3. XP 团队会严格按照任务的优先级来工作。所有的任务都被客户划分了优先级，团队都被要求在该优先级下工作。但scrum团队的人员会自己决定他们以何种顺序来完成所有的任务。
4. Scrum并没有定义任何工程实践的方法，它只是提供了一个实践的框架给你。但XP，极限编程却会给你这样的一些东西。比如测试驱动开发， 自动化测试，结对编程，简单设计，重构等等。
下面我们分别来讲讲Scrum和XP
Scrum流程
Scrum步骤：
1、我们首先需要确定一个Product Backlog（按优先级排列的一个产品需求清单），这个是由产品经理负责的；
2、Scrum 团队根据Product Backlog清单，做工作量的预估和计划；
3、有了Product Backlog清单，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story（用户故事）作为本次迭代完成的目标，这个目标的时间周期是1-4周，然后把这个Story进行细化，形成一个Sprint Backlog；（PS：Sprint 表示一次迭代）
4、Sprint Backlog是由Scrum 团队去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、在Scrum 团队完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图，见下图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；可使用工具实现提交、更新、测试和发布；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次迭代完成，我们就要进行 Srpint Review Meeting（演示会议），也称为评审会议，每一个Scrum 团队的成员都要演示自己完成的软件产品；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
XP敏捷实践
XP即极限编程（Extreme Programming的缩写）。极限编程是一种强调团队工作的工作方式，它是多种敏捷方式的一种。与Scrum不同的是，Scrum是一种工作方式的框架，从组织到团队的设计，而XP关注的是具体的工程技术实践。XP旨在通过工程实践的合理搭配使用，使开发者们能够自信地响应客户需求。强调反馈环机制，客户与研发团队之间的反馈环，测试与开发的反馈环，具体代码实现跟单元测试之间的反馈环，结对之间的反馈环。极限编程认为在软件研发过程中，变化是无所不在的，人们不应回避变化，而应该适应变化，通过对反馈去适应变化。
XP工程实践：
1、小型发布（Small Release）
每一次发布的版本应该尽可能的小，当然前提条件是每个版本有足够的商业价值，值得发布。由于小型发布可以使得集成更频繁，客户获得的中间结果也越频繁，反馈也就越频繁，客户就能够实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去。以实现更高的客户满意度。
2、计划游戏/规划策略(The Planning Game)
计划游戏的主要思想就是先快速地制定一份概要的计划，然后随着项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。“客户负责业务决策，开发团队负责技术决策”是计划游戏获得成功的前提条件。也就是说，系统的范围、下一次迭代的发布时间、用户故事的优先级应该由客户决定；而每个用户故事所需的开发时间、不同技术的成本、如何组建团队、每个用户故事的风险，以及具体的开发顺序应该有开发团队决定。
3、现场客户(On-site Customer)
为了保证开发出来的结果与客户的预想接近，XP方法论认为最重要的需要将客户请到开发现场。因此，在项目中有客户在现场明确用户故事，并做出相应的业务决策，对于XP项目而言有着十分重要的意义。
4、简单设计(Simple Design)
这个实践看上去似乎很容易理解，但却又经常被误解，许多批评者就指责XP忽略设计是不正确的。其实，XP的简单设计实践并不是要忽略设计，而且认为设计不应该在编码之前一次性完成，因为那样只能建立在“情况不会发生变化”或者“我们可以预见所有的变化”之类的谎言的基础上的。
5、结对编程(Pair programming)
所有的软件都是由两个程序员、并排坐在一起在同一台机器上完成的。
6、测试驱动开发(Testing）
编写单元测试是一个验证行为，更是一个设计行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们将预先编写一个自动化测试脚本，然后再编码使之通过。
7、重构(Refractoring)
重构是一种对代码进行改进而不影响功能实现的方式，XP需要开发人员在闻到代码的坏味道时，有重构代码的勇气。重构的目的是降低变化引发的风险，使得代码更优雅。
8、持续集成(Continuous Integration)
持续集成的含义则是要求XP团队每天尽可能多次地做代码集成，每次都在确保系统运行的单元测试通过之后进行。这样，就可以及早地暴露、消除由于重构、集体代码所有制所引起的错误。一个人commit后，其它所有人都有责任进行代码集成工作。
9、代码集体所有权(Collective Code Ownership)
任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。
10、编码规范（Code Standards）
XP方法论认为拥有编码标准可以避免团队在一些与开发进度无关的细节问题上发生争论。
11、系统隐喻（System Metaphor）
它是系统的未来影像，将整个系统联系在一起的全局视图；它使得所有单独模块的所属位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
12、可持续的速度/每周40小时工作制（40-hour Week）
加班早已成为开发人员的家常便饭，也是管理者最常使用的一种策略，而XP方法论认为，加班最终会扼杀团队的积极性，最终导致项目失败。团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
