项目管理流程适用于服务器开发评审版.docx

1、项目管理流程适用于服务器开发评审版项目管理流程（适用于server开发） 版本号：1.0目录：1. 概述本文档旨在通过建立规范化标准化的项目管理流程并且不断地改进、优化，达到提高工作效率，标准化项目管理，提高软件质量，优化资源配置，减小风险事件等不良影响，降低沟通成本的目的。进而，为公司拓展业务、扩大规模、持续发展，扫除阻碍、铺平道路。2. 适用范围本流程适用于北京无限立通基础平台服务器开发的项目管理使用3. 术语和缩略语下列术语和缩略语只适用于本规范：3.1 术语术语说明输入每项任务开始时的前提条件活动每项任务的具体工作内容分解输出每项任务经过活动后得出的结果，原则上要求所有的输出内容需要保

2、存、备份。负责人指当前任务项的主要负责人参与方指当前任务项的配合、辅助人员3.2 缩略语缩略语英文全称中文含义MRDMarket Requirement Document市场需求文档PRDProduct Requirement Document产品需求文档SRDSoftware Requirement Document软件需求文档4. 项目管理总流程图以下是无限立通项目管理总流程图（本流程适用于服务端的开发）5. 项目管理规范和流程5.1 产品需求文档（PRD）生成输入：移动规范、业务部提出需求、开发自行新需求活动： 产品经理结合移动规范、业务部提出的新需求或开发自行提出的新需求，对产品进行整

3、体规划； 产品经理根据产品规划，编写和制定产品需求文档； 产品需求文档输出后，产品经理须召集项目经理、开发人员、测试人员对产品的具体需求进行分析、同步及讨论； 针对产品需求中的实现功能点，如果评估有涉及到技术难点或风险点的，需要做前期的技术调研工作。输出：产品需求文档负责人：产品经理 参与方：项目经理、开发人员、测试人员5.2 技术调研输入：产品文档活动： 针对产品设计讨论过程中所提出的技术性风险、难题进行前期技术调研，技术调研都要有一定的深度，评测结果要真实可信，其他来源的数据仅能作为参考，要以自己的测试结果为主要依据； 调研工作结束后，必须编写技术调研报告，报告中要有对被调研技术的分析和建

4、议结论； 技术调研报告完成后，需要与相关人员共同评估被调研技术，评估完成后，针对该技术的调研工作完成； 如果在调研过程中有涉及到相关的代码和demo，需要在技术调研报告中体现，并说明具体放置的路径。输出：技术调研报告、代码、Demo负责人：开发人员 参与方：产品经理、项目经理5.3 软件需求文档（SRD）编写5.3.1 软件需求文档（SRD）编写输入：产品需求文档活动： 项目经理根据产品经理提供的PRD文档，将PRD文档转化为软件需求文档； SRD文档主要内容包含： 项目名称 术语解释 功能需求描述 性能需求描述 安全及可扩张性需求 所参考的协议和规范（包含内部协议和外部协议） 接口要求 软硬

5、件需求 产品质量要求 项目大致计划等 具体格式可参见软件需求文档模板输出：软件需求文档负责人：项目经理参与方：产品经理、开发人员、测试人员5.3.2 SRD文档评审输入：SRD文档活动： 项目经理编写好SRD文档后，召集产品经理、开发人员、测试人员进行讨论、评审，并输出评审报告及修正后的SRD文档。输出：评审报告，修正后的SRD文档负责人：项目经理参与方：产品经理、开发人员、测试人员5.4 项目预立项输入：SRD文档活动： 项目经理根据最终确定的SRD文档对项目进行预立项，对后面的工作进行安排和规划； 预立项工作主要是针对接下来的“项目整体方案设计”阶段进行规划和计划安排； 项目整体方案设计主

6、要涵盖以下四大部分： 技术方案的设计（包含概要设计及详细设计） UI/UE的设计 测试方案及测试用例的设计 配置方案及计划的设计输出：项目计划负责人：项目经理参与方：产品经理、开发人员、测试人员、配置管理员5.5 项目整体方案设计5.5.1 技术方案设计5.5.1.1 概要设计文档编写及评审输入：PRD文档、SRD文档、项目计划活动： 在SRD完成后，需要开发人员对SRD、PRD进行系统分析工作； 必要时需要进行额外的技术调研，技术调研的流程仍参照5.2步骤进行； 初步系统分析完成后，需要编写概要设计文档； 概要设计文档至少包含内容： 系统架构 系统各模块的分解及功能说明 针对概要设计文档进行

