小牛在线研发项目流程及工作约定V1.0

小牛在线研发项目流程及工作约定V1.0所属域□研发

□运行维护

□运营

□产品

□市场

□支持管理

□财务

□品牌公关

□机构合作

□用户体验

□数据□客服流程类型□公司级流程

□跨系统流程

□系统内流程

□跨部门流程

□部门内流程适用范围小牛在线研发项目流程owner需求提出人，版本负责人，产品负责人，系统设计人员、美术、UI、开发人员，测试人员，运维人员等*版本信息版本更新日期更改要点说明编制审核批准1.02016-11-25创建文档定慧王昱茜郭玮目录内容1.研发项目流程总览2.版本启动前流程&标准3.TAPD需求流程4.版本转测流程&标准5.TAPD缺陷流程6.准生产环境测试提包规范7.版本发布流程&标准8.其它约定版本正式启动前说明常规版本均需按照该流程执行，紧急版本：现网问题解决的版本、临时增加的新需求版本且版本工期在5个工作日之内完成的版本，可根据具体情况进行裁剪所有对外发布版本需创建迭代并标注版本号（紧急版本除外），即对外只能按版本发布，不能发布单个需求若后续步骤中，发现某一部分质量不符合，要将这一部分内容“回滚”直到满足要求需求的类型定义以及需求变更流程参看《小牛在线需求管理制度指引》研发项目流程总览版本启动前流程图版本启动前流程活动步骤输入活动说明和责任人输出备注一、需求规划需求部门提交的需求针对各部门提出的需求进行需求调研以及评估，输出需求文档和原型——产品负责人组织需求澄清，确保产品、设计、开发、测试、运维人员对需求理解一致，并确认需求优先级和初步排期——产品负责人根据需求和原型输出交互设计、视觉设计——设计负责人评审通过的需求以及原型初步排期确认的交互设计、视觉设计稿需求评审会，开发、测试人员必须与会，运维人员根据需要参加二、需求确认第一步的输出物根据第一步输出进行需求的细化和拆分，编写系统设计文档，明确设计方案，数据库设计，接口设计，模块分解等——开发负责人对细化后的需求、交互、视觉、系统设计进行评审，以确保大家对需求和设计理解一致——开发负责人细化的需求系统设计文档需求及设计文档可提供测试用例编写参考，且需作为转测交付件三、版本计划第二步的输出物评估开发工作量和风险，确认开发计划——开发负责人评估测试工作量和风险，输出测试计划——测试负责人输出上线部署计划——运维负责人TAPD创建迭代，明确迭代内容、迭代目标、迭代启动、转测和发布时间（如涉及免测版本需注明免测标识，并说明免测原因）——版本负责人发送版本启动邮件，知会到所有干系人——版本负责人描述完整、已拆分并达成一致的需求列表经产品、开发、测试、运维评估通过的版本计划版本启动邮件可根据版本具体情况选择是否召开版本启动会议版本启动标准序号主要启动要求描述责任人备注1明确版本发布目标、版本范围、版本计划（开发、测试、运维完成时间）版本负责人2产品需求通过评审&评估，确定需求初步排期产品负责人3交互设计、视觉设计定稿设计负责人3细化的需求以及系统设计文档通过评审开发负责人4TAPD创建好迭代，包含以下内容：

1、迭代目标（迭代相关信息，如概括本迭代主要完成内容、风险、版本负责人、测试计划等）；

2、迭代启动、转测和发布时间；

3、版本、开发、测试、产品、运维负责人名单。版本负责人5准备好TAPD需求列表，满足下面条件：

1、明确每条需求/任务的开发人员、测试人员、预估工时；

2、需求、任务已细化到具体的子模块，且各子需求预估工时不超过2天；

3、需求内容清晰无遗漏，明确优先级；

4、每条需求/任务的预计开始和结束时间填写完毕（根据依赖关系和需求优先级）；

