工作流程定义 - shenliuyang/development GitHub Wiki

工作流程

项目/产品开发流程

项目和产品的开发都应遵循此流程规定。

需求分析

需求分析应拟定一个计划,在计划期限内由项目经理或产品经理按照需求说明书的模板完成,必须按照国际化UML用例的模式对业务需求进行分析,并给出用例的场景描述,符合需求说明书模板的要求,提交需求分析说明书,需求分析通过Review后可进入设计流程,需求分析的Review会议必须有测试人员参与。

原型设计

原型设计推荐使用Axure或者类似的专业原型搭建工具完成,也可以使用Visio,html来表述,但必须基于需求分析的基础产生,并应先确定需求,给出需求分析,否则原型无法保证能够开发实现。原型设计通过Review后可进入系统设计流程。

系统设计

系统设计包括系统性的分析,接口设计和概要设计文档,概要设计文档参见概要设计文档模板。

编码开发

编码和开发必须按照编码规范完成,其中包括编码格式,标准以及单元测试,集成测试脚本编写,过程中各个团队负责人应组织Code Review,记入考核。

测试

测试人员应根据需求分析编写测试计划和测试用例,根据测试用例对系统进行测试,最终根据测试用例执行结果撰写测试报告。

验收

由需求提出部门测试使用产品,完成验收。

部署和发布

部署和发布必须由operation组员完成,正式环境在部署前应进行版本发布备份。

工作任务分配

工作任务采用协作平台的问题方式进行分配,每个人在我的工作台可以看到指派给自己的工作任务,每项任务必须按照工作任务的处理流程来进行,问题分各种类别,有错误(Bug处理),我的工作(任务)等。每个人都应从“我的工作台”获取指派给自己的任务,也可以在相关项目内新建问题给其他的技术人员。

任务状态

任务状态分别为:

  • 新建 – 任务新分配
  • 进行中 – 任务正在执行中
  • 已解决 – 任务已完成
  • 反馈 – 存在问题,需要沟通
  • 已关闭 – 完成后已得到验证
  • 已拒绝 – 任务不合理,已取消

每次的任务更新都应做相关说明,尤其是类似已拒绝和反馈的状态,如无说明,则认为流程执行不合理。

问题处理流程

新分配的任务为“新建”状态,执行人收到新的任务后,如果对分配的任务的描述,开始时间,完成时间等没有异议,开始执行此任务前将“新建”状态改为“进行中”,每天下班时更新此任务的完成度,并书写相关信息,直至任务完成后,将状态更新为已解决。如果有异议请与任务分配人协商,更改任务的相关要素。如果任务完成时间分配者未填写,请任务执行者自行估计完成时间,更新时填写,Lead负责评估完成时间是否合理。

重要说明

研发部的人员必须按照流程完成自己的工作,未来的考评将以任务处理流程作为重要依据(所有的任务状态更新流程和相关注释都可通过报表导出),未能按时更新和完成工作状态的任务将被认为是流程执行不力和工作Delay,将影响本人的工作评估。

⚠️ **GitHub.com Fallback** ⚠️