背景
历经瀑布开发模型、快速原型模型、螺旋开发模型的1995年前后，CMMI、IEEE、ISO等标准规范大行其道，但由于其重型化，使得软件开发依然变得困难，主要表现在：
- 需求总在变化，导致项目不断延期。
- 系统越来越复杂，Bug越来越多，质量越来越差。
- 文档要求规范繁重，维护难度极高，投入成本极大。
- 团队之间相互独立，部门隔阂严重。
- 互联网的高速发展更加强调软件交付的速度。
为了挣脱软件开发的重重枷锁，17位软件大咖在2001年齐聚美国犹他州的Snowbird，分享与探讨新型软件开发模型，内容包括极限编程(XP)、自适应编程(ASD)、特性驱动开发(FDD)、测试驱动开发(TDD)等轻量级的开发框架。
最后，他们为这次运动取名为“敏捷”，并发表“敏捷软件开发宣言”。
概述
敏捷，Agile，是一种思想，是一种理念，是以**用户需求进化**为核心，采用迭代、循序渐进的方式进行软件开发。
敏捷的目的是为了降低需求变化所带来的成本，其最大特点是响应变化。项目初期，软件会被切分成多个子项目，每个子项目周期内（1~4周）的活动称为迭代。每次迭代都会发布一个运行的软件，并且在整个迭代过程中，软件一直处于可用状态。
但敏捷并不是单纯的追求快，如果可以这样，何不通过加人来解决此类问题？敏捷更加关注人与人之间的沟通与交流，以人为核心，建立起全员参与的软件开发团队，使得团队互通有无。
开发流程
敏捷开发迭代流程一般遵循以下五个步骤：
- 需求分析（requirements analysis）
- 产品设计（design）
- 功能编码（coding）
- 功能测试（testing）
- 部署评估（deployment / evaluation）
该流程与传统的开发模型是极其相似的，也都遵循着PDCA的原则。
所以，敏捷与其他传统开发模型相比，最大的变化并不是流程的创新，而是思想的转变，是如何从文档驱动向用户需求驱动的转变，是如何从一成不变向拥抱变化的转变。
核心价值
- 个体和互动 高于 过程和工具。
- 工作的软件 高于 详尽的文档。
- 客户合作 高于 合同谈判。
- 响应变化 高于 遵循计划。
敏捷原则
- 通过早期和持续交付有价值的软件，实现客户满意度。
- 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
- 不断交付可用的软件，周期通常是几周，越短越好。
- 项目过程中，业务人员与开发人员必须在一起工作。
- 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
- 面对面交谈是最好的沟通方式。
- 可用性是衡量进度的主要指标。
- 提倡可持续的开发，保持稳定的进展速度。
- 不断关注技术是否优秀，设计是否良好。
- 简单性至关重要，尽最大可能减少不必要的工作。
- 最好的架构、要求和设计，来自团队内部自发的认识。
- 团队要定期反思如何更有效，并相应地进行调整。
敏捷测试
自动化
敏捷开发要求高效性，自动化测试在敏捷开发模式中占据着重要地位。与传统开发模式不同，传统开发模式允许测试人员有充足时间调研、开发、准备自动化测试，而敏捷模式恰恰处于要求高度自动化同时还要快速、急迫实现自动化。
这也是很多人在使用敏捷开发模式时所抱怨的“敏捷一点都不敏捷”。没有自动化，难以谈上敏捷。在敏捷开发模式下，自动化主要包括： （a）单元测试 （b）集成测试 （c）系统测试
测试设计
敏捷给测试带来更高的要求，需要快速响应测试需求，不断提升测试效率与质量，测试设计与分析的能力显得尤为重要。测试设计与分析主要从以下三方面切入： （a）测试设计方法：等价类、边界值、正交试验、状态迁移等。 （b）质量属性测试：性能、稳定性、本地化、易用性测试等。 （c）探索性测试：以用户为中心，在极短的时间内，不按照固有思维，对产品质量快速检测。
测试管理
传统开发模式会明确定义测试经理角色，但是在敏捷开发模式下并无提及。这是否说明敏捷下并不需要要测试经理？答案是肯定的，在敏捷模式下，测试经理是不需要的。
但是这并不代表不需要测试管理职能。就像敏捷并不会设立项目经理角色一样（通常该角色功能转移到产品负责人），“经理”这个职位应该被彻底抛弃。敏捷开发团队的成员都有义务参与到测试当中，测试管理活动应该由团队成员共同承担。
对于专职测试团队（负责人不叫测试经理），测试管理更多是体现在：
（a）敏捷测试计划与测试策略。
（b）产品缺陷的跟踪与管理。
（c）产品质量评估与风险分析。
敏捷分类
敏捷是众多优秀软件开发实践的集大成者，很多优秀实践与经验值得借鉴学习。为了避免概念混淆，可以作出适当分类：
总结
敏捷是一种思想，是一种理念，它并不束缚我们如何行事，而是定下准则给予指导，让我们能够跟快适应互联网发展趋势，让我们能够保持生命力，让我们持久发布交付对用户有价值的产品。
Q&A
-
敏捷对人的要求很高？
不管引入敏捷与否，软件开发的技能是必须的。敏捷是在原有的流程基础上，让团队从固有的思维跳出，向着用户需求交付看齐，适应产品的变化。同时，随着团队技能的不断提升，敏捷能够打开团队创新的思维，使得团队的效率会越来越高。
-
敏捷好，其他方法已经落伍。
敏捷是一种思想，与其他开发模式相比，更注重与人的沟通与交流，响应变化。但是这并不能作为评判事物好坏的标准。尤其在传统行业中，如航空制造、交易系统等，并不需要拥抱变化，需要按照既定的流程严格遵守。
-
敏捷就是XP、就是Scrum。
敏捷是一种思想，而XP和Scrum是在遵循敏捷思想的基础上发展出来的优秀实践。
-
持续集成、结对编程都是敏捷下的优秀实践？还能3个其他优秀实践吗？
正确。站立会议、重构、解耦、迭代、特性团队。
-
敏捷开发流程是一套全新的开发流程。
敏捷开发并不是流程上的创新，而是思想的转变。
-
敏捷团队下所有人都参与测试，所以不需要专职测试团队了。
敏捷团队所有成员都要参与测试，这是对团队的要求，也是对测试团队职责转变的要求。测试团队不再局限于测试执行当中，还要肩负起自动化测试、质量监控、测试指导的责任。