7、评审，评审通过后初步系统分析完成 具体格式可参见概要设计文档模板输出：概要设计文档、评审报告负责人：技术负责人参与方：开发人员、项目经理、技术总监、测试人员5.5.1.2 详细设计文档编写与评审输入：SRD文档、概要设计文档、项目计划活动： 开发人员根据SRD和概要设计文档，进行系统模块的划分和分解； 分模块进行系统分析，各个模块的系统分析完成后，需要编写详细设计文档； 各子系统间的交互需要编写系统内部接口文档； 如本系统与其他系统有交互，需要编写系统接口文档； 针对详细设计文档、系统内部接口文档和系统接口文档须召集项目经理、产品经理、开发人员、测试人员进行评审； 具体格式可参见详细设计文档、

8、系统内部接口文档和系统接口文档模板。 输出：详细设计文档、系统内部接口文档、系统接口文档、评审报告 负责人：开发人员参与方：项目经理、技术总监、测试人员5.5.2 测试方案及用例设计5.5.2.1 测试方案设计及评审输入：PRD文档、SRD文档、概要设计文档、详细设计文档、系统内部接口文档和系统接口文档活动： 测试人员根据产品文档、需求文档及技术文档进行测试方案的编写； 测试方案包含：功能测试、性能测试、白盒测试； 测试方案编写完成后，需要组织相关人员进行评审，并输出评审报告； 测试方案评审后，测试、开发需双方达到确认。输出：测试方案、测试方案评审报告负责人：测试人员参与方：开发人员、项目经理

9、、产品经理5.5.2.2 测试用例设计及评审输入：测试方案、PRD文档、SRD文档活动： 测试人员根据测试方案、产品文档及SRD文档进行测试用例的编写和分解； 测试用例包含：功能测试、性能测试、白盒测试； 测试用例编写完成后，需要组织相关人员进行评审，并输出评审报告； 测试用例评审后，测试、开发需双方达到确认。输出：测试用例负责人：测试人员参与方：开发人员、项目经理、产品经理5.5.3 UI/UE设计（针对有界面展现的产品）输入： PRD文档、SRD文档、项目计划活动： 产品经理根据SRD文档、PRD文档对产品的UI/UE进行设计； 设计结束后，须召集项目经理、开发人员、测试人员进行评审。输出

10、：UI/UE设计文档负责人：产品经理参与方：开发人员、项目经理、测试人员5.5.4 配置管理方案及计划设计输入：SRD文档、PRD文档、项目计划活动： 项目经理根据SRD文档对项目的配置管理方案及计划进行设计； 配置管理方案主要涵盖以下内容： 项目名:（供内部使用） 发布版本命名及版本号：（每次版本发布时的版本命名及版本号控制，包含从输出给测试部系统测试起一直到正式版本的发布。） Sharepoint：（项目文件目录的规划和设计） SVN：（目录的规划和设计） QC系统：（目录的规划和设计） 资源配置1 人力资源2 设备资源3 其它无形资源（如开发环境软件、工具类等） 配置管理方案和计划设计结

11、束后，须召集开发人员、测试人员、配置管理员进行讨论及信息同步； 最后输出配置管理方案和计划，并同步给配置管理员作为后续项目配置管理的依据。输出：配置管理方案和计划负责人：项目经理参与方：开发人员、测试人员、配置管理员、运维人员5.6 项目正式启动准备5.6.1 项目计划制定输入：PRD文档、SRD文档、整体方案设计活动： 项目经理召集技术负责人进行计划预估及制定； 技术负责人须配合项目经理进行任务的分解和评估，同时对开发时间进行评估（技术负责人在预估时间时可找相应要参与的直接工程师进行共同预估时间点，以确保给出的时间尽量准确）； 评估的时间粒度原则上能让项目经理可有效的进行跟踪任务进展，具体的

12、粒度由项目经理根据项目实际情况进行把握（按照国内的项目管理惯例，一般情况下，最小粒度希望能细到1天。） 项目计划所包含的维度须涵盖： 服务器端开发 客户端开发 单元测试 联调 集成测试 系统测试 性能测试 封板发布等 项目经理根据开发、测试评估的计划，整理出整个项目计划；输出：项目计划负责人：项目经理参与方：开发人员、测试人员、运维人员、配置管理员5.6.2 项目组成员列表输入：项目计划活动： 项目经理根据项目计划中的人力资源，对所有项目组人员建立一份成员列表； 需明确每位项目组成员的职责； 如果有涉及到客户或第三方，也需要将其项目的负责人进行建立，以便保持后续联系； 项目成员列表至少包含姓名

