敏捷开发思想

定义

一种以人为核心，迭代、增量的开发价值观。

路线

• Test-Driven Development 测试驱动开发
• Continuous Integration 持续集成
• Refactoring 重构
• Pair-Programming 结对编程
• Stand up 站立会议
• Frequent Releases 小版本发布
• Minimal Document 较少的文档
• Collaborative Focus 以合作为中心
• Customer Engaggement 现场客户
• Automated Testing 自动化测试
• Adaptive Testing 可调整计划

特征

• “适应性”而非“预见性”
• ”面向人“而非”面向过程“

价值观

• “个人与交互”重于“开发过程和工作”
• “可用的软件”重于“复杂的文档”
• “寻求客户的合作”重于“合同的谈判”
• “对于变化的响应”重于“始终遵循固定的计划”

12条原则

1. 通过早期和持续交付有价值的软件，实现客户满意度。
2. 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 不断交付可用的软件，周期通常是几周，越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作
5. 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
6. 面对面交谈是最好的沟通方式。
7. 可用性是衡量进度的主要指标。
8. 提倡可持续的开发，保持稳定的进展速度。
9. 不断关注技术是否优秀，设计是否良好。
10. 简单性至关重要，尽最大可能减少不必要的工作。
11. 最好的架构、要求和设计，来自团队内部自发的认识。
12. 团队要定期反思如何更有效，并相应地进行调整。

优势

• 早期交付
  互联网市场风向转变很快，需要及时快速的交付形式
• 降低风险
  增量式开发，对需求范围不明确、变更较多的项目，可以很大程度拥抱变化，大大增加成功的可能性
  最大程度体现80/20原则，每次优先交付那能产生80%效益的20%功能，单位成本最大化

成功项目的共性

• 至少每天把新代码合并到整个系统，并通过测试，对设计变更作出快速反应
• 开发团队具备运作多个产品的工作经验
• 很早就致力于构建和提供内聚的架构

误解

• 敏捷就是越快越好
  应该是轻量级、高效
• 敏捷对人的要求很高
  其实是一项创造性活动
  解开对热嗯的束缚，鼓励创新
  易于集思广益，总有人知道问题所在
• 敏捷没有文档不做设计
  必要且有意义的文档要写
  用户要一定要写
  架构设计文档复杂要写，不复杂不写
• 敏捷好，其他方法不好
  适用场景不同，如建筑行业里瀑布模型就可以运作的很好
• 敏捷就是XP（极限编程），就是Scrum
  方法很多，都遵循「敏捷宣言」原则
  任何方法都要进行本土地优化，才能更好解决特定环境的问题
• 敏捷很好，因此我要制定标准，所有项目都要遵循这个标准
  项目背景、阶段不同，敏捷是动态的，而非静止不变的

主流方法

• 极限编程 ExtremeProgramming，俗称XP
• Scrum
• 水晶方法
• 动态系统开发方法，DSDM
• 精益开发，Lean