开发流程规范

流程

1. 需求整理： 和业务、开发 深入 沟通之后做产品设计，以产品原型、产品文档方式整理出详细产品方案
2. 需求评审： 产品文档、产品原型完善之后邀请设计师、测试、开发（如有必要建议加上业务方）参加需求评审会；会议开始前要求所有参会人员已经认真地看过产品经理提供的产品原型、产品文档；在该会议上所有参会人员对产品细节提出疑问，力求所有人对所有细节都有清晰明确和一致的理解，如果有异议，讨论之后由产品/业务方修改需求后重复该环节。会议最终结果要求所有人对产品需求描述（原型、文档）清晰明确无异议。
3. 准备阶段： 需求评审会之后各岗位并行启动，测试开始写测试用例，设计师设计初稿，接口设计接口方案，开发设计开发方案
4. 测试用例评审： 所有人参与测试用例评审，通过对测试用例的评审加深对需求的逻辑细节理解，进一步完善开发方案和接口方案、产品和设计师一起完善交互设计
5. 设计方案评审： 评审设计方案，对于开发来说主要是避免出现某些特殊情况下的设计方案缺失，例如横向/纵向元素较多时在小屏幕下的设计是否缺失，元素内容弹性较大时（文本长度）不同内容的设计方案是否合理完善，动态表现是否合理等
6. 接口方案评审： 开发和测试、产品（可无）评审接口方案，最后以文档形式交付
7. 开发方案评审： 产品、测试一起评审开发方案，避免开发方案设计缺陷、前后端对相同业务理解不一致
8. 开发阶段： 开发开始严格按照开发方案分模块进行迭代开发，测试开始按照测试用例和接口文档编写接口测试代码、测试脚本
9. 测试阶段： 开发分模块提交给测试进行测试，开发配合测试Debug
10. 上线： 所有模块测试完毕，gitlab 上打 tag，打出各渠道包，提交上线
11. 需求更改： 开发、测试过程中若有需求更改（包括但不限于产品逻辑、文案描述、UI 设计），重复执行以上步骤。严禁直接找开发私下调整，务必保证所有改动都会通知到所有人。注：不需要步骤的可以跳过，例如 UI 改动，不需要“接口方案评审”，接口改动不需要“设计方案评审”。

各环节及岗位交付要求

1. 产品交付要求：        
   1. 文档完整、无歧义、简洁、通俗易懂，产品原型请保证“基本交互”，最好是高保真
   2. 若有判断逻辑的，请在产品原型上注明某项操作导致的后续流程所需要执行的判断逻辑。
2. 接口交付要求：
   1. 以接口文档形式交付（推荐代码生成）
   2. 注明都有哪些接口；
   3. 注明每个接口的业务说明；
   4. 注明每个接口的数据结构；
   5. 注明每个接口的各字段是否可以为空；
   6. 各接口中相同含义的字段名称和数据类型要保持相同；
   7. 如果存在枚举字段，需要详细给出各状态的枚举值以及对应的说明；
   8. 接口请求头、请求格式的详细规定；
   9. 接口非正常响应状态的详细规定；
   10. 接口评审完成后要尽快先给出“假数据接口”；
3. UI 交付要求：
   1. 文件夹路径按照产品原型逻辑组织，每个对应模块的文件夹下应包含所有页面对应的标注图，不应将类似标注图放到其他文件夹下
   2. 提供全局适用的设计规范定义，以及适用说明：包括但不限于全局用到的颜色，字体大小，按钮在各种状态下的背景色、前景色、宽高，文本间行间距，文内折行时的行间距，分割线颜色，内边距等等
   3. 需要提供不同尺寸的屏幕下设计差异性，例如横向/纵向元素较多的情况下，需要提供小尺寸屏幕的设计标注图；横向/纵向元素较少时，需要提供大尺寸屏幕的设计标注图；若元素内容多少弹性较大时，请提供不同情况下（内容较多和内容较少）时的设计标注图
   4. 切图要压缩
4. 测试方案交付要求：
   1. 完善的测试用例文档
   2. 接口测试方案（最好有测试脚本能够批量测试所有接口）
   3. 上线必备流程/条件
5. 开发方案交付要求：
   1. 技术选型调研结论报告（优劣比较、踩坑方案）
   2. 复杂的业务流程要给出流程图、时序图（图可以很简单，但是要能精准地诠释方案）
   3. 复杂需求更改及代码重构要有架构设计方案，需要经过内部评审
6. 开发阶段执行要求：
   1. 严格按照**4个参考（开发方案、需求文档、产品原型、设计图）**开发/Debug，代码提交前务必执行单元测试
   2. 若开发过程中发现设计标注或产品需求描述不够清晰、逻辑错误等问题，需邮件知会项目组内所有人，重复执行流程步骤解决问题。严谨私下沟通私自解决，防止其他人不知情导致工作出错
   3. 开发过程中若需要修订技术方案，需要开会讨论，知会相关同事

转载原地址：开发流程规范_天亮哥的博客-CSDN博客