13、、职责、电话、邮件等联系方式。输出：项目成员列表负责人：项目经理参与方：开发人员、测试人员、运维人员、合作伙伴、配置管理员5.6.3 风险评估及管理输入：项目计划、PRD文档、SRD文档、项目整体方案设计活动： 项目经理需组织项目组成员对项目的风险进行识别和评估； 项目风险主要包含技术风险、资源风险等； 根据识别出的风险，项目组需要对其严重程度及影响面进行评估，以综合评估风险的影响程度； 针对识别出来的风险，需要项目组共同讨论预防措施及应对措施，以防问题发生，将风险降到最低点； 项目经理根据识别出的风险点及讨论后的预防措施，进行管理，并跟进预防措施的落实情况，并定期更新和维护风险管理表。输出：

14、风险评估和管理表负责人：项目经理参与方：开发人员、测试人员、运维人员5.6.4 项目质量目标的设计和制定输入：SRD文档、项目计划活动： 项目经理根据SRD文档和项目计划对项目在实施过程中的每个milestone，产品所要完成的功能及达到的质量目标进行设计和制定； 项目质量目标需要分解到每个大的里程碑； 质量目标和测试用例需要同开发人员进行讨论、同步； 项目质量目标主要涵盖内容如下： 功能完成度 性能达到的要求 本阶段的输入及输出 本阶段质量所要达到的最终目的 评判标准 评判人员 输出：项目质量目标负责人：项目经理参与方：开发人员、测试人员、产品经理5.6.5 配置管理输入：配置管理方案及计划

15、活动： 配置管理员收到项目经理的配置管理方案和计划书后。对项目实施过程中所使用到的工具、系统、环境进行相关的配置； 当前涉及到相关的工具、系统、环境是: Sharepoint：根据配置方案进行项目建立、目录的建立及相关人员权限开通、设置； QC系统：根据配置方案进行项目建立、目录的建立及相关人员权限开通、设置； SVN：根据配置方案进行项目建立、目录的建立及相关人员权限开通、设置； 版本管理：根据配置方案对版本发布地址、版本命名、版本号进行建立和管理。 配置管理员对以上的配置进行管理和维护，并输出项目配置表。 输出：项目配置表负责人：配置管理员参与方：项目经理、开发人员、测试人员、运维人员5.

16、7 项目启动会议输入：项目计划、团队成员列表、风险评估和管理表、项目质量目标、项目配置表活动： 在项目启动准备工作就绪后，项目经理发起会议并召集项目组所有人员进行kick off会议； 会议主要讨论和明确内容如下:1 项目计划同步和确定2 项目组成员及职责的明确和确定3 对当前存在风险点进行同步和明确，并明确各风险点的负责人；4 对项目质量目标的明确和同步5 对项目配置方案的明确和同步 会议结束后，项目经理将以上5项讨论后的结论做最终整理，并将其相关文档提交到sharepoint上相应的文件目录下进行管理，以便项目组查询。 输出：项目计划、团队成员列表、风险评估和管理表、项目质量目标、项目配置

17、表负责人：项目经理参与方：开发人员、测试人员、运维人员5.8 编码实现及调试5.8.1 编码输入：项目计划、PRD文档、SRD文档、技术方案设计文档活动： 在项目启动会议结束后，开发在开始编码前，须建立并确定代码目录结构、文件命名规则； 代码格式须遵照Java代码编写规范书写； 每隔2-3天，应将代码入库一次； 代码入库前必须完成Code Review 准备进行Code Review前，应当更新本地代码到最新版本； 检查更新后的代码是否会导致Build Break； 如没有问题，生成patch，将patch发送给Reviewer； Reviewer检查完代码，确认没有问题后，方可入库； 入库代

18、码如果造成Build Break，须在当天解决，并且入库更新的代码 开发过程中的各种讨论（技术讨论、需求讨论、测试讨论等）原则上都需要有文档记录，可以通过SharePoint或者邮件来记录 对于Build Break、较严重或有代表性的Bug、重大设计错误等问题，需要进行Case Study，每一次Case Study都需要有独立的文档，并且保存在SharePoint中 开发过程中如有并行开发的情形（例如同时修改多个Bug，或者Bug修改和代码开发同步进行，或者多个分支同时开发等），应该在自己的开发机器上建立多个开发镜像，不应将代码混杂在一个工程中管理 在代码编写阶段，需要严格按照项目计划执行

