开发流程过程改进建议模板

修订历史记录

目录

1概述 (3)

1.1目前遇到的问题 (3)

1.2过程改进基础 (4)

2过程改进建议 (5)

2.1流程化说明 (5)

2.2变更管理 (7)

2.3BUG审核 (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)

1概述

在经历了商城轻量化改造、专卖店轻量化改造、会员后台轻量化改造以及包括修改BUG在内的其他一系列项目型工作后，我对目前的开发环境及组织过程有了完整的认识，为了更好的完成以后的工作，结合我们组的工作经验及建议，我对开发流程提出过程改进建议。

首先，对项目有一个全面的认识，项目是为创造独特的产品、服务或成果而进行的临时性工作。这是对项目的定义，在我们的工作中，分配下来的任务都可以视为项目，商城轻量化改造是项目，新增智囊团功能是项目，修改一版BUG也是项目（修改BUG 是最简单的项目，因为目标明确、范围界定准确）。项目不分大小，都需要进行规划，都需要标准化的管理，这也是我提出过程改进建议的初衷。

项目的特点有三个：独特性、临时性和不确定性。独特性指每一个项目都是独特的，没有两个项目是相同的，有可能当前项目中某一块具体功能在以前的项目中有重复，这也只能说在项目实现时有一些经验借鉴。临时性指项目要有明确的起点和终点，即项目的时间约束条件，这是项目的重要制约因素，项目必须承诺在指定的时间内完成，而不是随着工作的完成而项目结束，这一点我们的认识不够深刻。项目的不确定性有两点，一是指项目在整个生命周期中会因环境变化、风险移动等因素而产生变化，这类变化成为变更；而是指由于项目的独特性而产生的项目结果认识不完整，这一点常常被忽视，我们在实际开发中，总是希望先把项目设计的足够完整足够详细足够全面，而实际上对绝大多数项目说这是不现实的，对项目的认识就像认识海上的冰山一样，项目经理必须全面认识水上部分，同时预测水下部分，并随着冰山的上浮不断重新认识重新预测，这就是规划项目的常用技术—渐进明细（指在项目进程中，随着信息越来越详细，估算越来越准确，持续改进和细化计划）。

基于以上的认识，得出的结论是：一次性完成项目的成本最低。把我们分派的工作视为项目，项目就要规划、评审、设计、实现，而不是直接上来就编代码。对于规模较大的项目（如商城轻量化改造），我们容易接受这个观点；对于规模小的项目（如添加媒体审核功能），很多时候我们不愿意接受这个观点，而导致多次返工。修改BUG工作，我认为是最简单的项目，因为目标明确，这类项目可以根据具体BUG内容进行适当剪裁。所谓一次性完成，主要指不要让我们的项目因缺少规划、着急开始、认识不全面等原因而导致的多次返工，同时还要认识到，规划、评审、设计是要消耗资源的（我们这里主要指时间），我们要为这些工作预留资源。

1.1目前遇到的问题

1.2过程改进基础

1.流程化的目的是提高工作绩效，而不是束缚工作。项目管理层应结合自己项目实际，

对流程化体系进行适当剪裁。

2.项目目标是多个角度（范围、时间、功能）的结合体，一个角度的变化会影响到其

他角度。

3.项目基线（经审核的项目目标），不可轻易修改。仅当变更管理审核后，进行修改。

4.项目实现以原型为唯一依据。

5.无论项目规模大小，项目是否复杂，都应该进行项目总结。

6.变更管理负责处理所有变更。项目设计是变更进入的唯一入口。变更进入流程后，

要先修改项目设计，然后修改原型，然后修改系统，这个顺序要严格遵守。

2过程改进建议

图表1 流程图

如上图，将整个项目生命期分为六个阶段，分别是：定义阶段、原型设计阶段、开发实现阶段、测试阶段、上线阶段和收尾阶段。其中，定义阶段完成项目的目标（范围、时间、功能点），原型设计阶段完成项目原型的开发及测试，开发实现阶段完成项目的编码实现工作，测试阶段完成对系统的测试，上线阶段按照目前的上线流程进行上线，收尾阶段负责对项目进行总结，记录项目资产。

