定义
一种以人为核心，迭代、增量的开发价值观。
路线
- Test-Driven Development 测试驱动开发
- Continuous Integration 持续集成
- Refactoring 重构
- Pair-Programming 结对编程
- Stand up 站立会议
- Frequent Releases 小版本发布
- Minimal Document 较少的文档
- Collaborative Focus 以合作为中心
- Customer Engaggement 现场客户
- Automated Testing 自动化测试
- Adaptive Testing 可调整计划
特征
- “适应性”而非“预见性”
- ”面向人“而非”面向过程“
价值观
- “个人与交互”重于“开发过程和工作”
- “可用的软件”重于“复杂的文档”
- “寻求客户的合作”重于“合同的谈判”
- “对于变化的响应”重于“始终遵循固定的计划”
12条原则
- 通过早期和持续交付有价值的软件，实现客户满意度。
- 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
- 不断交付可用的软件，周期通常是几周，越短越好。
- 项目过程中，业务人员与开发人员必须在一起工作
- 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
- 面对面交谈是最好的沟通方式。
- 可用性是衡量进度的主要指标。
- 提倡可持续的开发，保持稳定的进展速度。
- 不断关注技术是否优秀，设计是否良好。
- 简单性至关重要，尽最大可能减少不必要的工作。
- 最好的架构、要求和设计，来自团队内部自发的认识。
- 团队要定期反思如何更有效，并相应地进行调整。
优势
- 早期交付
互联网市场风向转变很快，需要及时快速的交付形式 - 降低风险
增量式开发，对需求范围不明确、变更较多的项目，可以很大程度拥抱变化，大大增加成功的可能性
最大程度体现80/20原则，每次优先交付那能产生80%效益的20%功能，单位成本最大化
成功项目的共性
- 至少每天把新代码合并到整个系统，并通过测试，对设计变更作出快速反应
- 开发团队具备运作多个产品的工作经验
- 很早就致力于构建和提供内聚的架构
误解
- 敏捷就是越快越好
应该是轻量级、高效 - 敏捷对人的要求很高
其实是一项创造性活动
解开对热嗯的束缚，鼓励创新
易于集思广益，总有人知道问题所在 - 敏捷没有文档不做设计
必要且有意义的文档要写
用户要一定要写
架构设计文档复杂要写，不复杂不写 - 敏捷好，其他方法不好
适用场景不同，如建筑行业里瀑布模型就可以运作的很好 - 敏捷就是XP（极限编程），就是Scrum
方法很多，都遵循「敏捷宣言」原则
任何方法都要进行本土地优化，才能更好解决特定环境的问题 - 敏捷很好，因此我要制定标准，所有项目都要遵循这个标准
项目背景、阶段不同，敏捷是动态的，而非静止不变的
主流方法
- 极限编程 ExtremeProgramming，俗称XP
- Scrum
- 水晶方法
- 动态系统开发方法，DSDM
- 精益开发，Lean
