项目管理体系

初稿2011.9.15规范化：项目各项工作的开展，定义和管理作到有据可依。比如版本的命名标准化，文档编辑模板化，测试通过一致化。避免工作的重复性，模糊性，无效性。流程化：各项工作的开展系统化，各项工作通过JIRA系统进行管理，控制和监督，并通过邮件系统进行通知。保证工作开展的有序性和针对性。避免不必要的工作流以流控的混乱。降低风险，提高质量：版本的规范化管理，工作上的流程化管理，进度上的阶段性监督管理，问题的及时化处理，使得产品降低风险，提高质量。降低成本，提高效率：通过标准流程化的监控，项目开展规范化操作，减少无效沟通，减少重复性工作，快速获取正确的信息和资料，降低单位工作时间的人力成本，提高工作效率。项目管理体系需求管理环境管理版本管理计划管理文档管理流程管理测试管理日常工作及会议管理绩效管理JIRA建立各种管理模块JIRA上提交各项管理文档项目经理审核视情况召开评审评审根据评审修订归档执行。说明：1.项目经理审核后，邮件自动通知。2.项目经理根据提交的内容决定是否评审。JIRA上提交版本或文档项目经理审核归档执行需要评审评审修订通过不通过背景目前我们项目开发中没有明确的需求，在开发和测试过程中容易出现以下情况：1.没有针对性，尤其是测试，在没有用例和方案的时候，类似于随机测试和验收测试。2.没有标准性，没有需求说明的一些关键指标和数据依据，质量无法把握。3.导致所有人重复工作量，部分功能或者设计不能在需求阶段确定，将会影响整个流程上的所有人的工作量和工作效率。为避免需求阶段对后面流程上的影响，提出一下建议和规范：1.开发人员在接到任务时整理出一个初步需求。2.在每次新的开发任务执行前，由本次开发人员对测试人员进行一个培训或讲解。测试人员对需求讲解进行提问。（由设计到该模块的开发人员，项目经理，测试人员参与）3.测试人员根据讲解和最终确认结果对需求进行修订，进入准备测试方案和用例阶段。4.需求变更，需要及时更新并命名为文档名+日期，通过JIRA系统通知相关人员，项目经理根据需求决定是否再次评审。背景目前项目中对于版本的管理还是比较空白的，流程上，命名规范，查询接口等方面都没有很好控制。主要如下问题;1.命名没有规范化。没有区分开发版本，测试版本，还是发布版本，补丁版本，迭代版本。导致无效的反复操作增加。2.没有查询接口。终端设备无法通过工具或者软件界面直接查看系统里面版本。3.版本的发布没有走正规的审批流程。4.不能非常明确知道和记录版本出现问题，不能有效统计每个版本稳定性。5.版本没有基线化管理，不能很好的归档。6.服务器版本和客户端版本没有紧密对应起来。为对版本进行规范化管理以及流程上更好监控，提出以下建议和规范：一、版本命名规则版本类型：1.主版本号和子版本号。2.服务器版本和客户端版本。3.阶段性版本。4.发布版本。5.补丁版本。1.主版本和子版本命名主版本为：产品名称+1.0如：云码头IcloudI_1.0云码头IIcloudII_1.0子版本在主版本的基础上递增。子版本的产生可以以一个迭代或者一个时间段作为周期云码头I:cloudI_1.0,cloudI_1.1,cloudI_1.2…云码头II:cloudII_1.0,cloudII_1.1,cloudII_1.2…2.服务器版本和客户端版本。服务器和客户端版本号可以在主版本或者子版本号前面加上标识。如：s_cloudI_1.0,c_cloudII_1.0.原则希望每次发布版本客户端版本和服务器版本一一对应起来。如：如云码头II第二次迭代版本。服务器版本：s_cloudII_1.1,客户端版本:c_cloudII_1.1.3.阶段性版本命名规则在同一开发周期内或者迭代周期内，出现需要进行一些小的改动，时间周期比较短。如：s_cloudII_1.2_201109204.发布版本命名规则子版本测试，评估完成最终版本。（基线化）如：s_cloudIII_1.1_release5.补丁版本命名规则对于售后产品需要升级的产品且可以直接通过补丁形式安装的。针对于发布后的版本如：c_cloudII_1.2_update二、版本存放规则版本的存放通过JIRA系统或者SVN管理工具进行存放管理一级目录为产品名称，如：cloudI,cloudII,cloudII.二级目录为版本名称，如：cloudI_1.0,cloudI_1.1,cloudI_1.2_release,cloudI_1.3_update三级目录为服务器和客户端目录，包含各种环境安装文档。如：s_cloudII_1.1,c_cloudII_1.1三、版本变更版本变更可以按照原定计划迭代进行，也可以根据修复的BUG之后变更，但需要一个流程上和周期性的控制1.版本变更需要提供变更原因，由于软件重新开发，新功能增加，BUG修复。2.版本变更需要要提供变更列表。3.版本变更需要周期性控制和经过审核，不能随意变更版本，需要评估变更时间，特殊情况，需要备注。四、版本的提交与审核。1.版本的提交走测试申请流程。2.确认版本的命名规范。3.确认版本，安装文件，配置文件等各种资料齐全。4.确认安装文件，配置文件等各种资料为最新状态。背景环境管理，包括硬件环境，软件环境，设备环境，IP及虚拟机资源，系统资源，测试或演示文档等。目前我们的环境存在以下问题：1.开发，测试，演示环境在一起，相互影响。2.测试环境，尤其是后台不能自行维护，每次需要等待开发配置，影响开发，等待浪费时间。3.IP地址和虚拟机没有一个相对固定的地址。4.设备的状态（比如版本），不良品没有分类和注明。5.各个版本的良品系统没有备份，维修时，找不到良品系统。6.演示材料没有事先准备，演示效果有一定影响。建议和规范1.将开发环境，测试环境和演示环境分别单独管理。2.开发提供服务器、客户端环境安装及验证方法，安装过程尽力简单化，能让测试快速安装，能实现脚本安装最好。3.IP地址（虚拟机）和产品及数据库对应固定化，没有特殊情况，尽可能不改变。4.产品需要专门的存储柜进行管理，产品需要实时更新和标注版本及状态。5.对于基线化的版本的系统需要专门的备份，为产品维修提供标准版本。6.针对演示时需要更好的效果，比如视频效果，收集换面清晰，流畅。声音效果好的素材作为演示材料。目的：为了合理利用资源，分配任务，把握项目整体进度，降低项目风险对项目实施进行一个科学的安排和部署。优势：1.目标针对性，项目计划明确了需要完成的各项功能和性能要求，以及人员分配。2.工作有序性，项目计划对项目任务进行阶段性的划分，明确了每个周期内各个人员的具体工作，使工作有序开展。3.进度监控，根据项目计划安排与实际工作反馈对比，可以监控每项工作的完成进度，及时做出调整。4.工作协调配合，开发和测试人员可以根据项目计划对各自工作同时进行安排及相互沟通。项目计划内容项目计划建议采用EXCEL模版进行设计，简单明了，主要内容包括：1.项目目标和范围描述进行项目的背景和意义，项目的基本框架，项目实现的主要功能和指标。（详细功能清单）2.项目进度计划说明项目划分几个阶段完成，每个阶段开发和测试各项工作的开展顺序，开展时间，完成时间3.项目资源准备环境，设备，人员4.项目风险评估对项目可能存在的风险进行说明。（详细见模版）文档管理主要对各种工具，文件，资料进行一个分类备份以及共享，方面查找资料和学习提高。文档管理和分类文档管理项目资料培训资料学习资料开发测试码头I码头II码头III需求，方案，计划，工具等码头I码头II码头III需求，方案，计划，工具等测试概述一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→发布申请.输入条件软件需求文档、软件规格书以及开发人员的概要设计文档内容：测试环境和资源需求分析功能需求分析，包括1.硬件及接口定义分析2.用户使用界面分析3.系统支持软件分析4.通讯协议分析5.可靠性，稳定性分析6.用户场景分析输出开发：详细设计文档测试：测试思维导向图.输入条件需求文档，详细设计，测试计划模版内容1.测试背景2.通过标准3.测试输入项目4.测试资源5.测试策略6.日程安排7.风险分析输出：测试计划书输入需求文档，详细设计，测试思维导向图，测试计划内容1.硬件及接口2.用户界面3.应用软件4.自带软件5.协议测试6.可靠性，稳定性测试7.案例评审输出基本测试用例，用户场景用例，修订后的案例。输入安装软件及文档（包括客户端及服务器），配置文档，烧录系统及工具，IP分配内容搭建测试环境，用户演示环境测试安装文档，记录安装过程问题准备测试需要的工具，资料。安装逐步实行脚本化。输出安装脚本，安装过程反馈表输入基本测试用例，场景设计用例内容1.确保执行环境的正确性2.按优先级顺序执行用例。3.检查用例执行条件4.记录每个用例的执行结果，通过，不通过，锁定。5.对测试不通过的，详细记录问题重现的路径，现象，以及日志等相关内容。6.与开发确认BUG，并在系统上及时提交反馈。7.考虑测试的覆盖率，测试过程中思考是否需要补充测试用例，是否需要增加用户场景。8.统计BUG缺陷率，（BUG总数，致命的，严重的，一般的，建议的。）及用例执行结果。总的用例数，未执行的，通过的，未通过，锁定的，BUG数）9.对于需要回归测试，统计回归不过的问题。输出测试用例执行反馈表，BUG统计表输入BUG统计表内容1.与开发确认BUG，有争议的反馈PM2.编写BUG的情况，类型，紧急情况，问题描述和详细步骤，期望结果。3.提交BUG，指定任务分派。输出BUG系统跟踪输入测试用例执行反馈表，BUG统计表内容1.测试评价：总体评价，新功能情况小结，重点BUG列表，bugfix情况，稳定性测试，2.开发改进点3.测试改进点4.风险点5.测试数据：回归数据反馈，新增BUG统计，用例执行情况统计。6.测试资源输出测试报告常见的测试相关流程主要有以下几种：1.测试案例评审流程2.测试计划评审流程3.测试申请流程4.测试执行流程5.内测试反馈流程6.客户BUG反馈流程7.BUG处理流程8.测试报告提交流程测试人员准备测试用例发起评审项目经理查阅测试用例邮件通知相关人员进行用例评审根据评审结果修订用例用例归档测试人员编制好测试计划发起评审项目经理查阅测试计划无需评审召开评审需要测试计划修订归档研发自测完毕，提交测试申请项目经理检查软件，文档是否齐全，规范否测试人员检查软件，文档是否齐全，规范否是执行测试测试人员按照测试用例执行测试发现BUG并提交开发人员确认BUG否打回确认关闭存在争议项目经理评审确认是是关闭处理否提单跟踪测试人员提供反馈模版和验证需求测试人员收集并确认内测问题抛弃否提单跟踪是开发人员确认BUG否打回确认关闭存在争议项目经理评审确认是是关闭处理否提单跟踪客户反馈BUG测试人员确认内测问题抛弃否提单跟踪是开发人员确认BUG否打回确认关闭存在争议项目经理评审确认是是关闭处理否提单跟踪项目经理分派任务或者测试指派BUG处理开发确认BUG开发修复BUG提交修复版本给项目经理确认项目经理确认并分派测试任务测试人员验证BUG是否通过否关闭是测试人员整理并提交测试报告项目经理查阅审核，评估是否需要评审评审讨论是问题跟踪，文档归档否日常工作管理包括1.日报管理2.周报管理3.月度总结会议管理包括1.非正式会议，比如站立会议2.正式会议，评审会议，研讨会，总结会议。3.正式会议需要规范的会议记录。测试绩效KPI的管理可以从一下几方