这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记
团队一起开发开发一个项目需要确定采用什么开发模型，这样才能提高效率。
1.为什么需要流程
将一个想法变成一个产品需要进行开发。而开发的过程是需要流程的。超过一个人的团队就需要协作，随着团队规模上升，会出现全新的问题。
项目的开发往往不是一蹴而就的，需要一群人花费大量时间去开发，测试。产品上线后还需要运维迭代。由此可见，在一个产品从设计到开发再到运维上线的过程，需要经历时间长，人员多，功能需求多等问题。通过设计产品开发的流程，有利于将开发过程制度化，进而提高效率。
2.开发流程
2.1开发模型
开发模型有很多，目前经常使用的模型有瀑布模型、敏捷开发等。
瀑布模型：瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
敏捷开发：敏捷 开发是用于描述迭代软件开发的术语。 迭代软件开发通过以较小的增量（通常称为冲刺）对工作执行来缩短DevOps生命周期。 冲刺(sprint) 的时长通常为 1-4 周。 敏捷开发通常与传统开发或瀑布式开发相对照，后面两种开发模式会提前计划大型项目并根据该计划执行。
2.2开发流程
在开发的不同阶段有不同的目标，通常情况下，一个项目的开发流程有以下几个方面：
- 需求阶段：每个人都有自己的想法，团队决策需要有一个过程
- 开发阶段：多人/多端协作开发，每个人有自己的安排，相互配合需要有一个流程
- 测试阶段：产物怎样交付，测试如何开展，bug怎么修都需要流程
- 发布阶段：怎样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范
- 运维阶段：线上问题如何应急响应，处理用户反馈和线上问题需要有流程
2.2.1需求阶段
需求阶段至少包括两个部分：一是初始包需求（OR－Offered Requirement）确定阶段，这个阶段的参与人员会直接和市场、用服、客户沟通交流、调研，确定产品开发的初始需求；二是初始需求交给研发团队，系统工程师进一步分析，结合产品原有基础、收集内外部需求，得出产品要实现的包需求，并采用系统分析的工程方法开展对包需求的深入分析，得出更细化的需求描述，输出可以被实现的设计需求，交给软件实现人员
我们可以将需求根据重要程度和紧急程度分为四种：重要但不紧急、重要且紧急、不重要不紧急、紧急但不重要。
2.2.2开发阶段
开发阶段我们首先需要确定的是开发环境，根据项目环境和使用采用合适的架构模型。同时我们还要考虑团队成员应该怎么进行协作开发，修改之间有冲突怎么解决，出了问题的代码如何回退到之前的版本。在开发之前，还需要设计好产品开发的规格说明书，方案评审等内容。一个好的分布式代码托管平台就是一个不错的开发选择
2.2.3测试阶段
系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。而且越早发现缺陷修复的成本越低。
应根据开发各阶段的需求、设计等文档或程序的内部结构精心设计测试用例，并利用这些实例来运行程序，以便发现错误。信息系统测试应包括软件测试、硬件测试和网络测试。硬件测试、网络测试可以根据具体的性能指标来进行，此处所说的测试更多的是指软件测试。
更多时候，测试比开发更为重要，一个好的测试能够有效提高开发的效率。
2.2.4发布阶段
在项目发布之前需要做很多事情
1.确定发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态，及时处理异常
2.变更服务的相关RD
- 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
- 对于自己负责的改动，在小流量或者是预览环境进行功能验证
- 执行发布计划中的其他操作
3.安排值班同学
- 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
- 如果有变更引起的告警或者用户反馈，需要及时终止发布。
我们常采用的发布模式有蛮力发布、金丝雀发布、滚动发布、蓝绿发布、红黑发布等，根据自己的需求，可以选择合适的发布模式
2.2.5运维阶段
运维，本质上是对网络、服务器、服务的生命周期各个阶段的运营与维护，在成本、稳定性、效率上达成一致可接受的状态。
所以在运维阶段，需要我们构建系统监控体系，进行应急处理，对问题进行分析，比如说从业务问题上处理。在版本更新的时候也需要对版本进行测试，然后上线。
以上便是在这次课程中我关于项目开发过程中的笔记
