研发规范及效能提升大致框架

研发规范及效能提升大致框架

一、事务性工作效能提升

阶段	关键流程点	判断标准	执行说明
PO(立项完成)	业务需求收集>需求整理、需求目标制定及业务价值分析>整理立项资料及立项评审	1、业务方案和业务价值梳理清晰
P1(业务方案设计)	需求准备>需求设计>需求评审	1、需求清晰；2、通过需求评审	1、 杜绝一句话需求：需求详细具体，清晰明了，按照需求规范进行梳理编制； 2、 非功能性需求涵盖，包括性能、容量、容灾、兼容性等； 3、需求变更及时知会，并同步更新需求文档； 4、合理规划，控制临时需求插入和需求变更； 5、联合需求联调、联测计划排期要保持一致，计划延期提前通知；
P2(设计&研发&测试)	需求排期》需求设计》需求评审》需求实现》需求自测/联调》需求提交测试	1、确定需求排期；2、准备合适的设计文档&通过设计评审；4、(可先)需求反讲，确保需求理解一致；5、完成功能需求&满足性能及安全需求；6、自测&联调完成；7、满足测试准入标准，通过测试的验证收；	设计：1、 设计详细完整，涵盖非功能性设计，数据库设计和接口设计等 设计满足系统的非功能性需求，包括性能、容量、容灾、兼容性等 数据库设计覆盖全面，包括数据定义，部署、同步方案、核对方案、安全存储方案等。 接口设计除了基本功能说明、参数定义、实现逻辑、错误码还须明确是否支持重入以及进行安全设计。 2、 设计变更及时知会，并同步更新设计文档 3、跨中心和部门的接口评审需要确认接口文档中所有的请求和返回参数，避免后期变更； 研发：1、严禁需求夹带 2、遵循编码规范 3、保障开发质量，业务主流程测试通过方可提测，建议通过单元测试代码覆盖保障 4、新增、严重的代码检查问题要求修复 5、提测文档齐套，信息准确 6、单边团队需要未联调先提测，需由双方开发 SE、测试 SE 再次确认接口，评估影响 测试：1、测试人员提前介入，了解需求并编写测试用例 2、通过自动化测试，保障版本对业务主流程无影响 3、开发人员及时处理测试缺陷 4、版本携带致命或严重缺陷，测试不准出 5、接口变更需重新联调再提测，并记录需关注版本 6、联调需求未联测先提发，需要双方评估影响 7、测试全部完成后开发提交确认后的发布计划（所有版本都要有发布计划）和回退计划
P3(UAT)	用户体验	1、功能实现满足业务设计要求；2、页面交互符合产品交互设计；3、通过 UAT 验证；
P4(启动结项)	结项评估
P5(结项完成)	发送结项通知，更新项目状态为结项

二、技术工具效能提升

1、记录分享

记录团队成员在团队内及部门内的分享，用于团队整体的学习及能效提交。

分享主题	分享内容简介	结题日期	参与人
领域工程快速框架	沉淀后端研发框构通用能力，使其能够快速的应用到新的项目场景，包括但不限于：1、多语言的支持；2、多数据源的支持；3、自动生成ORM代码、Service代码及Controller代码的生成；4、常用的工具包的集成；5、异常的的通用处理；6、支持Consul注册中心的快速集成；7、支持定时任务的快速集成；8、支持Apollo注册中心的快速集成；9、单元测试实现率检查集成；10、API文档管理工具集成；11、代码扫描工具的集成；
线上问题发现解决方案及工具	当线上应用发生问题时，能够通过一定的消息渠道通过企微、邮件、短信或电话通知到开发人员，以便于研发人员及时介入，分析问题并解决问题，减少对用户的影响。
联调测试提效方案	提升开发过程与测试环境其它应用联调的效率、提升与前端联调的效率

2、知识库沉淀

记录团队成员在日志工作中的经验总结、问题分析发现的总结沉淀等，以便于帮助团队成员提交效率或解决相同及相似的问题。

分享内容	内容简介	分享日期	分享人
（示例）[如自动生成后端工程时YAPI接口文档的Maven插件]	项目研发的过程中，作为后端人员往往需要先定义好接口，以便于其它协作方可以同步进入开发，目前通常的做法是在yapi等接口管理工具中先定义好接口，然后通知协作方根据接口文档实现。如果接口的定义一切顺利，后期没有大的或者是频繁的调整，通常也不会出现问题；但是项目及需求的变化往往超出我们的期望，通常随着研发人员、产品经理等对业务的不断理解或者需求的变更，后端研发人员定义的接口往往都需要根据业务的变化而变化。这个分享通过使用自动化的工具解决来解决上面的提到的问题。

3、学习资源推荐

记录团队成员收集的一些好课、好文章等，分享给团队成员共同提升。

学习内容	内容简介	分享日期	分享人

三、团队协作

用于记录团队面临和共同问题，需要大家一起共同来解决。

问题名称	问题说明	问题提出人	问题提出日期	问题认领人	认领日