我们一般常用的为4种，分别是 “敏捷开发模式”、“迭代模式”、“瀑布模式”、“快速原型模式” 。目前几乎都在用前两种模式：
DevOps 发展融合运维可视化 2016年
DevOps和敏捷这两种方法的目的都是破坏信息孤岛。实际上，DevOps是敏捷的扩展，包括系统和操作，并专注于打破开发和运营团队之间的障碍。这构建了一种协作文化，可以帮助他们变得更敏捷，以响应市场需求。DevOps和敏捷的目标是消除孤岛。
DevOps，是开发（Development）和运维（Operations）的组合，代表一种文化、运动或实践，旨在促进软件交付和基础设施变更软件开发人员（Dev）和 IT 运维技术人员（Ops）之间的合作和沟通。它的目的是构建一种文化和环境使构建，测试，发布软件更加快捷，频繁和可靠。
开发和运营团队之间缺乏协作实际上违背了敏捷的目的 - 功能需求已得到解决，但功能和部署需求未得到解决。这导致DevOps的兴起 - 这是一种新的开发方法，它基于开发和测试团队，业务团队和运营之间的持续协作，以更快，更准时地创建业务解决方案。
虽然可以在没有DevOps的情况下执行敏捷，但我们认为不可能没有敏捷原则的DevOps。作为一种方法论，DevOps是关于更短的开发冲刺，更加注重测试，增加自动化。目标是通过使用持续集成和持续交付与部署，更快地将软件投入生产。
DevOps 中的一套成熟的运维系统包括什么？自动化测试批量配置基础组件监控，告警数据可视化协同合作一套成熟的运维系统，能够将应用、网络、计算、存储、虚拟化等资源的性能以及告警信息进行综合分析，通过简洁易懂的界面，直观呈现业务健康水平。当出现故障时，能够第一时间受到信息，从监控相关信息确定问题位置，缩小故障定位范围，确定问题是在计算、应用还是网络，进而明确问题职责，让相应的开发运维迅速处理问题，没有推脱责任之嫌。
可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。需要频繁交付的企业可能更需要对DevOps有一个大致的了解
敏捷开发模式 Agile-Development-Model 2001 年
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发的4个核心思想：
（1）强调面对面的沟通，人和人的相互交流胜于任何流程和工具
（2）把精力集中在可执行的程序上，可以运行的产品胜于编制综合性文档，强调了原型、模型、demo等的重要性
（3）团队合作和团队激励，合作胜于谈判，敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体，大家都是一条线上的蚂蚱
（4）超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速
敏捷软件开发要注意项目规模，规模增长，团队交流成本就上去了，因此敏捷软件开发暂时适合不是特别大的团队开发，比较适合一个组的团队使用。好处是通过早期发现和修复缺陷来提高开发的效率。但这种模式比较依赖用户的信息反馈，而且这种模式比较适用于小规模的软件开发公司，习惯于“瀑布法”的程序员，管理层和组织可能难以适应敏捷。
敏捷开发模式有许多不同的形式，包括：Scrum，Crystal，Extreme Programming（XP）和Feature-Driven Development（FDD）详见：https://zhidao.baidu.com/question/1387782203020441540.html
其中迭代的过程（迭代模型）
整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。且可以再每个迭代中应用瀑布模式
* 其他常用的开发模式，如瀑布模式 - Waterfall model
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模式将软件生命周期划分：为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。
优点：严格遵循预先计划的步骤顺序进行，一切按部就班比较严谨。
（1）为项目提供了按阶段分的检查点
（2）当完成一个阶段后，只需要去关注后续阶段
（3）可在迭代模型中应用瀑布模型
缺点：缺乏灵活性，太过线性理想化，不适合现代软件开发
（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
（4）各个软件生命周期衔接花费时间较长，团队人员交流成本大。
（5）瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的
* 其他常用的开发模式，如.快速原型模式 Rapid Prototype Model
快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。
* 其他常用的开发模式，如.螺旋模型 Spiral-Model
瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
网友评论