导语
常见的软件开发过程方法有：瀑布模型、迭代增量开发、敏捷开发等。本文对以上三种加以介绍，同时还会介绍这两年火热的DevOps。
1 - 传统瀑布模型
瀑布模型将软件生命周期划分成计划、需求、设计、实现、测试、运维六个阶段，并规定它们严格自上而下、相互衔接的固定次序，如同瀑布流水一样。由于前一阶段的输出将作为下一阶段的输入，所以瀑布模型要求每一个阶段都做到最好，尤其是项目前期设计。然而在每个项目中需求变更都是无法避免的，瀑布模型的严格分级导致其无法较好应对需求变更且代价高昂。此外瀑布模型十分强调文档的重要性，导致开发人员需要在文档上付出大量的时间和精力。
2 - 迭代增量开发
迭代增量开发弥补了瀑布模型严格分级、缺少阶段间反馈的缺点。在迭代增量开发中，项目被分割成一系列时间较短的迭代，同时整个工程被分成了不同的小部分，每一次迭代后都比上一次增加一些功能。这些小迭代中都会包括需求分析、设计、实现、测试。通过这种方法，开发可在需求被完整定义前启动，并在每次迭代完成后，通过用户反馈来细化进一步需求，并开始新一轮迭代。迭代增量开发是基于瀑布模型的，但它不要求每一次迭代出来完美的结果，而是先把主要功能构建出来，通过反馈不断完善。
迭代增量开发仍然是一种过程模型，只是从瀑布模型的线性关系转变成迭代关系，因此它仍然十分强调文档的重要性。
3 - 敏捷方法
上面两种方法都是传统的软件开发过程，对于大型团队开发大型项目，这种强调过程规范的方法论是有必要的，但对于较小的开发团队，敏捷开发会是一个更好的选择。
到这里还没解释什么是敏捷开发，因为我觉得了解敏捷开发最好的方法就是阅读敏捷宣言和敏捷软件的十二条原则，直接看敏捷宣言可能会有点无法理解，所以先看敏捷软件的十二条原则会是一个更好的选择。我个人的理解是：提出敏捷宣言的人对传统软件开发方法不满，提倡一种更轻便、更现代的方法。而他们的不满可以总结如下：
- 过于强调严格的工作流程、方法论，团队成员之间沟通不足
- 过于强调文档的重要性，与客户交互中往往给出臃肿的文档，而不是直观可用的软件。
- 客户参与不足，忽视客户协作的重要性，无论是需求还是反馈都应该让客户参与进来。
- 过于依赖计划，无法快速响应需求变化。
总结来说，敏捷开发就是：强调能够应对需求变更的开发能力，强调开发人员和业务人员之间的紧密协作，强调面对面的沟通（比书面的文档更有效），强调能够频繁交付新的软件版本的开发能力，并且更注重软件开发进程中人的作用而不是文档。
敏捷开发实践
- 结对编程
- 站会
- 任务板 Task board
常用的敏捷软件开发框架有 Scrum 和 XP
Scrum
