开发流程过程改进建议.doc

文档号：pj001 版本号：0.1 日 期：2012-06－12 开发流程 过程改进建议  九樱天下（北京）信息技术有限公司 。 修订历史记录 版本 日 期 描 述 修订人 张二明 目 录 1 概述 3 1.1 目前遇到的问题 3 1.2 过程改进基础 4 2 过程改进建议 5 2.1 流程化说明 5 2.2 变更管理 7 2.3 BUG审核 7 3 开发注意事项 8 3.1 团队基本规则 8 3.2 不能自己引用第三方包 8 3.3 要注意区分使用单表和服务 8 3.4 特定代码管理规则 8 3.5 分支版本的应用 9 3.6 对前台文件命名规定 9 3.7 数据库设计规范 9 3.8 与第三方技术支持规范 10 概述 在经历了商城轻量化改造、专卖店轻量化改造、会员后台轻量化改造以及包括修改BUG在内的其他一系列项目型工作后，我对目前的开发环境及组织过程有了完整的认识，为了更好的完成以后的工作，结合我们组的工作经验及建议，我对开发流程提出过程改进建议。 首先，对项目有一个全面的认识，项目是为创造独特的产品、服务或成果而进行的临时性工作。这是对项目的定义，在我们的工作中，分配下来的任务都可以视为项目，商城轻量化改造是项目，新增智囊团功能是项目，修改一版BUG也是项目（修改BUG是最简单的项目，因为目标明确、范围界定准确）。项目不分大小，都需要进行规划，都需要标准化的管理，这也是我提出过程改进建议的初衷。 项目的特点有三个：独特性、临时性和不确定性。独特性指每一个项目都是独特的，没有两个项目是相同的，有可能当前项目中某一块具体功能在以前的项目中有重复，这也只能说在项目实现时有一些经验借鉴。临时性指项目要有明确的起点和终点，即项目的时间约束条件，这是项目的重要制约因素，项目必须承诺在指定的时间内完成，而不是随着工作的完成而项目结束，这一点我们的认识不够深刻。项目的不确定性有两点，一是指项目在整个生命周期中会因环境变化、风险移动等因素而产生变化，这类变化成为变更；而是指由于项目的独特性而产生的项目结果认识不完整，这一点常常被忽视，我们在实际开发中，总是希望先把项目设计的足够完整足够详细足够全面，而实际上对绝大多数项目说这是不现实的，对项目的认识就像认识海上的冰山一样，项目经理必须全面认识水上部分，同时预测水下部分，并随着冰山的上浮不断重新认识重新预测，这就是规划项目的常用技术—渐进明细（指在项目进程中，随着信息越来越详细，估算越来越准确，持续改进和细化计划）。 基于以上的认识，得出的结论是：一次性完成项目的成本最低。把我们分派的工作视为项目，项目就要规划、评审、设计、实现，而不是直接上来就编代码。对于规模较大的项目（如商城轻量化改造），我们容易接受这个观点；对于规模小的项目（如添加媒体审核功能），很多时候我们不愿意接受这个观点，而导致多次返工。修改BUG工作，我认为是最简单的项目，因为目标明确，这类项目可以根据具体BUG内容进行适当剪裁。所谓一次性完成，主要指不要让我们的项目因缺少规划、着急开始、认识不全面等原因而导致的多次返工，同时还要认识到，规划、评审、设计是要消耗资源的（我们这里主要指时间），我们要为这些工作预留资源。 目前遇到的问题 过程改进基础 流程化的目的是提高工作绩效，而不是束缚工作。项目管理层应结合自己项目实际，对流程化体系进行适当剪裁。 项目目标是多个角度（范围、时间、功能）的结合体，一个角度的变化会影响到其他角度。 项目基线（经审核的项目目标），不可轻易修改。仅当变更管理审核后，进行修改。 项目实现以原型为唯一依据。 无论项目规模大小，项目是否复杂，都应该进行项目总结。 变更管理负责处理所有变更。项目设计是变更进入的唯一入口。变更进入流程后，要先修改项目设计，然后修改原型，然后修改系统，这个顺序要严格遵守。 过程改进建议 图表 1 流程图 如上图，将整个项目生命期分为六个阶段，分别是：定义阶段、原型设计阶段、开发实现阶段、测试阶段、上线阶段和收尾阶段。其中，定义阶段完成项目的目标（范围、时间、功能点），原型设计阶段完成项目原型的开发及测试，开发实现阶段完成项目的编码实现工作，测试阶段完成对系统的测试，上线阶段按照目前的上线流程进行上线，收尾阶段负责对项目进行总结，记录项目资产。 流程化说明 项目定义 根据业务需要或其他需求而提出项目，这是可能只是一个初步的简单想法或思路，描述页比较简单。例如：会员后台轻量化、做一个智囊团功能、做一个彩票系统、在九樱后台添加媒体禁用功能等。 项目启动会 项目组决定开始做这个项目，首先分配责任并组织相关人员收集