19、，并确保代码质量。输出：代码负责人：开发人员参与方：项目经理 5.8.2 单元测试输入：项目计划、PRD文档、SRD文档、系统设计文档、产品代码活动： 在代码实现过程中，须保证在在一个迭代周期内完成单元测试（迭代周期视项目具体情况而定）； 在一个迭代周期结束前，入库的代码须包含相应的单元测试代码； 单元测试代码入库前原则上也必须进行Code Reviewer； 单元测试的最终结果是保证迭代周期内的代码测试通过，以确保入库代码的质量； 单元测试结束后，须输出相应的测试报告，测试报告原则上要求每项都是pass。输出：单元测试代码、单元测试报告负责人：开发人员参与方：项目经理5.8.3 联调输入：编

20、码完成、单元测试完成活动： 在编码及单元测试完成后，软件系统进入联调工作； 联调工作主要包含： 子系统间接口、功能联调 本系统与其它系统间的接口、功能联调 联调须确保各子系统间或相互调用的系统之间接口调通，正常流程的功能实现正常，以作为进入下阶段集成测试奠定良好的基础； 联调结束后，须输出联调报告（报告模板和格式可根据项目实际情况进行设计）。输出：联调报告负责人：开发人员参与方：项目经理5.8.4 集成测试输入：联调结束活动： 联调结束后，开发需进行集成测试； 集成测试的测试方案和测试标准由测试部门提供； 通过集成测试，须保证各系统及系统间相互调用的功能、正常流程是正常的； 集成测试后，须输出

21、集成测试报告（报告模板和格式可根据项目实际情况进行设计，重点是确保功能已实现且正常流程跑通）； 集成测试的结论将作为是否准入系统测试的判定标准之一，如果集成测试不通过，测试团队有权拒收提交的系统测试版本； 集成测试结束后，开发需将最新代码进行提交、入库。输出：集成测试报告负责人：开发人员参与方：项目经理、测试人员、配置管理员5.8.5 提交系统测试申请输入：集成测试报告活动： 集成测试通过后，开发人员将程序打包并提交到指定的服务器地址； 开发人员需填写系统测试申请单，申请单需经过相关人员签字后提交给测试部和配置管理员； 系统测试申请单须包含以下内容： 集成测试的结果 安装包的存放位置和地址 代

22、码的具体地址（包含SVN地址及SVN版本号）输出：系统测试申请单负责人：开发人员参与方：项目经理、测试人员、配置管理员5.8.6 系统测试版本输出输入：系统测试申请单活动： 配置管理人员从开发手上拿到系统测试申请单后，按照开发申请单上所描述的版本存放位置下载安装包，将版本备份到指定的服务器，并对版本进行统一管理； 同时配置管理员需要审核开发所提交的安装包的版本命名和版本号是否正确； 确保没问题后，将通知测试人员到指定的位置取安装包；输出：系统测试版本负责人：配置管理人员参与方：开发人员、项目经理、测试人员5.9 系统测试5.9.1 系统测试输入：系统测试版本、测试用例、测试方案活动： 测试负责

23、人按照测试计划对测试用例对任务进行分解到每位测试人员，并确保每条用例到具体负责人； 测试人员收到测试版本及测试任务后，进行测试工作； 测试人员的工作须按照测试计划进行，如出现与测试计划不符的，需及时提出，并跟项目经理进行沟通； 测试过程中发现的bug提交及具体操作，请参照QC文档执行； 测试过程中，如果碰到严重问题而造成正常测试无法进行的，须第一时间highlight出来给开发和项目经理，开发接到问题后需第一时间安排分析解决。问题得到修正后，开发需要重新走4.7.4到4.7.6版本提交申请、输出的流程； 测试负责人需要每天反馈测试进展，并输出每日测试报告； 一轮系统测试结束后，测试负责人需要发

24、布一轮系统测试总结报告；输出：每日测试报告、系统测试总结报告负责人：测试负责人参与方：开发人员、项目经理、测试人员5.9.2 测试报告评审输入：测试报告、bug list活动： 项目经理收到测试部发出的系统测试总结报告后，结合实际情况，发起测试报告评审的会议； 会议评审内容主要包含测试报告的内容及QC中的bug list； 测试报告评审的原则： 测试报告中是否已完成该涵盖的用例； 针对N/A的部分需要说明具体原因，并确认当前是否确实无法测试； Fail项是否都已提交到QC系统中进行管理 Bug List评审原则： 需要对每个bug的最新状态作确认； 逐一讨论bug，对每个bug需要分析其严重程

