1、Git代码提交注释规范
需求类Git注释
需求注释格式是：需求#{需求ID}：开发人员填写的注释内容
例如：需求#123456 API接口开发和提供
Git命令：
代码语言：javascript复制$ git commit -a -m "需求#123456 API接口开发和提供" 效果类似如下示例：
提交后，需求状态自动更新为：研发中、自动上屏到需求备注（方便code review）。
问题类Git注释
格式是：bug#{问题ID}：开发人员编写的注释内容或问题原因
例如： bug#123456 这里可以填写修复的原因
Git命令：
代码语言：javascript复制$ git commit -a -m "bug#123456 这里可以填写修复的原因"效果如下示例：
提交后，问题状态自动更新为：已解决、自动上屏到问题备注（方便code review）、邮件通知问题创建人员并推送钉钉群消息。
上面的需求和Bug提交规范，可以自动和YesDev的需求、Bug进行关联。
2、开发提测新模板
新提测模板请参考：《开发提测模板》
邮件标题：XXXX提测申请
项目链接：// 填写YesDev对应的项目链接或需求链接
开发分支：// 粘贴Git仓库分支链接
code review：// 分支对比链接，以及审计负责人
测试环境：// 填写测试环境的域名或APP安装包链接或小程序体验二维码
开发人员：// 参与本次开发的人员名单（可以进一步补充每个模块的主要负责人）
提测内容：// 原来的提测内容
影响模块：// 原来的影响模块
3、线上故障复盘模板
可以参考YesDev给出的故障复盘文档模板进行复盘，包括：故障标题、故障描述、故障影响及损失评估、处理过程、故障原因、后续改进措施等。
4、YesDev协作流程
1、面向产品经理和需求方
如何分类提需求？
1）常规迭代需求，添加需求或通过Excel导入，由技术负责人 创建项目并进行关联需求，评估工时，排期开发
2）紧急需求，需求方/产品经理和技术负责人沟通确认后，追加需求到已经排期的项目中，并且邮件同步发出
3）专项需求，创建项目后，维护项目需求，并指派需求给技术负责人
4）小改进需求，通过 问题-改进，进行单独提交，非技术问题，属于产品需求的小改动，例如：修改文案、更换图片或链接等
如何查看最新开发进度？
1）通过项目的详情页，查看项目进度和需求进度
2）在需求详情页，通过查看需求的代码提交记录，查看开发动态
3）通过 需求排期，查看当前最新的需求排期计划和迭代进度
4）通过每周的需求KPI邮件《每周需求迭代汇总》定时接收需求迭代的周记录，发送时间支持可配置
5）通过邮件、钉钉群消息，接收相关的需求流转新动态，例如：需求已完成、需求已上线等
6）通过钉钉群 【发布群】上线发布专用群，接收最终发布上线的通知，可以和YesDev进行集成
7）通过项目排期、提测邮件等，接收项目迭代汇总的信息
2、面向研发团队
如何流转需求？
1）根据需求，评估开发任务、工时、和预计完成的时间，在每周一之前形成自己的周工作计划
2）完成任务后，及时将任务状态改为DONE
3）开发过程中，提交代码时，按需求注释规范提交Git代码
4）需求完成或上线后，人工更新需求状态为：已完成/已上线
如何流转问题/Bug/故障/工单/改进？
1）问题解决后，将问题状态改为：已解决，并补充原因
2）问题重开后，重新修复后，将问题状态重新改为：已解决，并补充原因
3）可以按问题注释规范，提交Git代码，会自动更新问题状态为：已解决，并通知对方
4）遇到紧急的故障，应立即响应并处理，按“先止损-后定位-再排查-改代码-发布修复-最后复盘”顺序处理
如何统筹推进项目？
1）进行产品需求评审后，将已确定的需求，创建并关联到指定项目
2）分配需求到技术人员，各自拆解并评估任务和时间
3）汇总项目排期，发出项目排期邮件，如有需求，每天或每周或定时汇总重要项目的进度、风险和进度
4）关注每周的项目整体汇总邮件
3、面向测试部门
如何流转开发过程中发现的Bug？
1）在指定项目详情页，添加新问题到此项目，问题类型选择：Bug，并指派给技术人员
2）问题修复并验收后，将问题状态改为：已关闭，若依然有问题则改为：重开，并填写原因
如何处理线上故障？
1）发现故障后，第一时间在群里同步或现场沟通
2）同步创建故障单，并交给技术人员在故障处理完毕后补充编写
如何规划测试用例和测试计划？
1）可以创建或导入测试用例
2）可以创建测试计划并关联到指定项目
3）在测试计划，可以自动汇总并整理测试报告
4）可以定时接收每周的测试质量汇总邮件，跟踪每周的线上故障、工单等SLA服务水平
5、技术文档编写规范
针对重要的需求、核心功能、以及复杂的项目，可以按以下技术文档模板编写，以便进行技术评审。
开发分支：
// git的仓库分支
修改范围：
// 本次修改的页面、或新增的API接口等
技术设计：
// 核心的UML图，例如：时序图、泳道图、数据模型、架构图、流程图等
自测结果：
// 针对页面、接口、不同业务规则的自我验证，提供单元测试、链接、数据库截图以及其他材料证明
参考资料：
// 外部参考资料，例如XXX开放平台XXX接口
