研发管理规范

为了提高和保障需求从开发到上线的质量，结合公司及部门的实际情况，现起草如下细则，部门人员需严格按照此规范执行：

1.    系统内所有的改动，均要在云效上留痕，包括但不限于业务需求、系统缺陷、后台优化等。按照云效上的生命周期规则，以及模板要求，及时更新改动内容的明细，实时进行状态流转。
2.    所有的提交记录说明，必须严格按照如下规范编写（不要有空格）：

(1)   需求类：以“需求”+需求ID开始，如 需求1008694：

(2)   缺陷类：以“缺陷”+缺陷ID开始，如 缺陷1008623：

(3)   优化类：以需求类的规范为准

3.    每周五，开发人员对于归属自己的下版本需求，需要仔细分析，明确是否存在需延期任务，及时报给部门经理，沟通协商，规划好开发任务的优先级。
4.    最晚截止到迭代前两天下班前，本周需要临更的需求，必须完成开发、自测。例如周四更新，周三上班开始，无特殊要求不再进行本次迭代需求的开发工作。即所有上线的需求，要达到提测标准。达不到此标准的，报给部门经理，协商是否做延期处理。
5.    最晚截止到迭代前两天下班前，本周需要临更的需求，务必保证已在test2上测试完毕，代码合并到stage分支并发版。个别简易的需求、缺陷，跟进、督促测试，最晚在周四上午，达到临更标准。如无法达到目标，需马上撤回stage分支代码，同时报给部门经理，进行任务延期的沟通处理。
6.    迭代日上午，部门经理整理、发布本次临更涉及的需求、缺陷，各开发人进行确认，未转到测试通过阶段的，及时督促测试完成测试工作。最晚4点开始，由涉及更新的系统的负责人（见附表），进行本次更新涉及的代码、脚本、配置文件等内容的检查，检查无误后，提交临更审批。

(1)   所有应用的更新包，直接使用stage环境的，不再单独从本地打包。

(2)   如审批内容有修改，及时撤回重发。

7.    周四晚部署更新后，此次更新涉及人员，需仔细检查更新包、脚本、配置文件等是否正常更新，保障更新的准确性，并针对各自的更新内容进行验证。注意：大平台、国际都需要验证
8.    需求理解阶段，建立内部群，命名参考：xxx需求讨论群，人员包括部门经理、产品、测试、开发人员，需求最终落地前的讨论，在内部群里进行。改动较大，需要开会讨论的，要求产品将讨论结果落实到云效上。