5、明确需求验收标准。开发负责人6确定好本版本需要的测试计划和测试方案测试负责人7确定上线部署计划运维负责人8召开版本启动会议（可选）并发送版本启动邮件知会到所有干系人版本负责人说明：版本启动前所有需求以及设计文档应已确定。TAPD需求流程规划中：产品负责人将获取到的新需求录入TAPD待排需求池，并组织对需求进行讲解评审中：开发负责人在完成需求的细化以及系统设计后，针对需求具体情况组织评审，以便产品、开发，测试，运维对需求以及设计理解一致，将状态流转到评审中已评审：版本负责人将评审后的需求规划到具体的迭代，并将该需求流转到对应的开发人员开发中：开发人员进行编码，并完成codereview以及自测联调，保证冒烟测试通过后，将需求状态流转到故事验证，若不需故事验证，则直接发起测试申请邮件，将需求流转到对应的测试人员故事验证：测试人员进行故事验证，发现的缺陷录入TAPD，验证完已修改的缺陷，并在开发提交的转测申请评估通过后将状态流转到测试中测试中：测试人员进行测试验证以及预发布验证，发现的问题录入TAPD，缺陷修复验证OK后将状态流转到已完成已完成：该状态为需求的正常结束状态（包含完成测试后的待发布和已发布两种状态）挂起：由于不可控原因，如其他高优先级紧急需求加入，导致该需求暂时挂起，可重新打开到开发中已拒绝：不再需要的需求，该状态为需求的异常结束状态，处理人需备注清楚拒绝原因，并周知干系人版本转测流程图版本转测流程活动步骤输入活动说明和责任人输出备注一、开发1、开发完成代码1.开发完成后，开发人员需要对照需求范围和验收标准进行自测，若涉及到多模块需进行自测联调，确保开发质量；保证冒烟测试用例执行通过——开发负责人/版本负责人2.为进一步保障代码质量，可先用静态代码检查工具扫描代码，确保所有扫描问题都清零再提交代码（可选）——开发负责人持续开展Codereview（走查、会议评审），检视发现的缺陷建议提交缺陷库，确保问题及时修改

——开发负责人组织测试用例评审，确保对应的开发负责人、产品负责人参加，并输出测试用例评审报告——测试负责人开发自测联调通过后执行故事验证，故事验证发现缺陷提交缺陷库并输出测试日报——测试负责人及时修改故事验证阶段缺陷——开发负责人自测试验证结果（无需求验收标准情况下提供）；静态代码检查工具扫描结果（全部清零）；Codereview问题已修改；故事验证所需接口、配置文档等；评审后的测试用例以及评审报告已修复缺陷列表测试日报故事验证通过的需求。1.自测试结果体现在转测试申请的“测试说明”中2.需求可单独转故事验证二、集成测试转集成测试版本；转测邮件；集成测试所需接口、配置文档。评估转集成测试版本是否达到转测标准，如评估不通过，可做版本打回处理——测试负责人执行集成测试，集成测试发现缺陷提交缺陷库并输出测试日报——测试负责人及时修改集成测试阶段发现的缺陷——开发负责人已修复缺陷列表；测试日报集成测试通过版本；测试验证通过的接口、配置文档。三、预发布测试第二步的输出物执行预发布测试，预发布测试发现缺陷提交缺陷库并输出测试日报——测试负责人输出TAPD测试报告邮件——测试负责人预发布版本；测试日报版本部署文档;TAPD测试报告。说明：若测试工时（含故事验证、集成测试以及预发布测试）>=5个工作日时，在测试阶段需输出测试日报版本转测标准序号。主要转测要求描述责任人备注1需求以及系统设计文档（含接口文档、数据库设计文档等）评审通过开发负责人2代码通过静态代码检查工具扫描，并保证扫描发现问题清零开发负责人3已完成SQL审核（可选）测试负责人通过查看TAPD“SQL审核”任务是否已完成4所有的新增特性和本版本修复的缺陷需要通过自测试（自测试验证标准参考需求验收标准）开发负责人Bug回溯会挑选开发自测能够发现/重新打开的缺陷进行回溯5对于重要逻辑和关键点，增加单元测试，并保证单元测试全部通过开发负责人6基本冒烟测试用例100%通过测试负责人7涉及多模块的需求已完成自测联调，发现的缺陷已修复版本负责人8所有的新增特性需要开展故事验证，并保证故事验证通过测试负责人9a.故事验证发现的所有必现的严重/高优先级以上的缺陷必须完成修复；b.其它未修复缺陷，需经产品、开发、测试三方评估对版本测试无影响后，可以开展转测试产品/版本/测试/开发负责人10提供安装部署包、发布文档（readme）版本负责人说明：

