我们一直说敏捷开发，敏捷开发到底是什么呢？需要我们怎么做呢？
刚接触敏捷开发的时候 真的是一脸迷茫，当然接触一门新的概念或者知识的时候 我们还是一如既往的，查资料，买书来学习。
通过各种资料的学习，敏捷开发也就是下面四句宣言：
敏捷开发的4句宣言：
1，个体与交互 胜过 过程与工具
2，可以工作的软件 胜过 面面俱到的文挡
3，客户协作 胜过 合同谈判
4，响应变化 胜过 遵循计划
什么是敏捷开发？
学习敏捷开发之前我们首先要了解一下，敏捷开发的概念.
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
上面说到 敏捷开发的概念，其中涉及到了两个 关键语句：
1，以人为核心
2，迭代。
以人为核心
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
迭代
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
敏捷开发的方式
上面说到敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发。
目前敏捷开发方式有两种：
1，Scrum,
2，XP
你可以采用Scrum方式也可以采用XP方式；
Scrum和XP有一定的区别：
Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。
敏捷开发的主要特点
与传统开发方法相比，在敏捷开发的整个过程中，有以下几个主要的特点：
（1）敏捷开发的过程有着更强的适应性而不是预设性，从敏捷宣言的第四条响应变化高于预设计划便可以看出来。
（2）敏捷开发的过程中，更加的注重人的因素。
（3）在敏捷开发的过程中，整个项目是测试驱动的而不是文档驱动的。
敏捷开发和传统开发的区别
优势
敏捷开发的高适应性，以人为本的特性，和轻量型的开发方法即以测试为驱动取代了以文档为驱动，这三个主要的特点，也就是敏捷开发相对与传统开发方式的主要有点。因为他更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
劣势
与传统开发方式相比，敏捷开发的最主要的劣势在于敏捷开发欢迎新的需求，而在每次新的需求产生时都可能引起整个系统的大幅度的修改。因为开发者在开发上一个版本的时候，完全没有考虑以后的优化将要如何进行。这样的开发方式实际的软件开发过程中，并不一定总是有效的。
而另一个方面，敏捷开发因为缺乏很多在敏捷开发中被认为“不重要”的文档，这样在一个大型项目比如一个操作系统开发的时候，由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。
我们可以看一下Scrum的流程图，更清楚的了解敏捷开发，
上面说到了 敏捷的概念，方式和流程图，我们需要按照上面流程使用敏捷开发呢？
1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
