敏捷开发（Aglie Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。
敏捷并不是一门具体的技术，而是一种理念或者说是一种思想，他可以指导我们更加高效的开发。
再有，敏捷开发都具有以下几点的共同特征，如：
迭代式开发增量交付开发团队和用户反馈推动产品开发持续集成开发团队自我管理等。最后，相比于传统研发模式，如：”瀑布“，敏捷开发是一种“现代”的开发模式。
以往的软件工程已瀑布开发模式居多，瀑布开发模式比较适用于传统企业，如开发周期以年计的大型软件系统项目，任何环节都是基于上一个环节的输出后，才能往下顺序进行。
随着互联网的兴起，信息变得透明，而且传播速度之快，导致市场变化加速，用户需求加速变化，如果用软件工程的开发模式，做出来的软件，没有面世就被淘汰了，毕竟是存在竞争的。
敏捷开发追求的是快速迭代，灵活应对变化，弱工具、弱流程的管理方式，注重实效快速响应市场需求。
在敏捷开发中，软件项目在构建初期就被切分成多个子项目，各个子项目的成果都可分别经过测试，验收通过后，具备可视、可用、可集成的特征。
简单来说，就是把一个很大的项目分为多个相互联系且可独立运行的小项目，然后按照优先级分别完成，在此过程中项目产品是一直处于可使用的状态。
我们一直说敏捷开发是一种指导思想或开发方式，但经过20多年的发展，具体的软件项目中敏捷开发有哪些呢？
Scrum，极限编程（XP）精益软件开发（Lean Software Development）动态系统开发方法（DSDM）特征驱动开发（Feature Driver Development）水晶开发（Crystal Clear）等等我所比较了解的是Scrum，极限编程（XP）。区别是scrum有一套标准的流程规范，xp注重实践。二者结合使用起来效果是最佳的。
通过身体力行和帮助他人来揭示更好的软件开发方式。 经由这项工作，形成了如下价值观： 个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应变化 重于 遵循计划 在每对比对中，后者并非全无价值，但我们更看重前者。
1.我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 2.欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。 3.要不断交付可用的软件，周期从几周到几个月不等，且越短越好 4.项目过程中，业务人员与开发人员必须在一起工作。 5.要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 6.无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 7.可用的软件是衡量进度的主要指标。 8.敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 9.对技术的精益求精以及对设计的不断完善将提升敏捷性。 10.要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 11.最佳的架构、需求和设计出自于自组织的团队。 12.团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
敏捷开发宣言比较抽象，但敏捷开发十二原则就非常具体，上面的十二条原则都是开发过程的经验总结。
1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。（backlog可以理解为需求或者要做的事情） 2、召开产品backlog计划会议，预估每个backlog的时间，确定哪些backlog是需要在第一个sprint中完成的，即sprint的backlog。（sprint可以理解为一个团队一起开发的一个任务集合） 3、把sprint的backlog写在纸条上贴在任务墙，让大家认领分配。（任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上，这样大家都可以看得到任务的状态 ） 4、举行每日站立会议，让大家在每日会议上总结昨天做的事情、遇到什么困难，今天开展什么任务。（每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内） 5、绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0 ，这个sprint就完成了） 6、sprint评审会议是在sprint完成时举行，要向客户演示自己完成的软件产品 。 7、最后是sprint总结会议，以轮流发言方式进行，每个人都要发言，总结上一次sprint中遇到的问题、改进和大家分享讨论。
