传统软件开发模式一般采用的是瀑布开发模式，这种模式的特点是，下一个阶段的输入是上一个阶段的输出。在这个模式中，软件开发任何一个阶段的错误，都会严重影响到下一个阶段的进行，返工成本很大，而且这种错误发现的越晚，修复成本越大。
为了避免这种开发模式中的极大的错误返工成本，近几年流行起来了敏捷开发模式，也诞生了不少的敏捷开发教练。有关敏捷开发的概念，大家可以在网上搜索。这种模式下，我们考虑的是整个开发过程，从需求到上线这个过程的串行化，任何一个阶段的修改，直接回归、验证上线即可。
那么接下来我们考虑下，敏捷开发模式下的软件开发阶段。
需求分析
需求评审
详细设计
编码
测试
预上线
上线
一般有这7个阶段，当然，依据项目的不同特点，也有可能和这7个阶段有些细微的差异。接下来考虑下，在这7个阶段中，我们能够做些什么以及这些阶段在敏捷开发过程中，如果提高效率。
在需求分析中，这个阶段在传统的软件开发过程中，一般会占用软件开发流程40%以上的时间。在敏捷开发过程中，这个时间会被缩短，我们在确定需求的同时，会默认需求在后期会有变更。真实的开发过程也往往都这样，需求变更是一种常态。当然，需求变更在敏捷开发过程中，返工成本远远比传统开发模式的返工成本要小。这个阶段的产出一般是由PM进过市场调研最后确定的。
当需求分析完成后，会组织开发小组的PM、RD、QA、OP、EE、FE（如果有的话）各种角色一起进行需求kick off，如果对需求有异议，在这个时候进行讨论变更，最终生成一个当前最新的需求文档。当然，如果后期有需求变更，这个kick off会议还会被重新组织。
进入详细设计阶段，项目组的RD会进行详细设计，同时QA辅助进行review，最终产出详细设计文档。
在编码阶段，RD会按照详细设计文档，也就是MRD，来对应开发。在敏捷开发过程中，一般都会强调主干开发，频繁地、阶段性地进行代码提交。
测试阶段和编码阶段也不是严格隔开的两个独立的阶段。在编码阶段，阶段性的代码ci都会触发测试阶段。测试包括ut（ut一般由rd来保证），功能测试、异常测试、性能测试等。在敏捷开发中，这些阶段都会被串行自动触发，在代码提交的时候，都会自动触发各个阶段的回归任务；通过后，会补充功能测试case和异常测试测试case，大的功能升级的时候，还会对比性能测试结果，得出性能测试报告。
测试通过后，会上pre online环境，在preonline环境中，一般会引入线上的流量进行功能验证，保证pre online环境的正确性。
当pre online环境中功能验证通过后，会进行上线操作。一般会填写上线单，上线单中会包括上线的版本，包括代码产出的版本，配置的版本和数据的版本。同时包括出现线上问题是的回滚方案。
各个阶段都会采用自动化方式来进行，这些阶段都会有对应的自动化工具帮忙实现，保留记录需求的需求卡片（百度内部使用的是icafe工具），代码库的维护工具svn、git等，记录bug的bug卡片，预上线、上线的系统工具，以及辅助这些阶段进行串行起来的工具jenkins。针对这些阶段的集成串行执行等，百度内部会有agile工具。
当这些阶段串行起来后，任何一个阶段的变更自动触发后续阶段的回归和新功能的验证、自动化。当改动很小的时候，比如修复一个简单的bug，知道线上问题的解决，将会非常快速就可以完成。这些都考持续集成或者说持续交付来保证。
后面我们将会讨论，什么才是优秀的持续集成方案。