1、不符合转测标准，请测试负责人做转测试评估时打回版本2、回归版本也按照一样的标准要求TAPD缺陷流程新：开发、测试或运维人员发现缺陷，录入TAPD缺陷单，初始状态为新（在不知道对应的开发人员时可先提给版本负责人）接受/处理：开发人员确认缺陷，将状态流转为接受/处理状态，进行定位解决已解决：开发人员将问题修复并自测试通过后将状态流转为已解决并将缺陷流转给对应的测试人员已验证：测试人员接收到TAPD已解决缺陷单后进行验证，确认OK则将状态修改为已验证。重新打开：测试人员在验证时发现问题尚未解决，或一个分支已解决另外一个分支未解决均需重新打开，流转给对应的开发人员（若该问题已解决但引入了其它新的问题，则新建缺陷单）已拒绝：当版本负责人或开发人员定位为非缺陷时，与提单人确认OK后将状态流转到已拒绝，并备注拒绝原因已关闭：为缺陷的最终状态，由缺陷创建人关闭缺陷挂起：确认是问题，但因不可控力在本版本无法修改（如，第三方问题，环境问题等）且不影响版本正常发布的缺陷，经版本负责人，产品负责人、开发负责人，测试负责人以及运维负责人确认后可置为挂起状态。（挂起状态非缺陷的最终状态，需定期对挂起问题进行确认）说明：关于缺陷录入说明1、开发人员录入：Codereview、自测试发现的缺陷（免测版本）2、测试人员录入：故事验证、集成测试、预发布测试、发布确认时发现的缺陷3、运维人员录入：现网环境相关的缺陷准生产环境测试提包规范所有提测批次包里，按照开发负责人提供的目录（分模块提测）进行提测。在模块下的app和web目录，需要存放测试通过的最新的zip包。在各个模块中保留开发提测包的方式，如每个模块分

app和web

目录，sql，readme等。

测试负责人需对各个模块中开发负责人提交的readme文件进行评审，确保在测试环境中所有配置项都配置正确，并通过测试运维负责人根据每个模块里的readme进行环境部署。如：20161115_1

提测包里按照各个模块的方式进行提测。如

product模块：增量APP目录增量WEB目录版本发布流程图版本发布流程活动步骤输入活动说明和责任人输出备注一、提交发布申请测试验证通过版本；上线部署操作文档/邮件（发布文档）。会议评审：版本负责人组织对发布版本的功能进行演示，并对遗留缺陷进行评审，产品、开发、测试、运维共同评估是否可带BUG发布，若评审不通过，则结束发布流程。若会议评审通过，版本负责人在TAPD上提交“发布评审”申请，需提供上线部署操作文档（包含发布、回滚和验证步骤），并注明是否灰度发布（重构和新功能版本需要灰度）发布评审申请未上TAPD的项目请走邮件审批二、发布评审第一步的输出物会签审批：由产品总监、研发总监、测试总监、运维总监共同会签，需四方均审核通过后才可发布；若会签不通过则需修改后重新发起发布评审——版本负责人会签通过的发布评审三、发布实施和确认第二步的输出物发布实施：严格按照发布文档中的上线部署步骤要求进行上线部署操作，确保部署成功，如部署失败进行打回处理——运维负责人若需要灰度，则先灰度发布再全量发布——运维负责人发布确认：版本完成线上更新后，版本负责人结束发布评审流程，确认发布完毕确认版本发布完毕重构和新功能版本先灰度再全量发布，二次开发和优化需求直接全量发布说明：需求上线后，涉及到与运营相关的需求，请产品负责人通知

运营人员进行上线事宜处理版本发布标准序号主要发布要求描述责任人备注1提供版本所需发布文档（readme）测试OK测试负责人2确定需要在当前版本修复的现网缺陷，如果没有完成修复，不能发布版本版本/测试负责人3所有必现的严重/高优先级以上的缺陷必须完成修复版本/测试负责人4重构以及新功能版本先灰度再全量发布版本/产品负责人5若有严重及以上必现的遗留BUG需会议评审通过版本/测试负责人6偶现的致命类、严重类Bug且优先级为中级以下的Bug，经产品、开发、测试三方评估影响面后，可以暂时挂起或在下一版本修复产品/版本/测试负责人

说明：测试版本评审经产品负责人、研发总监、测试总监、运维总监审核通过后