前言
迭代开发
敏捷开发的核心是迭代开发（iterative development）。敏捷一定是采用迭代开发的方式。那么什么是"迭代开发"呢？迭代的英文是 iterative，直译为"重复"，迭代开发其实就是"重复开发"。
对于大型软件项目，传统的开发方式是采用一个大周期(比如半年)进行开发，整个过程就是一次"大开发"；迭代开发的方式则不一样，它将开发过程拆分成多个小周期，即一次"大开发"变成多次"小开发"，每次小开发都是同样的流程，所以看上去就好像重复在做同样的步骤。
举例来说，SpaceX 公司想造一个大推力火箭，将人类送到火星。但是，它不是一开始就造大火箭，而是先造一个最简陋的小火箭 Falcon 1。结果，第一次发射就爆炸了，直到第四次发射，才成功进入轨道。然后，开发了中型火箭 Falcon 9，九年中发射了70次。最后，才开发 Falcon 重型火箭。如果 SpaceX 不采用迭代开发，它可能直到现在还无法上天。
迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本，然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤，不断改进产品，添加新功能。通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。
增量开发
迭代开发只是要求将开发分成多个迭代，并没有回答一个重要的问题：怎么划分迭代，哪个任务在这个迭代，哪个任务在下个迭代？这时，一般采用"增量开发"（incremental development）划分迭代。
所谓的"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。
举例来说，房地产公司开发一个10栋楼的小区。如果采用增量开发的模式，该公司第一个迭代就是交付一号楼，第二个迭代交付二号楼…每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基，第二个迭代建好每栋楼的骨架，第三个迭代架设屋顶…
增量开发加上迭代开发，才算是真正的敏捷开发。
敏捷开发的好处
早期交付
敏捷开发的第一个好处，就是早期交付，从而大大降低成本。
还是房地产公司为例，如果按照传统的"瀑布开发模式"，先挖10栋楼的地基、再盖骨架、然后架设屋顶，每个阶段都等到前一个阶段完成后开始，可能需要两年才能一次性交付10栋楼。也就是说，如果不考虑预售，该项目必须等到两年后才能回款。
敏捷开发是六个月后交付一号楼，后面每两个月交付一栋楼。因此，半年就能回款10%，后面每个月都会有现金流，资金压力就大大减轻了。
降低风险
敏捷开发的第二个好处是，及时了解市场需求，降低产品不适用的风险。
请想一想，哪一种情况损失比较小：10栋楼都造好以后，才发现卖不出去，还是造好第一栋楼，就发现卖不出去，从而改进或停建后面9栋楼？
对于软件项目来说，先有一个原型产品，了解市场的接受程度，往往是项目成功的关键。有一本书叫做《梦断代码》，副标题就是"20+个程序员，三年时间，4732个bug，100+万美元，最后失败的故事"，这就是没有采用敏捷开发的结果。相反的，Instagram 最初是一个地理位置打卡 App，后来发现用户不怎么在乎地理位置，更喜欢上传照片，就改做照片上传软件，结果成了独角兽。
由于敏捷开发可以不断试错，找出对业务最重要的功能，然后通过迭代，调整软件方向。相比传统方式，大大增加了产品成功的可能性。如果市场需求不确定，或者你对该领域不熟悉，那么敏捷开发几乎是唯一可行的应对方式。
如何进行每一次迭代
虽然敏捷开发将软件开发分成多个迭代，但是也要求，每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。
&emssp;具体来说，每次迭代都必须依次完成以下五个步骤。
- 需求分析（requirements analysis）
- 设计（design）
- 编码（coding）
- 测试（testing）
- 部署和评估（deployment / evaluation）
每个迭代大约持续2~6周。
敏捷开发的价值观
《敏捷软件开发宣言》里面提到四个价值观。
- 程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
- 软件能够运行，优于详尽的文档。
- 跟客户的密切协作，优于合同和谈判。
- 能够响应变化，优于遵循计划。
十二条原则
该宣言还提出十二条敏捷开发的原则。
- 通过早期和持续交付有价值的软件，实现客户满意度。
- 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
- 不断交付可用的软件，周期通常是几周，越短越好。
- 项目过程中，业务人员与开发人员必须在一起工作。
- 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
- 面对面交谈是最好的沟通方式。
- 可用性是衡量进度的主要指标。
- 提倡可持续的开发，保持稳定的进展速度。
- 不断关注技术是否优秀，设计是否良好。
- 简单性至关重要，尽最大可能减少不必要的工作。
- 最好的架构、要求和设计，来自团队内部自发的认识。
- 团队要定期反思如何更有效，并相应地进行调整。
