浅谈敏捷开发
浅谈敏捷开发
敏捷开发（agile development）是非常流行的软件开发方法。据统计，2018年90%的软件开发采用敏捷开发。
但是，到底什么是敏捷开发，能说清的人却不多。本文尝试用简洁易懂的语言，解释敏捷开发。
章节
- 什么是敏捷开发（What）
- 为什么使用敏捷开发 （Why）
- 如何使用敏捷开发 （How）
- 采用敏捷开发的产品开发效果
1.什么是敏捷开发（What）
1.1 迭代开发
敏捷开发的核心是迭代开发（iterative development）。敏捷一定是采用迭代开发的方式。
那么什么是"迭代开发"呢？迭代的英文是 iterative，直译为"重复"，迭代开发其实就是"重复开发"。
对于大型软件项目，传统的开发方式是采用一个大周期（比如一年）进行开发，整个过程就是一次"大开发"；迭代开发的方式则不一样，它将开发过程拆分成多个小周期，即一次"大开发"变成多次"小开发"，每次小开发都是同样的流程，所以看上去就好像重复在做同样的步骤。
**迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进。**开发者先快速发布一个有效但不完美的最简版本，然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤，不断改进产品，添加新功能。通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。
迭代开发只是要求将开发分成多个迭代，并没有回答一个重要的问题：怎么划分迭代，哪个任务在这个迭代，哪个任务在下个迭代？这时，一般采用"增量开发"（incremental development）划分迭代。
1.2 增量开发
所谓"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。
增量开发加上迭代开发，才算真正的敏捷开发。
1.3 敏捷开发是一种价值观与原则
敏捷开发是一种价值观与原则，指导我们更加高效的开发
1.4 敏捷开发以用户需求为核心
敏捷开发以用户需求为核心，采用迭代(时间周期)、增量(循序渐进，功能模块)
的方式开发软件，目的在于快速覆盖、响应市场需求
1.5 大项目划分为小项目
大项目划分为小项目，分别完成，独立运行，如微服务的开发过程，就是将系统独立进行开发。
1.6 敏捷开发特征
1.6.1 迭代式开发 （主体是时间周期）
项目按照时间周期进行迭代，比如A功能优先级比较高，则在第一个迭代周期
内优先开发A功能，并上线。第二个迭代周期开发B功能。
1.6.2 增量交付 （主体是功能模块）
瀑布式开发模型：需求评审、概要设计、详细设计、开发、单元测试、
集成测试、上线。如微软的Vista系统，从1997年立项到2005年才问世，但是用
户反馈并不好，Vista操作系统的开发就是采用瀑布模型。
增量式开发:则代表产品是在每个周期结束时被逐步交付使用的。如微软在吸取Vista操作系统采用传统的瀑布式开发流程之后，发现操作系统并不能完全覆盖用户的需求。在2005-2007两年时间内 通过内部推行的敏捷开发原则，上线了win7，获得市场的一致好评。
1.6.3 开发团队和用户反馈推动产品开发
敏捷开发提倡用户参与到产品或项目开发的整个流程当中，通过用户反馈使得
产品更加符合用户频繁变动的需求。
1.6.4 持续集成
采用敏捷开发的产品在产品初期会上线基本功能，之后的功能是根据收集到的
用户反馈进行开发的，实现功能模块的持续集成。
1.6.5 开发团队自我管理
传统的开发模式，注重文档约束，而敏捷开发原则的推行原则要求团队内部交
流便利、文化相对开发，除去必要的文档约束，如Api接口文档，最注重的是团
队成员的高效交流，以此来提高产品、项目的开发效率、开发质量。
1.7 敏捷开发原则
1.7.1 快速迭代
小版本更新发布，更快覆盖当前 市场、用户 需求。
1.7.2 需求评审
需求评审阶段，要求PM、所有相关开发人员参与到需求评审当中
需求评审阶段：
需求可行性分析、
确定需求功能范围、
PM对需求中存在异议的细节进行解释。
1.7.3 编写story、验收标准
PM 编写story、验收标准
1.7.4 多沟通
PM、开发人员之间需要多沟通、减少不必要的文档。
1.7.5 做好原型
需求评审完毕后，PM与UE UI 人员进行紧密沟通，完成指导开发人员开发的UE、UI
1.7.6 及早考虑测试
测试人员在这个阶段需要根据需求中划分的功能点，设计测试用例。
2.为什么使用敏捷开发（Why）
2.1 覆盖快速变化的市场、用户需求，快速响应变化需求
在用户需求不断变化的情况下能够保证软件开发质量，把大的时间点变成小的
时间点。
2.2 把团队中职责定义清楚，发挥最大效率
2.3 早期交付
就是早期交付，从而大大降低成本。
还是以上一节的房产公司为例，如果按照传统的"瀑布开发模式"，先挖10栋楼的地基、再盖骨架、然后架设屋顶，每个阶段都等到前一个阶段完成后开始，可能需要两年才能一次性交付10栋楼。也就是说，如果不考虑预售，该项目必须等到两年后才能回款。
敏捷开发是六个月后交付一号楼，后面每两个月交付一栋楼。因此，半年就能回款10%，后面每个月都会有现金流，资金压力就大大减轻了。
2.4 降低风险
及时了解市场需求，降低产品不适用的风险。
请想一想，哪一种情况损失比较小：10栋楼都造好以后，才发现卖不出去，还是造好第一栋楼，就发现卖不出去，从而改进或停建后面9栋楼？
对于软件项目来说，先有一个原型产品，了解市场的接受程度，往往是项目成功的关键。有一本书叫做《梦断代码》，副标题就是"20+个程序员，三年时间，4732个bug，100+万美元，最后失败的故事"，这就是没有采用敏捷开发的结果。相反的，Instagram 最初是一个地理位置打卡 App，后来发现用户不怎么在乎地理位置，更喜欢上传照片，就改做照片上传软件，结果成了独角兽。
由于敏捷开发可以不断试错，找出对业务最重要的功能，然后通过迭代，调整软件方向。相比传统方式，大大增加了产品成功的可能性。如果市场需求不确定，或者你对该领域不熟悉，那么敏捷开发几乎是唯一可行的应对方式。
3.如何推行敏捷开发 (How)
上图为本人所在部门采用的敏捷开发原则，功能迭代时间大致为两周一个版本。
4.采用敏捷开发的产品开发效果
虽然敏捷开发将软件开发分成多个迭代，但是也要求，每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。
敏捷开发大大提高了我们部门的开发效率，开发人员各自关注自己负责的功能模块，并且通过高效的沟通，在保证产品质量的前提下，实现了产品的快速迭代。
具体来说，每次迭代都必须依次完成以下五个步骤。
- 需求分析（requirements analysis）
- 设计（design）
- 编码（coding）
- 测试（testing）
- 部署和评估（deployment / evaluation）
每个迭代大约持续2~6周。
5. 敏捷开发的价值观
《敏捷软件开发宣言》里面提到四个价值观。
- 程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
- 软件能够运行，优于详尽的文档。
- 跟客户的密切协作，优于合同和谈判。
- 能够响应变化，优于遵循计划。
6. 十二条原则
该宣言还提出十二条敏捷开发的原则。
- 通过早期和持续交付有价值的软件，实现客户满意度。
- 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
- 不断交付可用的软件，周期通常是几周，越短越好。
- 项目过程中，业务人员与开发人员必须在一起工作。
- 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
- 面对面交谈是最好的沟通方式。
- 可用性是衡量进度的主要指标。
- 提倡可持续的开发，保持稳定的进展速度。
- 不断关注技术是否优秀，设计是否良好。
- 简单性至关重要，尽最大可能减少不必要的工作。
- 最好的架构、要求和设计，来自团队内部自发的认识。
- 团队要定期反思如何更有效，并相应地进行调整。