一、瀑布模型

瀑布模型是比较传统的一种开发模式。

优点：
1、阶段清晰。从计划到开发最后到上线运行，三个阶段非常清晰。
2、时间顺序。每个阶段顺序必须是从上到下，严格按照时间先后进行。
3、环环相扣。在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。
4、黑盒模式。每个阶段都有各自的角色和分工，各自只关心自己的任务。
比如需求阶段开发人员无需关注。

缺点：
1、需求隔离。由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
2、变更代价大。既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。
3、束缚创造性。由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。
4、周期漫长。整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。

二、敏捷开发

敏捷开发是更注重沟通，快速产出新版本，并且更适应需求变更的的适合小团体开发的方法。
敏捷开发中有敏捷宣言，可以更好地阐述敏捷开发的概念：
1、个体和互动高于流程和工具（敏捷开发的站会落实了这一点）
2、工作的软件高于详尽的文档（jira、miro等更好地代替厚重的需求文档）
3、客户合作高于合同谈判（公司内各部门甩锅情况，难道不应该用合作为公司创造价值吗）
4、响应变化高于遵循计划（快速响应时长需求，而不是错过市场变化）

Scrum中的角色定义
Product Owner（产品负责人，主要负责产品设计，需求筛选等）
Scrum Master（敏捷主管，主要负责项目迭代跟进等）
Scrum Team（敏捷团队，主要负责需求的研发测试部署等，包括Dev、Test、Ops等）

Scrum中把一个迭代叫做一个冲刺(Sprint)，这也是很多地方把计划会议叫做冲刺会的由来，一般一个Sprint为1~4周。核心流程包括4个会议：
1、计划会议
2、每日站会
3、评审会议
4、回顾会议

XP（极限编程，Extreme Programming），是敏捷开发中最具成效的几种方法之一，如同其他敏捷方法，它和传统方法的本质不同在于它更强调可适应性能性以及面临的困难。如图：
DevOps是一种开发、测试和运维之间文化沟通，通过自动化的方式来进行软件交付和架构变更的流程，使构建、测试、发布软件能更快捷、频繁、可靠。它的出现是因为软件逐渐的认识到，开发、测试和运维的紧密合作可以更好的交付软件产品和服务。

下图展示了自循环工作流的流程，其中前4项属于Dev范畴，后4项属于Ops范畴：
1、plan（计划）
2、code（编码）
3、build（构建）
4、test（测试）
5、release（发布）
6、deploy（部署）
7、operate（操作）
8、monitor（监控）