20世纪80年代—90年代
软件复杂性进一步升级，需要更好更好的“可组合性”(Composability)、“可延展性”(Malleability)以及“可维护性”(Maintainability) 面向对象编程语言+设计模式第三次软件危机 2005年至今 软件的发展速度已经远超于硬件的发展，体现于需求复杂度、技术复杂度、团队协作 更好的工具、开发模式、与协作流程
由上可见，软件的快速发展直接促使了软件工程上的进步，新的工具、新的开发与设计模式，新的协作流程也随之而生。
开发模式的发展我工作多年经历了多家公司，所经历的有三种开发模式，瀑布、敏捷、DevOps。那么这三种主流的开发模式也对应着三个发展阶段：
瀑布开发模式瀑布开发模式是在第一次软件危机1970时Winston Royce博士提出来。其思想是把项目过程划分为主要的六个阶段：需求收集、需求分析、软件设计、程序编码、软件测试、运行维护。团队划分也通过岗位职责进行划分：产品团队、开发团队、测试团队、运维团队。到目前为止该开发模式仍然用到做项目制的开发团队。
那么其优点与劣势也很明显，优点是计划明确，职责清晰，按部就班的完成就好。缺点是周期容易拖得太长，不容易调整变更，每个人只为自己职责范围内的负责，跨部门沟通成本大（这就是为什么我在图里画了两堵墙的原因）。我自己呆过一个瀑布模式的团队，在项目立项后就会被项目经理调动资源成为团队，而开发人员只会在这一次批次负责编码与修改测试反馈的问题，基本上上线后的问题跟你无关（除非紧急严重的），其他的BUG也许是下一个批次的另外一个开发人员帮你填。
敏捷开发模式准确的说敏捷开发是一种价值观和原则的体现，2001年17位IT大佬想把瀑布发模式这种重量级的开发过程替换成一种更加轻量级，可惜大家都没有达成统一意见因此把各自都认同的观念整理出来成为敏捷宣言。
敏捷开发其实把产品、开发、测试三种岗位职责的人紧密的联系了起来，由原来长周期的大目标拆解成了一个个短周期的小目标。他之所以快，不是因为写代码快了，而是节省了很多不必要的前置条件与返工，同时小步快跑的交付也可以提高团队的士气，一个长周期项目那枯燥、乏味、痛苦的过程，谁试谁知道。
举个例子，大家都是为公司的同个产品努力，没有什么合同谈判可言，只要需求要求相互了解清楚并且可行就可以开干了。写详细设计文档的时间，还不如花时间多沟通下需求的核心点，想办法设计得更容易满足需求。短周期的交付后，产品与客户就可以及时的查看交付效果并相应的优化与调整。（快速响应并不代表随时随地接受变更响应，可以统一归到下一个迭代周期，我不赞同拍拍脑袋的变更，自己都没清楚的功能怎么说服客户使用？）
敏捷开发的最大好处之一就是短周期的持续交付，这样方式能在现阶段的互联网行业得到更快速的响应与市场的抢占，同时能很好的进行技术改进与试错。但是这种”野蛮的“方式会让开发团队与运维团队形成一条鸿沟，而鸿沟的形成主要原因是运维团队希望软件的运作是可靠的，所以他们对资源的变动、新技术的使用尤为的小心、谨慎。
我曾经呆过一个敏捷开发团队，生产出了问题运维团队会自行去修改配置，当然会越改越错了，而且一天发布次数多了，就会起争执。
DevOps