# 1.Git代码提交注释规范
#需求类Git注释
需求标注格式为：需求# {需求ID}:开发人员填写的标注内容。
例如，需求#123456应用编程接口开发和供应
Git命令：
$ git提交上午'需求#123456应用编程接口开发和供应'
效果类似于以下示例：
效果如下：
qvj2l q49k 0/954 D5 ed 77 c 04 a6 CB 9 e 6961d 9 dec 5b 88 /
# 4，是开发合作流程
# 1.对于产品经理和需求者
如何分类和需求？
1)例行迭代需求，添加需求或通过Excel导入，技术总监创建项目并关联需求，评估工作时间并安排开发。
2)紧急需求，需方/产品经理与技术负责人沟通确认后，将需求添加到预定项目中，并同步发送邮件。
3)专项需求,在项目创建后，维护项目需求并将需求分配给技术总监。
4)通过问题改进单独提交的微小改进要求，不属于技术问题，属于产品要求的微小变更，如修改文案、更换图片或链接等。
qvj2l q49k 0/9d 13 CBA 617843 DCA 0 e 2265 F5 c 69708 /
如何查看最新的开发进度？
1)通过项目的详细信息页面查看项目进度和需求进度。
2)在需求详细信息页面，通过查看需求的代码提交记录来查看发展趋势。
3)通过需求调度查看最新的需求调度计划和迭代进度。
4)通过每周需求KPI邮件《每周需求迭代汇总》定期接收需求迭代的每周记录，发送时间可配置。
5)接收需求流的相关新趋势，如需求已完成、需求已上线等。通过邮件和美甲组信息。
6)通过美甲群【发布群】在线发布专属群，在线收到最终发布通知，可与YesDev集成。
7)通过项目调度、测试邮件等接收项目迭代总结信息。
iaoimg.com/large/tos-cn-i-qvj2lq49k0/409da741df9244c1a9b3ee2f5cbe2ed1' />
# 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接口
