项目研发交付规范

​ 贴近业务属性、兼顾研发各阶段要点的研发规范，可以切实提高研发效率、保障项目研发工作有条不紊地运作、顺利交付。而不完善的研发流程，会降低研发效率，增加成本与风险。

​ 本规范文档作为我司项目交付规范化的研发流程指导方法，目的是简化、规范日常工作流程，提高工作效率，减少无效与冗余工作，赋能企业、客户更强大的掌控力来应对海量增长的业务需求，从而释放更多人力专注于业务创新。

1. 术语定义

• 客户方

  另称 甲方 ，项目的业主方 / 业务方 / 需求方

• 开发方

  另称 乙方 ，项目的执行方 / 研发方 / 实施方，负责项目需求的开发/实施

• 合作方

  另称 对端，项目的其它合作单位 / 团队 / 共研方

2. 阶段规划

鉴于对日常项目研发工作的总结与归纳，结合我司项目情况将项目研发交付流程抽象为如下四个阶段：

• 需求阶段

• 设计阶段

• 开发阶段

• 发布阶段

3. 整体流程

3.1 需求阶段

关于需求类型，结合业务情况划分为两类：首次需求 与 迭代需求

• 首次需求

  客户方 首次提出的需求/功能点，主要是新增加的业务、功能、数据支撑等场景

• 迭代需求

  对于前期已经存在的功能进行变更或优化、遗留缺陷、发现的BUG，客户方 再次提出的需求，均属于迭代需求

3.1.1 需求分析

​ 由 客户方 与 开发方 充分沟通，力求获取并理解业务场景（背景）、目标，由双方就需求内容展开讨论，开发方 评估 需求合理性 、数据可行性 、技术可行性 ，并根据需求内容实际情况，由 客户方 输出《XX需求文档》

3.1.2 需求确认

​ 针对需求内容如果多方有异议，则反复讨论沟通，必须共同达成一致性解决方案。如果无异议，则产品需求文档定稿. 由 开发方 向 客户方 完成 最终版本需求 确认后，则本次需求进行 定档，开发方 则按照定档后的内容进入设计、开发，由 客户方 输出最终版本《XX需求文档》

需求一旦定档后，原则上不再接受大的需求调整，如有调整，对于已进入开发阶段的需求则建议中止开发，重新进行评估。

3.2 设计阶段

3.2.1 方案设计

​ 在开发方的 需求/项目负责人 与 客户方 完成需求确认，并收到最终《XX需求文档》 后。由开发方根据 需求文档内容 进行方案设计，视需求实际情况 向 客户方 反馈本次需求设计方案（工作群记录或邮件）

3.2.2 研发排期

​ 由 开发方 评估给出研发排期

3.2.3 工时确认

​ 由 开发方 向客户提交 《XX工时评估文档》，等待 客户方 确认

3.3 开发阶段

​ 在工时确认完成后需求即进入开发阶段，开发阶段的主要任务是将设计阶段的产出转化为具体代码。开发过程中，开发人员必须保证代码的规范性、准确性。同时进行适当的开发自测，以便后续联调工作可以顺利开展。

3.3.1 文档编制

​ 对于涉及需要对外提供接口的需求，由 开发方 进行《XX接口文档》的编制，向客户方、合作方进行输出；在文档编制过程中遇到需求不清晰、有疑问等问题，开发方 及时向 客户方 确认

3.3.2 代码开发

​ 开发人员根据 已定档的需求内容 进行开发，开发过程中如发现有疑问及时反馈 客户方 进行确认。代码开发完成后由开发人员进行自测后，部署至测试环境进行 内部测试与 联调

3.3.3 开发自测

测试环境部署

​ 开发方的开发人员在需求自测完成后，部署至测试环境

内部测试

​ 测试环境部署完成后，由 开发方 测试人员按照测试用例进行内部测试，测试过程中出现的BUG、问题反馈给开发人员进行修复

3.3.4 测试联调

开发联调

​ 涉及 合作方 参与或 需求评估可能影响 合作方 的，与 合作方 进行联调，并及时处理调试过程中产生的问题

测试文档编制

​ 完成测试与联调后，开发方 进行代码评估，出具《XX测试文档》，文档中说明需求测试用例、开发联调情况(可选)、遗留问题评估(可选)、预期风险、发布后合作方与对端配合情况(可选)，以及是否发布的结论或建议

3.4 发布阶段

发布是将具备发布条件的程序发布到线上系统，并以生产标准进行数据产出的过程。

发布分为正常发布和紧急发布：

• 正常发布：发布节奏在原则上是可预见性、周期性的，发布计划可提前制定和公布。正常列入排期计划的需求，都必须按照正常的节奏安排发布计划。

• 紧急发布：紧急发布是为应对突发性、紧急性状况而额外开启的可选发布，如线上BUG紧急修复、突发性需求等。

  在接到紧急发布需求后，第一时间应评估是否可以随最近一次正常发布窗口期发布。如果不可以，则根据实际情况发起紧急发布申请。

3.4.1 生产发布

发布申请

​ 在需求完成测试验证通过后，由 开发方 向 客户方 发起发布申请，与 客户方 确定好 上线时间 ；对于涉及需要 合作方 配合验证的情况，由 客户方 协调 合作方 , 并约定好 上线时间， 未协调好合作方验证的情况下 开发方 将延期上线。

执行部署

​ 在与 客户方 确定的上线时间点，由 开发方 按照上线步骤执行部署，部署完成后进行冒烟测试。冒烟测试完成后，如本次上线有数据、附加配置的处理，则进行同步处理。

​ 如冒烟测试未通过，则不满足交付条件，应执行回滚，则告知 客户方 情况并延期上线。

3.4.2 生产联调

​ 对有 合作方（对端）参与的需求，开发方 在生产环境冒烟测试通过后，通知 客户方 协调合作方配合验证，并解决联调过程中产生的问题，如出现无法即时解决的问题，执行发布回滚，后续解决后再申请上线。

3.4.3 交付通知

​ 在 开发方 完成生产发布、与 合作方 完成生产联调后，由 开发方 发布《XX上线说明》文档，邮件通知 客户方 上线结果

3.4.4 代码同步

​ 在需求完成上线后，开发方 整理本次改动的代码，并同步给 客户方 约定代码仓库

3.5 紧急问题

​ 为应对突发性、紧急性状况（如线上BUG紧急修复、突发性需求），针对紧急需求以优先解决问题为主，由 开发方 对需求进行评估、实施改造，并同步向 客户方 说明解决方案 (语音/微信/邮件… 可选其一)、预估上线时间。开发方 完成生产发布、处置完状况后，向 客户方 输出《XX问题/反馈/补充说明》

4. 附录

• 文档说明

• 版本修订记录