2.1流程化说明

1.项目定义

根据业务需要或其他需求而提出项目，这是可能只是一个初步的简单想法或思路，描述页比较简单。例如：会员后台轻量化、做一个智囊团功能、做一

个彩票系统、在九樱后台添加媒体禁用功能等。

2.项目启动会

项目组决定开始做这个项目，首先分配责任并组织相关人员收集需求，这两项成为项目启动会的主要内容。分配责任就是指定项目的相关责任人（谁总

体负责，谁参与开发等）；收集需求是指通过多种方式来确定项目的需求，对

于规模小的项目，收集需求会比较简单，可以在会上敲定。对于规模大的项目，要根据具体情况采用多种方式收集。这个工作由项目管理层进行组织。

3.项目设计

项目设计包括：整理需求、描述实现思路、确定项目目标。项目目标包括项目范围、项目时间约束、项目功能点等。其中，项目范围确定项目的范畴及

边界，明确哪些在项目中，哪些不在项目中（例如：在改造功能A项目中，发

现了功能B的问题，这时功能B的问题是不属于本项目的，如果要修改则需要

变更管理）。项目时间约束规定项目的关键时间点（也称里程碑），规定何时原型开发完成、何时开发实现完成交给测试等。项目功能点属于项目范围范畴，由于其在我们的项目中比较重要，所以单独提取出来作为项目目标的一项，要列出项目的关键功能点，以利于评价项目目标。这里要注意项目目标是多个角度（范围、时间、功能）的结合体，一个角度的变化会影响到其他角度，所以对目标的变化要慎重。这个工作由项目负责人完成。

4.项目设计评审会

项目设计完成后，就要组织相关人员进行评审。评审内容包括：需求理解的是否正确（准确性、正确性、完整性）、实现思路是否正确可行、项目目标是否可接受。以上内容经审核后就成为项目基线（经审核的项目目标），不可轻易修改。仅当变更管理审核后，进行修改。这个工作由项目负责人牵头，项目管理层协助完成。

5.原型开发

项目基线确定后，可以进行原型开发，在我们的项目中，原型非常重要，项目实现以原型为唯一依据。这个工作由项目组成员（美工）完成。

6.原型测试

原型开发完成后，进行原型测试。这是我们新增加的内容。原型测试的目的有三个：业务展现的是否正确合理、页面样式是否正确合理、多浏览器是否兼容。这个工作由测试完成。

7.编写测试用例

原型测试通过后，就可以进入开发实现阶段，开发实现阶段包含编写测试用例和开发实现两项工作，这两项可以并行进行。

根据原型编写测试用例，测试用例最好是针对单个功能的，测试用例完成后要进行讨论确定，开发人员要通过查看并学习测试用例来了解业务并指导系统调试工作。这个工作由测试完成。

8.开发实现

开发实现，主要指开始编写代码实现系统。项目实现以原型为唯一依据，其他任何形式的指令都不能作为项目实现依据。如果有可借鉴的代码，要谨慎使用，禁止因原来代码的逻辑而修改当前项目的逻辑。这个工作由项目负责人通过指导与管理项目组成员来完成。

9.单模块测试

单模块测试，指一个功能完成后进行的功能测试，单模块测试要根据具体项目的规模来考虑，如果项目规模比较小可以不做单模块测试，添加单模块测试的目的是提前暴露系统BUG。这个工作由测试完成。

10.总体测试

对系统进行整体测试。在整个流程中，我将测试拆分成了三部分，目的是在不同阶段暴露不同类型的BUG，而不是在最后出现一大堆的BUG。这个工作由测试完成。

11.上线流程

测试通过后，按照目前的上线流程进行上线工作。

12.项目总结

无论项目规模大小，项目是否复杂，都应该进行项目总结，来分享成功的经验和失败的教训，以形成项目资产，来指导后来的项目。项目总结的内容包

