瀑布型开发模式
瀑布型开发，也就是传统开发模式。瀑布型模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布型开发模式
瀑布型开发模式具有以下不足：
- 需求分析占比很重，对客户想要的产品进行详细分析，明确指定产品结果。但是由于需求人员的考虑的方面可能有疏漏，客户的需求的变化，行情的变化等等因素存在，需求文档会不断变更，开发人员产生抵触心理。
- 开发人员按照需求文档严格开发，限制思维，参与不到需求的设计。
- 需求与客户沟通存在障碍，可能导致最终产物不是客户想要的。重新开始项目，很费事费力。
所谓的瀑布，很形象的表达了这一开发模式，就是留下去了，就回不去了。当然程序开发的时候可以重新开始，但是就相当于之前作废，重立项目。但是市场在变，科技在变，一切都在不断改变，拥抱变化才能更快的适应环境的变化。因此瀑布型开发模式逐渐被敏捷开发所取代。
敏捷开发模式
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发。
敏捷开发只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。而瀑布开发模型，它是以文档为驱动的。因为在瀑布型的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据。
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
Scrum是一种流行的敏捷开发流程构架，也可以说是一种套路。Scrum框架中包含三个角色，三个工件，四个会议，听起来很复杂，其目的是为了有效地完成每一次迭代周期的工作。
Scrum工作流程如下图所示。在学习Scrum工作流程之前，我们先要了解几个基本术语：
Sprint：冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
User Story：用户的外在业务需求。拿银行系统来举例的话，一个 Story 可以是用户的存款行为，或者是查询余额等等。也就是所谓的小目标本身。
Task：由 User Story 拆分成的具体开发任务。
Backlog：需求列表，可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
Daily meeting：每天的站会，用于监控项目进度。有些公司直接称其为 Scrum。
Sprint Review meeting: 冲刺评审会议，让团队成员们演示成果。
Sprint burn down：冲刺燃尽图，说白了就是记录当前周期的需求完成情况。
Release：开发周期完成，项目发布新的可用版本。
Scrum开发流程
如上图所示，在项目启动之前，会由团队的产品负责人（Product owner）按照需求优先级来明确出一份 Product Backlog，为项目做出整体排期。
随后在每一个小的迭代周期里，团队会根据计划（Sprint Plan Meeting）确定本周期的 Sprint Backlog，再细化成一个个 Task，分配给团队成员，进行具体开发工作。每一天，团队成员都会进行 Daily meeting，根据情况更新自己的 Task 状态，整个团队更新 Sprint burn down chart。
当这一周期的 Sprint backlog 全部完成，团队会进行 Spring review meeting，也就是评审会议。一切顺利的话，会发布出这一版本的 Release，并且进行 Sprint 回顾会议（Sprint Retrospective Meeting），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。
从上述工作流程可以看出，敏捷开发并没有将运维也纳入进来，有可能需求，开发，测试很快做出了很多版本，但是没有部署，或者部署很慢。也拖延产品的进程。这就需要开发，测试，运维的相互沟通。为了加快这些环节的沟通问题，devops观念产生。
DevOps开发模式
DevOps是Development与Operations的缩写。DevOps就是要打破开发与运维之间的隔阂，提高了各个团队的协作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。
DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。
DevOps能力图
下图是以Jira为源的DevOps工具链。整个DevOps流程包括：需求管理、持续集成&测试、配置&部署、监控&运营，各个环节的任务均有相应的工具来完成。
以Jira为源的DevOps工具链
下面给出了一个通用的逻辑流程，在这个流程中所有内容都将自动进行无缝交付。但是此流程也会因不同组织的不同需求而导致一些差异。
开发人员开发代码，源代码由Git等版本控制系统工具管理。
开发人员将此代码提交到Git，并且对代码所做的任何更改都将提交到此代码仓库。
Jenkins通过Git插件从仓库中提取此代码，并使用Ant或Mave 等工具构建它。
配置管理工具（如Puppet）部署和提供测试环境，然后Jenkins在使用Selenium等工具进行测试的测试环境上发布此代码。
代码测试结束后，Jenkins 就会将其发送到生产服务器上进行部署（甚至生产服务器也由 Puppet 等工具进行配置和维护）。
部署后，Nagios 等工具会进行持续监控。
Docker容器提供测试环境来测试构建功能。
DevOps和敏捷开发有以下区别：
DevOps和敏捷开发对比
总结
市场对软件行业的开发需求，促使其软件开发模式不断演进，从瀑布型开发模型发展到目前流行的DevOps开发模式，其核心在于通过自动化工具提高软件团队的沟通效率，改善软件功能可持续部署和交付的能力。软件行业开发模式的演变必定会给汽车行业制定软件开发模式带来启发。
参考文献
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！