项目管理流程适用于服务器开发评审版.docx
《项目管理流程适用于服务器开发评审版.docx》由会员分享，可在线阅读，更多相关《项目管理流程适用于服务器开发评审版.docx（21页珍藏版）》请在冰豆网上搜索。
项目管理流程适用于服务器开发评审版
项目管理流程
（适用于server开发）
版本号：
1.0
目录：
1.概述
本文档旨在通过建立规范化标准化的项目管理流程并且不断地改进、优化，达到提高工作效率，标准化项目管理，提高软件质量，优化资源配置，减小风险事件等不良影响，降低沟通成本的目的。
进而，为公司拓展业务、扩大规模、持续发展，扫除阻碍、铺平道路。
2.适用范围
本流程适用于北京无限立通基础平台服务器开发的项目管理使用
3.术语和缩略语
下列术语和缩略语只适用于本规范：
3.1术语
术语
说明
输入
每项任务开始时的前提条件
活动
每项任务的具体工作内容分解
输出
每项任务经过活动后得出的结果，原则上要求所有的输出内容需要保存、备份。
负责人
指当前任务项的主要负责人
参与方
指当前任务项的配合、辅助人员
3.2缩略语
缩略语
英文全称
中文含义
MRD
MarketRequirementDocument
市场需求文档
PRD
ProductRequirementDocument
产品需求文档
SRD
SoftwareRequirementDocument
软件需求文档
4.项目管理总流程图
以下是无限立通项目管理总流程图（本流程适用于服务端的开发）
5.项目管理规范和流程
5.1产品需求文档（PRD）生成
输入：
移动规范、业务部提出需求、开发自行新需求
活动：
☆产品经理结合移动规范、业务部提出的新需求或开发自行提出的新需求，对产品进行整体规划；
☆产品经理根据产品规划，编写和制定《产品需求文档》；
☆产品需求文档输出后，产品经理须召集项目经理、开发人员、测试人员对产品的具体需求进行分析、同步及讨论；
☆针对产品需求中的实现功能点，如果评估有涉及到技术难点或风险点的，需要做前期的技术调研工作。
输出：
《产品需求文档》
负责人：
产品经理
参与方：
项目经理、开发人员、测试人员
5.2技术调研
输入：
产品文档
活动：
☆针对产品设计讨论过程中所提出的技术性风险、难题进行前期技术调研，技术调研都要有一定的深度，评测结果要真实可信，其他来源的数据仅能作为参考，要以自己的测试结果为主要依据；
☆调研工作结束后，必须编写《技术调研报告》，报告中要有对被调研技术的分析和建议结论；
☆《技术调研报告》完成后，需要与相关人员共同评估被调研技术，评估完成后，针对该技术的调研工作完成；
☆如果在调研过程中有涉及到相关的代码和demo，需要在《技术调研报告》中体现，并说明具体放置的路径。
输出：
《技术调研报告》、代码、Demo
负责人：
开发人员
参与方：
产品经理、项目经理
5.3软件需求文档（SRD）编写
5.3.1软件需求文档（SRD）编写
输入：
产品需求文档
活动：
☆项目经理根据产品经理提供的PRD文档，将PRD文档转化为软件需求文档；
☆SRD文档主要内容包含：
★项目名称
★术语解释
★功能需求描述
★性能需求描述
★安全及可扩张性需求
★所参考的协议和规范（包含内部协议和外部协议）
★接口要求
★软硬件需求
★产品质量要求
★项目大致计划等
☆具体格式可参见《软件需求文档》模板
输出：
《软件需求文档》
负责人：
项目经理
参与方：
产品经理、开发人员、测试人员
5.3.2SRD文档评审
输入：
SRD文档
活动：
☆项目经理编写好SRD文档后，召集产品经理、开发人员、测试人员进行讨论、评审，并输出评审报告及修正后的SRD文档。
输出：
评审报告，修正后的SRD文档
负责人：
项目经理
参与方：
产品经理、开发人员、测试人员
5.4项目预立项
输入：
SRD文档
活动：
☆项目经理根据最终确定的SRD文档对项目进行预立项，对后面的工作进行安排和规划；
☆预立项工作主要是针对接下来的“项目整体方案设计”阶段进行规划和计划安排；
☆项目整体方案设计主要涵盖以下四大部分：
★技术方案的设计（包含概要设计及详细设计）
★UI/UE的设计
★测试方案及测试用例的设计
★配置方案及计划的设计
输出：
项目计划
负责人：
项目经理
参与方：
产品经理、开发人员、测试人员、配置管理员
5.5项目整体方案设计
5.5.1技术方案设计
5.5.1.1概要设计文档编写及评审
输入：
PRD文档、SRD文档、项目计划
活动：
☆在SRD完成后，需要开发人员对SRD、PRD进行系统分析工作；
☆必要时需要进行额外的技术调研，技术调研的流程仍参照5.2步骤进行；
☆初步系统分析完成后，需要编写《概要设计文档》；
☆概要设计文档至少包含内容：
★系统架构
★系统各模块的分解及功能说明
☆针对《概要设计文档》进行评审，评审通过后初步系统分析完成
☆具体格式可参见《概要设计文档》模板
输出：
《概要设计文档》、评审报告
负责人：
技术负责人
参与方：
开发人员、项目经理、技术总监、测试人员
5.5.1.2详细设计文档编写与评审
输入：
SRD文档、《概要设计文档》、项目计划
活动：
☆开发人员根据SRD和《概要设计文档》，进行系统模块的划分和分解；
☆分模块进行系统分析，各个模块的系统分析完成后，需要编写《详细设计文档》；
☆各子系统间的交互需要编写《系统内部接口文档》；
☆如本系统与其他系统有交互，需要编写《系统接口文档》；
☆针对《详细设计文档》、《系统内部接口文档》和《系统接口文档》须召集项目经理、产品经理、开发人员、测试人员进行评审；
☆具体格式可参见《详细设计文档》、《系统内部接口文档》和《系统接口文档》模板。
输出：
《详细设计文档》、《系统内部接口文档》、《系统接口文档》、评审报告
负责人：
开发人员
参与方：
项目经理、技术总监、测试人员
5.5.2测试方案及用例设计
5.5.2.1测试方案设计及评审
输入：
PRD文档、SRD文档、《概要设计文档》、《详细设计文档》、《系统内部接口文档》和《系统接口文档》
活动：
☆测试人员根据产品文档、需求文档及技术文档进行测试方案的编写；
☆测试方案包含：
功能测试、性能测试、白盒测试；
☆测试方案编写完成后，需要组织相关人员进行评审，并输出评审报告；
☆测试方案评审后，测试、开发需双方达到确认。
输出：
《测试方案》、测试方案评审报告
负责人：
测试人员
参与方：
开发人员、项目经理、产品经理
5.5.2.2测试用例设计及评审
输入：
测试方案、PRD文档、SRD文档
活动：
☆测试人员根据测试方案、产品文档及SRD文档进行测试用例的编写和分解；
☆测试用例包含：
功能测试、性能测试、白盒测试；
☆测试用例编写完成后，需要组织相关人员进行评审，并输出评审报告；
☆测试用例评审后，测试、开发需双方达到确认。
输出：
《测试用例》
负责人：
测试人员
参与方：
开发人员、项目经理、产品经理
5.5.3UI/UE设计（针对有界面展现的产品）
输入：
PRD文档、SRD文档、项目计划
活动：
☆产品经理根据SRD文档、PRD文档对产品的UI/UE进行设计；
☆设计结束后，须召集项目经理、开发人员、测试人员进行评审。
输出：
UI/UE设计文档
负责人：
产品经理
参与方：
开发人员、项目经理、测试人员
5.5.4配置管理方案及计划设计
输入：
SRD文档、PRD文档、项目计划
活动：
☆项目经理根据SRD文档对项目的配置管理方案及计划进行设计；
☆配置管理方案主要涵盖以下内容：
★项目名:
（供内部使用）
★发布版本命名及版本号：
（每次版本发布时的版本命名及版本号控制，包含从输出给测试部系统测试起一直到正式版本的发布。
）
★Sharepoint：
（项目文件目录的规划和设计）
★SVN：
（目录的规划和设计）
★QC系统：
（目录的规划和设计）
★资源配置
1人力资源
2设备资源
3其它无形资源（如开发环境软件、工具类等）
☆配置管理方案和计划设计结束后，须召集开发人员、测试人员、配置管理员进行讨论及信息同步；
☆最后输出《配置管理方案和计划》，并同步给配置管理员作为后续项目配置管理的依据。
输出：
《配置管理方案和计划》
负责人：
项目经理
参与方：
开发人员、测试人员、配置管理员、运维人员
5.6项目正式启动准备
5.6.1项目计划制定
输入：
PRD文档、SRD文档、整体方案设计
活动：
☆项目经理召集技术负责人进行计划预估及制定；
☆技术负责人须配合项目经理进行任务的分解和评估，同时对开发时间进行评估（技术负责人在预估时间时可找相应要参与的直接工程师进行共同预估时间点，以确保给出的时间尽量准确）；
☆评估的时间粒度原则上能让项目经理可有效的进行跟踪任务进展，具体的粒度由项目经理根据项目实际情况进行把握（按照国内的项目管理惯例，一般情况下，最小粒度希望能细到1天。
）
☆项目计划所包含的维度须涵盖：
★服务器端开发
★客户端开发
★单元测试
★联调
★集成测试
★系统测试
★性能测试
★封板发布等
☆项目经理根据开发、测试评估的计划，整理出整个项目计划；
输出：
项目计划
负责人：
项目经理
参与方：
开发人员、测试人员、运维人员、配置管理员
5.6.2项目组成员列表
输入：
项目计划
活动：
☆项目经理根据项目计划中的人力资源，对所有项目组人员建立一份成员列表；
☆需明确每位项目组成员的职责；
☆如果有涉及到客户或第三方，也需要将其项目的负责人进行建立，以便保持后续联系；
☆项目成员列表至少包含姓名、职责、电话、邮件等联系方式。
输出：
项目成员列表
负责人：
项目经理
参与方：
开发人员、测试人员、运维人员、合作伙伴、配置管理员
5.6.3风险评估及管理
输入：
项目计划、PRD文档、SRD文档、项目整体方案设计
活动：
☆项目经理需组织项目组成员对项目的风险进行识别和评估；
☆项目风险主要包含技术风险、资源风险等；
☆根据识别出的风险，项目组需要对其严重程度及影响面进行评估，以综合评估风险的影响程度；
☆针对识别出来的风险，需要项目组共同讨论预防措施及应对措施，以防问题发生，将风险降到最低点；
☆项目经理根据识别出的风险点及讨论后的预防措施，进行管理，并跟进预防措施的落实情况，并定期更新和维护风险管理表。
输出：
风险评估和管理表
负责人：
项目经理
参与方：
开发人员、测试人员、运维人员
5.6.4项目质量目标的设计和制定
输入：
SRD文档、项目计划
活动：
☆项目经理根据SRD文档和项目计划对项目在实施过程中的每个milestone，产品所要完成的功能及达到的质量目标进行设计和制定；
☆项目质量目标需要分解到每个大的里程碑；
☆质量目标和测试用例需要同开发人员进行讨论、同步；
☆项目质量目标主要涵盖内容如下：
★功能完成度
★性能达到的要求
★本阶段的输入及输出
★本阶段质量所要达到的最终目的
★评判标准
★评判人员
输出：
项目质量目标
负责人：
项目经理
参与方：
开发人员、测试人员、产品经理
5.6.5配置管理
输入：
配置管理方案及计划
活动：
☆配置管理员收到项目经理的配置管理方案和计划书后。
对项目实施过程中所使用到的工具、系统、环境进行相关的配置；
☆当前涉及到相关的工具、系统、环境是:
★Sharepoint：
根据配置方案进行项目建立、目录的建立及相关人员权限开通、设置；
★QC系统：
根据配置方案进行项目建立、目录的建立及相关人员权限开通、设置；
★SVN：
根据配置方案进行项目建立、目录的建立及相关人员权限开通、设置；
★版本管理：
根据配置方案对版本发布地址、版本命名、版本号进行建立和管理。
☆配置管理员对以上的配置进行管理和维护，并输出项目配置表。
输出：
项目配置表
负责人：
配置管理员
参与方：
项目经理、开发人员、测试人员、运维人员
5.7项目启动会议
输入：
项目计划、团队成员列表、风险评估和管理表、项目质量目标、项目配置表
活动：
☆在项目启动准备工作就绪后，项目经理发起会议并召集项目组所有人员进行kickoff会议；
☆会议主要讨论和明确内容如下:
1项目计划同步和确定
2项目组成员及职责的明确和确定
3对当前存在风险点进行同步和明确，并明确各风险点的负责人；
4对项目质量目标的明确和同步
5对项目配置方案的明确和同步
☆会议结束后，项目经理将以上5项讨论后的结论做最终整理，并将其相关文档提交到sharepoint上相应的文件目录下进行管理，以便项目组查询。
输出：
项目计划、团队成员列表、风险评估和管理表、项目质量目标、项目配置表
负责人：
项目经理
参与方：
开发人员、测试人员、运维人员
5.8编码实现及调试
5.8.1编码
输入：
项目计划、PRD文档、SRD文档、技术方案设计文档
活动：
☆在项目启动会议结束后，开发在开始编码前，须建立并确定代码目录结构、文件命名规则；
☆代码格式须遵照《Java代码编写规范》书写；
☆每隔2-3天，应将代码入库一次；
☆代码入库前必须完成CodeReview
★准备进行CodeReview前，应当更新本地代码到最新版本；
★检查更新后的代码是否会导致BuildBreak；
★如没有问题，生成patch，将patch发送给Reviewer；
★Reviewer检查完代码，确认没有问题后，方可入库；
★入库代码如果造成BuildBreak，须在当天解决，并且入库更新的代码
☆开发过程中的各种讨论（技术讨论、需求讨论、测试讨论等）原则上都需要有文档记录，可以通过SharePoint或者邮件来记录
☆对于BuildBreak、较严重或有代表性的Bug、重大设计错误等问题，需要进行CaseStudy，每一次CaseStudy都需要有独立的文档，并且保存在SharePoint中
☆开发过程中如有并行开发的情形（例如同时修改多个Bug，或者Bug修改和代码开发同步进行，或者多个分支同时开发等），应该在自己的开发机器上建立多个开发镜像，不应将代码混杂在一个工程中管理
☆在代码编写阶段，需要严格按照项目计划执行，并确保代码质量。
输出：
代码
负责人：
开发人员
参与方：
项目经理
5.8.2单元测试
输入：
项目计划、PRD文档、SRD文档、系统设计文档、产品代码
活动：
☆在代码实现过程中，须保证在在一个迭代周期内完成单元测试（迭代周期视项目具体情况而定）；
☆在一个迭代周期结束前，入库的代码须包含相应的单元测试代码；
☆单元测试代码入库前原则上也必须进行CodeReviewer；
☆单元测试的最终结果是保证迭代周期内的代码测试通过，以确保入库代码的质量；
☆单元测试结束后，须输出相应的测试报告，测试报告原则上要求每项都是pass。
输出：
单元测试代码、单元测试报告
负责人：
开发人员
参与方：
项目经理
5.8.3联调
输入：
编码完成、单元测试完成
活动：
☆在编码及单元测试完成后，软件系统进入联调工作；
☆联调工作主要包含：
★子系统间接口、功能联调
★本系统与其它系统间的接口、功能联调
☆联调须确保各子系统间或相互调用的系统之间接口调通，正常流程的功能实现正常，以作为进入下阶段集成测试奠定良好的基础；
☆联调结束后，须输出联调报告（报告模板和格式可根据项目实际情况进行设计）。
输出：
联调报告
负责人：
开发人员
参与方：
项目经理
5.8.4集成测试
输入：
联调结束
活动：
☆联调结束后，开发需进行集成测试；
☆集成测试的测试方案和测试标准由测试部门提供；
☆通过集成测试，须保证各系统及系统间相互调用的功能、正常流程是正常的；
☆集成测试后，须输出集成测试报告（报告模板和格式可根据项目实际情况进行设计，重点是确保功能已实现且正常流程跑通）；
☆集成测试的结论将作为是否准入系统测试的判定标准之一，如果集成测试不通过，测试团队有权拒收提交的系统测试版本；
☆集成测试结束后，开发需将最新代码进行提交、入库。
输出：
集成测试报告
负责人：
开发人员
参与方：
项目经理、测试人员、配置管理员
5.8.5提交系统测试申请
输入：
集成测试报告
活动：
☆集成测试通过后，开发人员将程序打包并提交到指定的服务器地址；
☆开发人员需填写《系统测试申请单》，申请单需经过相关人员签字后提交给测试部和配置管理员；
☆系统测试申请单须包含以下内容：
★集成测试的结果
★安装包的存放位置和地址
★代码的具体地址（包含SVN地址及SVN版本号）
输出：
《系统测试申请单》
负责人：
开发人员
参与方：
项目经理、测试人员、配置管理员
5.8.6系统测试版本输出
输入：
系统测试申请单
活动：
☆配置管理人员从开发手上拿到系统测试申请单后，按照开发申请单上所描述的版本存放位置下载安装包，将版本备份到指定的服务器，并对版本进行统一管理；
☆同时配置管理员需要审核开发所提交的安装包的版本命名和版本号是否正确；
☆确保没问题后，将通知测试人员到指定的位置取安装包；
输出：
系统测试版本
负责人：
配置管理人员
参与方：
开发人员、项目经理、测试人员
5.9系统测试
5.9.1系统测试
输入：
系统测试版本、测试用例、测试方案
活动：
☆测试负责人按照测试计划对测试用例对任务进行分解到每位测试人员，并确保每条用例到具体负责人；
☆测试人员收到测试版本及测试任务后，进行测试工作；
☆测试人员的工作须按照测试计划进行，如出现与测试计划不符的，需及时提出，并跟项目经理进行沟通；
☆测试过程中发现的bug提交及具体操作，请参照QC文档执行；
☆测试过程中，如果碰到严重问题而造成正常测试无法进行的，须第一时间highlight出来给开发和项目经理，开发接到问题后需第一时间安排分析解决。
问题得到修正后，开发需要重新走4.7.4到4.7.6版本提交申请、输出的流程；
☆测试负责人需要每天反馈测试进展，并输出《每日测试报告》；
☆一轮系统测试结束后，测试负责人需要发布一轮《系统测试总结报告》；
输出：
《每日测试报告》、《系统测试总结报告》
负责人：
测试负责人
参与方：
开发人员、项目经理、测试人员
5.9.2测试报告评审
输入：
测试报告、buglist
活动：
☆项目经理收到测试部发出的系统测试总结报告后，结合实际情况，发起测试报告评审的会议；
☆会议评审内容主要包含测试报告的内容及QC中的buglist；
☆测试报告评审的原则：
★测试报告中是否已完成该涵盖的用例；
★针对N/A的部分需要说明具体原因，并确认当前是否确实无法测试；
★Fail项是否都已提交到QC系统中进行管理
☆BugList评审原则：
★需要对每个bug的最新状态作确认；
★逐一讨论bug，对每个bug需要分析其严重程度、解决的优先级；
★每个bug需要明确具体的负责人和解决时间点；
★对一些bug暂时不需要解决的（如需求不明确或严重程度低的），可做“挂起”处理。
但事后需要特别对“挂起”问题，重新进行分析、讨论，作为后期完善、优化的一部分内容；
★针对“争议”类的bug需要项目组做特别讨论，并给出处理的结论；
★其它关于bug的处理原则，具体详见QC文档执行。
☆根据评审完的报告和buglist，需要进一步明确下阶段版本更新、系统测试的时间点以及测试范围；
☆根据评审的结果，项目组确定版本是否可达到封板目的。
输出：
评审结论、会议记录
负责人：
项目经理
参与方：
开发人员、项目经理、测试人员
5.9.3开发debug
输入：
buglist
活动：
☆开发人员需要主动查看分配给自己的Bug，并及时更新Bug状态；
☆当Bug修改完成提交修改代码时，需要说明以下事项：
★在提交到SVN时，必须附带comment，并且在comment中说明相关Bug号；
★同时修改Bug状态，在Bug中增加comment说明相关代码提交时的Revision。
☆针对Bug修改的代码提交时，原则上不允许以下情况：
★一次提交代码中包含多个Bug修改；
★一次提交代码中即包含Bug修改，又包含其他功能的开发代码
☆关于bug的处理原则，具体详见QC文档执行。
输出：
评审结论、会议记录
负责人：
项目经理
参与方：
开发人员、项目经理、测试人员
5.10性能测试
输入：
测试版本、测试环境
活动：
☆测试负责人按照测试计划对性能测试进行安排；
☆性能测试主要包含以下几方面：
★客户端方面：
对功耗、流量、内存占有率进行测试（具体测试内容视具体项目和测试方案而定）；
★服务器方面：
根据设定的相应使用指标进行测试（具体指标视不同项目实际情况和测试方案而定）；
☆测试结束后，须输出性能测试报告，并把报告发给项目经理、开发人员及相关负责人；
☆测试报告中，测试人员需要给出每项测试的结论；
输出：
性能测试报告
负责人：
性能测试负责人
参与方：
开发人员、项目经理、测试人员
5.11封板及代码冻结
5.11.1封板测试及封板
输入：
系统测试完成、性能测试完成
活动：
☆测试负责人按照测试计划，完成系统测试及性能测试的结果对产品进行最后一轮封板测试；
☆封板测试结束后，须输出封板测试报告；
☆根据封板测试报告，召集项目组进行讨论、评估，以确定版本是否可达到封板条件；
☆如果达到，测试负责人启动版本封板流程，并填写《版本封板申请单》，并提交申请单给开发人员、项目经理、配置管理员进行签字确认；
☆版本封板申请单所包含内容项，至少涵盖：
★各相关负责人确认结果
★封板测试的版本及版本号
★对应代码的SVN地址和版本号
★封板的结论和具体时间
☆最终将封板申请单提交给配置管理员，由配置管理员进行版本封存，对代码、版本进行冻结、封存管理。
输出：
封板测试报告
负责人：
测试负责人
参与方：
开发人员、项目经理、配置管理员
5.11.2代码冻结
输入：
版本封板申请单
活动：
☆配置管理员收到版本封板申请单后，根据申请单上对应的SVN地址和版本号对代码、版本进行冻结和封存，并对SVN上的代码打Tag，同时对Tag进行特别注释；
☆冻结完成后，配置人员需在《版本封板申请单》上填写代码冻结、版本封存的结论、时间、地址及相应的SVN版本号，并通知给项目的相关人员；
☆在代码冻结之后，原则上禁止任何代码的提交，如果确实需要提交，需要部门经理及配置管理员确认，以确定是否在原有基础上拉分支，方案确定后方可入库。
输出：
版本封板申请单
负责人：
配置管理员
参与方：
开发人员、项目经理、测试人员、开发经理
5.12生产环境部署、验证测试
5.12.1上线部署申请
输入：
版本封板及代码冻结
活动：
☆上线前开发人员需要编写和准备《系统部署文档》和《上线手册》两份文档；
☆此两份文档需要提交给测试人员进行验证测试，验证通过后将文档提交给运维部门；
☆开发人员收到配置管理员最后的版本封板和代码冻结成功后，根据项目计划提交《上线部署申请单》；
升级会员 