括但不限于：对业务的理解、制定项目计划过程中的经验和教训、项目执行过

程中的经验和教训、项目监控过程中的经验和教训等。

2.2变更管理

项目在没有结束前一直面临着变更，与项目相关的任何人都有权提出变更。项目负责人为实现项目目标必须管理变更，注意管理变更并不意味着拒绝变更和回避变更，而是面对变更。变更管理的目的是通过各种方式使变更对项目目标的影响最小。变更管理负责处理所有的变更，未经管理的变更会造成系统蔓延。

项目负责人负责收集并记录变更请求，并对变更进行分析其影响范围，对于影响大的变更需要经项目管理层审批。经批准或确认后的变更要纳入标准化流程中进行处理，项目设计是变更进入的唯一入口。变更进入流程后，要先修改项目设计，然后修改原型，然后修改系统，这个顺序要严格遵守。

2.3BUG审核

BUG审核也是新增加的内容，主要针对反馈状态的BUG（包括建议型、需求型、与本项目无关型等）。项目组在面对这些BUG时，会犹豫改还是不改，我认为对这类BUG应该至于一种“悬浮”状态，由项目管理层来决定是否做，有些时候项目组队BUG 的态度项目管理层并不认同。如果涉及到变更，则应进行变更管理。

3开发注意事项

开发注意事项，是项目组在开发系统的过程中，形成的开发约定及规范，我们明确的列出这些约定。

3.1团队基本规则

（1）每天下班前写工作日志；

（2）每天下班前提交工作内容（代码、文档、文件等）；

（3）工作时间（9:00-12:00, 13:00-18:00）禁止浏览与工作无关的内容；

（4）每天上午9：30开团队例会。团队例会的目的是让整个团队了解每一个成员的工作状况，以便分享成果和总结经验。团队成员在参加例会前要准备如

下内容：昨天工作总结、今天工作计划和遇到的难点问题。每一名成员的发

言时间尽量控制在4分钟以内。

3.2不能自己引用第三方包

第三方包要统一进行管理，项目组成员不能随意在项目中添加使用第三方包。如果需要使用第三方包，应先说明需求，然后由项目管理者组织讨论后决定，不要自己从网上下载个包就直接用。

3.3要注意区分使用单表和服务

如果操作只涉及一个数据库表，则应该使用单表；否则使用服务，开发或修改服务时要先向项目管理者说明。另外要注意，尽量不使用旧的服务包（例如：vinuxshop-biz-core.jar，bizviva-core.jar等）。

3.4特定代码管理规则

特定代码指定负责人，如果开发过程中涉及特定代码修改，必须通知负责人，由负责人修改。特定代码负责人如下表：

3.5分支版本的应用

打分支时，分支的名称使用“版本加一”格式，然后代码的版本加一，这样保证分支的版本与代码的版本一致。如果要修改JAR包代码，则要引用新版本的JAR包。分支名称在打分支时确定（打分支时注意：不在以日期形式命名分支），代码版本在文件pom.xml中确定，要保证分支名称结尾与版本号一致。举例如下：

3.6对前台文件命名规定

前台文件（*.ftl文件）的命名必须由小写英文字符组成；

禁止使用大写字符；

禁止使用下划线（_）；

禁止使用数字。

3.7数据库设计规范

表名称必须用大写字母，多个单词之间要用下划线（_）隔开；

字段名称必须用大写字母，多个单词之间要用下划线（_）隔开；

ID字段必须存在。

C_DATE字段必须存在。

3.8与第三方技术支持规范

第一步，建议QQ交流群，将相关干系人都邀请到群里面来；

第二步，共享部分API的基础资料到群里面；

第三部，将我们自己了解到的情况写成文件，通告给相关领导及本公司所有干系人；

第四步，召集所有干系人，召开碰头会，了解需求，确定技术实现方案，统一口径。目前API情况如下：API不做定制开发，系统不能做外部部署。