22-【行业案例】公司研发部项目管理手册（网络招聘企业）.docx

产品研发中心 项目管理手册(试行) V0.1 一、 目的： 为了规范产品研发中心项目管理流程，提高项目的质量，并保证对项目数据的收集和分析，特此编写产品研发中心项目管理手册，以期对产品研发中心的项目过程形成指导作用。 二、 适用人员： 该规范适用于产品研发中心项目过程中相关人员，包括开发人员、测试人员、运维人员。同时也试用与产品部门以及运营部分等与产品研发中心有项目交集的部门（主要作为项目需求提出方的部门）。 三、 手册规范概述： 由于XX目前还处于创业期间，对于项目管理采用敏捷式管理，更加注重过程和产出，对于过程中的要求比较简洁，也尽量简化。 同时为了将来产品研发中心扩展和规范化考虑，也初步设定了项目管理过程，以及期间的重要节点和中间输出，供大家遵守。 产品研发的过程包括需求管理、设计管理、估算与排期管理、进度管理、测试管理和上线管理几部分组成，如下图所示，标注红色部分为具体产出物。 其中需求管理包括：需求预确认、需求评审、需求返讲与确认。设计管理包括：方案设计、方案评审。估算与排期管理包括：开发、测试工作量估算、需求排期，并将结果更新到功能跟踪表。进度管理包括：迭代管理，任务进展流程管理。测试管理包括：测试用例管理，用例执行，Bug追踪与汇总，测试小结。上线管理包括：系统发布，上线管理，上线验证、回滚，上线小结。 四、 需求管理： 需求管理包括如下三部分：需求预确认、需求评审、需求返讲与确认。 (一) 需求预确认 产品部分在进行产品设计、策划的过程中会与开发部门针对功能可实现性，实现形式等内容进行沟通。在正式提交产品会议之前，会将功能与研发人员进行需求预确认，确认产品细节，以及技术实现形式，确保产品切实可行。 (二) 需求评审 在产品功能通过产品会议之后，提交给产品研发中心，研发人员会进行需求评审，确认产品的细节可以细化到开发阶段，每个功能的流程描述清楚，关联和影响功能分析清楚。达到开发标准。 需求评审通过，则该产品功能正式进入到开发阶段，如果产品功能未细化，或者关联功能分析未妥当，产品人员需要进一步对功能进行细化，方能再次进入开发阶段。 (三) 需求返讲与确认 产品需求通过需求评审之后，进入正式开发之前，开发与测试人员需要针对需求想产品经理进行需求返讲，确认需求理解一致。返讲通过之后才能正式进入开发阶段。 在需求实现过程中，在开发完成提交测试前，测试完成上线前需要进行实现确认，保证实现的功能达到预期，如果没有达到预期可以责令开发人员进行修改。 上线之后，产品人员需要第一时间对功能进行验收，如果有问题需要及时修改。 五、 设计管理： 设计管理包括设计方案的编写，以及设计评审两个方面。 (一) 设计方案 对于比较复杂的功能（需要引入新的技术框架、模块。或者实现比较复杂），需要编写设计文档，提交到Quip。形成设计方案。 (二) 设计评审 对于技术方案需要经过条线负责开发人员，架构人员的评审才能通过。 产出物：《Quip设计文档》 六、 估算与排期管理： 对于通过需求评审的产品功能（复杂功能需要通过设计评审），开发和测试人员需要对功能进行估算，估算之后确定初步的排期（预计上测试和上生产的时间）和初步的分配人员。后续需要对估算和排期进行估算。 七、 进度管理： 进度管理包括迭代管理和具体功能流程跟踪两部分组成。 (一) 迭代管理 目前迭代周期暂定为一周，基本方式采用Scrum的迭代管理方式，在进入迭代之前确认迭代任务，以及迭代任务的分配。由于目前还处于早期，产品会有输出不足，或者变更等情况，迭代中的工作内容会出现一定程度的变更，变更部分会以真实的工作内容部分为准，会折算70%的产率，折算为理想人天。 (二) 任务进展跟踪 在具体任务的进展过程中，由于涉及产品，开发（页面开发、后台功能开发），测试，运维等多种角色人员，流程比较负责，所以对于功能开发较复杂（估算超过1人天）的任务，都需要通过流程单进行跟踪。 八、 测试管理： 测试工作穿插于开发前中后期，包括测试用例准备，测试执行，Bug跟踪，测试小结等工作。 (一) 测试用例准备 在需求评审通过之后，就开始准备测试用例，注意不同功能的测试用例覆盖率情况，不同标准的功能测试覆盖率要求也不相同。 测试用例准备目前采用TestLink来进行测试用例管理工作，不同功能的用例通过TestLink进行编写和管理。 产出物：TestLink中测试用例 (二) 测试用例执行 目前阶段（特别是新功能）仍然是以手动测试为主，主流程和之前经常出现问题的部分才会考虑以自动化测试为主。 目前测试用例执行，会在testlink中分配执行人员和执行计划。目前测试主要包括三轮测试， Ø 测试环境测试（测试Test分支）。开发完成之后提交测试环境进行测试工作。 Ø 准生产环境测试（测试Master分支）。测试环境测试通过之后，代码合并到Master分支，发布到准生产环境进行第二轮测试。 Ø 上线测试。准生产环境测试通过之后，在生产环境进行发布，并进行最后的测试。 (三) Bug跟踪与管理 在测试过程中发现的Bug，测试人员会提交到Redmine，并提交给开发人员，开发人员需要对缺陷进行修改。 测试人员需要跟踪Bug的进展，并对修复的Bug进行再次测试。 (四) 测试小结 上线之后，或者每迭代结束之后，测试人员需要对本迭代的工作进行小结。每个功能中，每个开发人员产生的Bug数量，以及Bug汇总统计信息。测试人员设计的用例数量，执行过程中发现的Bug数量，上线之后才发现的缺陷数量（也即每个测试人员未发现的Bug数量）。 九、 上线管理： 根据划分的排期和迭代计划，会对通过测试的功能进行上线。确定的上线时间由运维人员进行系统上线发布。发布成功之后，由测试人员进行上线测试，产品经理进行功能验收，通过之后才算上线成功。如果测试人员或者产品经理在测试过程中发现问题，开发人员需要快速进行问题修复。如果问题影响较大，或者修复困难，则需要进行上线回滚。 上线完成之后，运维人员需要对上线情况进行上线小结。 十、 版本管理： 在开发和测试过程中，会不断涉及到版本和分支。需要对版本和分支进行严格管理。 (一) 版本管理 大版本号由产品规划决定，小版本号由每次上线决定。 每个版本包括的内容，以及每个内容的进展情况，由产品人员与开发人员确定。分别进行跟踪。 每次上线之后，会对应小版本号码更新，只有本次大版本所有内容都修改完毕之后，才会对应提升大版本内容。 (二) 分支管理 开发和测试过程中，会对应分支切换。并且线上系统和内部系统的分支管理略有不同。 Ø 线上系统 开发人员主要在dev进行开发，进入发布周期，切换到Test分支，提交测试环境供测试人员进行测试。测试通过之后，Test分支合并到Master分支，准备发布。发布成功之后，Master分支归并到dev分支。 Ø 内部系统 内部系统功能开发前会先从dev分支建立分支，进行开发，开发完成之后合并到dev分支，然后切换到Test分支发布，然后合并到Master分支，并最终合并回dev分支。 具体分支管理可以参考《分支管理手册》。 6 / 6