25、度、解决的优先级； 每个bug需要明确具体的负责人和解决时间点； 对一些bug暂时不需要解决的（如需求不明确或严重程度低的），可做“挂起”处理。但事后需要特别对“挂起”问题，重新进行分析、讨论，作为后期完善、优化的一部分内容； 针对“争议”类的bug需要项目组做特别讨论，并给出处理的结论； 其它关于bug的处理原则，具体详见QC文档执行。 根据评审完的报告和bug list，需要进一步明确下阶段版本更新、系统测试的时间点以及测试范围； 根据评审的结果，项目组确定版本是否可达到封板目的。输出：评审结论、会议记录负责人：项目经理参与方：开发人员、项目经理、测试人员5.9.3 开发debug输入：b

26、ug list活动： 开发人员需要主动查看分配给自己的Bug，并及时更新Bug状态； 当Bug修改完成提交修改代码时，需要说明以下事项： 在提交到SVN时，必须附带comment，并且在comment中说明相关Bug号； 同时修改Bug状态，在Bug中增加comment说明相关代码提交时的Revision。 针对Bug修改的代码提交时，原则上不允许以下情况： 一次提交代码中包含多个Bug修改； 一次提交代码中即包含Bug修改，又包含其他功能的开发代码 关于bug的处理原则，具体详见QC文档执行。输出：评审结论、会议记录负责人：项目经理参与方：开发人员、项目经理、测试人员5.10 性能测试输入：

27、测试版本、测试环境活动： 测试负责人按照测试计划对性能测试进行安排； 性能测试主要包含以下几方面： 客户端方面：对功耗、流量、内存占有率进行测试（具体测试内容视具体项目和测试方案而定）； 服务器方面：根据设定的相应使用指标进行测试（具体指标视不同项目实际情况和测试方案而定）； 测试结束后，须输出性能测试报告，并把报告发给项目经理、开发人员及相关负责人； 测试报告中，测试人员需要给出每项测试的结论；输出：性能测试报告负责人：性能测试负责人参与方：开发人员、项目经理、测试人员5.11 封板及代码冻结5.11.1 封板测试及封板输入：系统测试完成、性能测试完成活动： 测试负责人按照测试计划，完成系统

28、测试及性能测试的结果对产品进行最后一轮封板测试； 封板测试结束后，须输出封板测试报告； 根据封板测试报告，召集项目组进行讨论、评估，以确定版本是否可达到封板条件； 如果达到，测试负责人启动版本封板流程，并填写版本封板申请单，并提交申请单给开发人员、项目经理、配置管理员进行签字确认； 版本封板申请单所包含内容项，至少涵盖： 各相关负责人确认结果 封板测试的版本及版本号 对应代码的SVN地址和版本号 封板的结论和具体时间 最终将封板申请单提交给配置管理员，由配置管理员进行版本封存，对代码、版本进行冻结、封存管理。输出：封板测试报告负责人：测试负责人参与方：开发人员、项目经理、配置管理员5.11.2

29、 代码冻结输入：版本封板申请单活动： 配置管理员收到版本封板申请单后，根据申请单上对应的SVN地址和版本号对代码、版本进行冻结和封存，并对SVN上的代码打Tag，同时对Tag进行特别注释； 冻结完成后，配置人员需在版本封板申请单上填写代码冻结、版本封存的结论、时间、地址及相应的SVN版本号，并通知给项目的相关人员； 在代码冻结之后，原则上禁止任何代码的提交，如果确实需要提交，需要部门经理及配置管理员确认，以确定是否在原有基础上拉分支，方案确定后方可入库。输出：版本封板申请单负责人：配置管理员参与方：开发人员、项目经理、测试人员、开发经理5.12 生产环境部署、验证测试5.12.1 上线部署申请输入：版本封板及代码冻结活动： 上线前开发人员需要编写和准备系统部署文档和上线手册两份文档； 此两份文档需要提交给测试人员进行验证测试，验证通过后将文档提交给运维部门； 开发人员收到配置管理员最后的版本封板和代码冻结成功后，根据项目计划提交上线部署申请单；