开发流程过程改进建议剖析

《开发流程过程改进建议剖析》由会员分享，可在线阅读，更多相关《开发流程过程改进建议剖析（11页珍藏版）》请在金锄头文库上搜索。

1、文档号：pj-20110214-001 版本号：0.1 日 期：2012-0612 开发流程开发流程 过程改进建议过程改进建议 九九樱樱天下（北京）信息技天下（北京）信息技术术有限公司有限公司 。 文档号：九樱天下-2011安全 MC SYSTEM 第 i 页 修修订历订历史史记录记录 版本版本日日 期期描描 述述修修订订人人 张二明 文档号：九樱天下-2011安全 MC SYSTEM 第 ii 页 目目 录录 1概述概述3 1.1目前遇到的问题3 1.2过程改进基础4 2过程改进建议过程改进建议5 2.1流程化说明5 2.2变更管理7 2.3BUG 审核7 3开发注意事项开发注意事项8 3.

2、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 在内的其他一系列项目型工作后，我对目前的开发环境及组织过程有了完整的 认识，为了更好的完成以后的工作，结合我们组的工作经验及建议，我对开发流程提 出过程改进建议过程改进建议。 首先，对项目有一个全面的认识，项目是为创造独特的产品、服务或成果而进行 的临时性工作。这是对项目的定义，在我们的

3、工作中，分配下来的任务都可以视为项 目，商城轻量化改造是项目，新增智囊团功能是项目，修改一版 BUG 也是项目（修改 BUG 是最简单的项目，因为目标明确、范围界定准确）。项目不分大小，都需要进行 规划，都需要标准化的管理，这也是我提出过程改进建议的初衷。 项目的特点有三个：独特性、临时性和不确定性独特性、临时性和不确定性。独特性指每一个项目都是独特 的，没有两个项目是相同的，有可能当前项目中某一块具体功能在以前的项目中有重 复，这也只能说在项目实现时有一些经验借鉴。临时性指项目要有明确的起点和终点， 即项目的时间约束条件，这是项目的重要制约因素，项目必须承诺在指定的时间内完 成，而不是随着工

4、作的完成而项目结束，这一点我们的认识不够深刻。项目的不确定 性有两点，一是指项目在整个生命周期中会因环境变化、风险移动等因素而产生变化， 这类变化成为变更；而是指由于项目的独特性而产生的项目结果认识不完整，这一点 常常被忽视，我们在实际开发中，总是希望先把项目设计的足够完整足够详细足够全 面，而实际上对绝大多数项目说这是不现实的，对项目的认识就像认识海上的冰山一 样，项目经理必须全面认识水上部分，同时预测水下部分，并随着冰山的上浮不断重 新认识重新预测，这就是规划项目的常用技术渐进明细渐进明细（指在项目进程中，随着信 息越来越详细，估算越来越准确，持续改进和细化计划）。 基于以上的认识，得出的

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

6、.1目前遇到的目前遇到的问题问题 文档号：九樱天下-2011安全 MC SYSTEM第 4 页 1.2过过程改程改进进基基础础 1.流程化的目的是提高工作绩效，而不是束缚工作。项目管理层应结合自己项目实际， 对流程化体系进行适当剪裁。 2.项目目标是多个角度（范围、时间、功能）的结合体，一个角度的变化会影响到其 他角度。 3.项目基线（经审核的项目目标），不可轻易修改。仅当变更管理审核后，进行修改。 4.项目实现以原型为唯一依据。 5.无论项目规模大小，项目是否复杂，都应该进行项目总结。 6.变更管理负责处理所有变更。项目设计是变更进入的唯一入口。变更进入流程后， 要先修改项目设计，然后修改原

7、型，然后修改系统，这个顺序要严格遵守。 文档号：九樱天下-2011安全 MC SYSTEM第 5 页 2过程改进建议过程改进建议 过程改进 项目组项目管理测试组运维支持组 收尾阶段上线阶段测试阶段开发实现阶段原型设计阶段定义阶段 项目定义 项目启动会 项目设计 项目设计评审会 原型开发 原型测试 开发实现 单模块测试 总体测试 BUG审核 变更 管理 上上线线流流程程 项目总结 编写测试用例 图图表表 1 流程流程图图 如上图，将整个项目生命期分为六个阶段，分别是：定义阶段、原型设计阶段、 开发实现阶段、测试阶段、上线阶段和收尾阶段。其中，定义阶段完成项目的目标 （范围、时间、功能点），原型设

8、计阶段完成项目原型的开发及测试，开发实现阶段 完成项目的编码实现工作，测试阶段完成对系统的测试，上线阶段按照目前的上线流 程进行上线，收尾阶段负责对项目进行总结，记录项目资产。 2.1流程化流程化说说明明 1.项目定义 根据业务需要或其他需求而提出项目，这是可能只是一个初步的简单想法 或思路，描述页比较简单。例如：会员后台轻量化、做一个智囊团功能、做一 个彩票系统、在九樱后台添加媒体禁用功能等。 2.项目启动会 项目组决定开始做这个项目，首先分配责任并组织相关人员收集需求，这 两项成为项目启动会的主要内容。分配责任就是指定项目的相关责任人（谁总 体负责，谁参与开发等）；收集需求是指通过多种方式

9、来确定项目的需求，对 于规模小的项目，收集需求会比较简单，可以在会上敲定。对于规模大的项目， 要根据具体情况采用多种方式收集。这个工作由项目管理层进行组织。 3.项目设计 项目设计包括：整理需求、描述实现思路、确定项目目标。项目目标包括 项目范围、项目时间约束、项目功能点等。其中，项目范围确定项目的范畴及 边界，明确哪些在项目中，哪些不在项目中（例如：在改造功能 A 项目中， 发现了功能 B 的问题，这时功能 B 的问题是不属于本项目的，如果要修改则需 文档号：九樱天下-2011安全 MC SYSTEM第 6 页 要变更管理）。项目时间约束规定项目的关键时间点（也称里程碑），规定何 时原型开发

10、完成、何时开发实现完成交给测试等。项目功能点属于项目范围范 畴，由于其在我们的项目中比较重要，所以单独提取出来作为项目目标的一项， 要列出项目的关键功能点，以利于评价项目目标。这里要注意项目目标是多个 角度（范围、时间、功能）的结合体，一个角度的变化会影响到其他角度，所 以对目标的变化要慎重。这个工作由项目负责人完成。 4.项目设计评审会 项目设计完成后，就要组织相关人员进行评审。评审内容包括：需求理解 的是否正确（准确性、正确性、完整性）、实现思路是否正确可行、项目目标 是否可接受。以上内容经审核后就成为项目基线（经审核的项目目标），不可 轻易修改。仅当变更管理审核后，进行修改。这个工作由项

11、目负责人牵头，项 目管理层协助完成。 5.原型开发 项目基线确定后，可以进行原型开发，在我们的项目中，原型非常重要，项目 实现以原型为唯一依据。这个工作由项目组成员（美工）完成。 6.原型测试 原型开发完成后，进行原型测试。这是我们新增加的内容。原型测试的目 的有三个：业务展现的是否正确合理、页面样式是否正确合理、多浏览器是 否兼容。这个工作由测试完成。 7.编写测试用例 原型测试通过后，就可以进入开发实现阶段，开发实现阶段包含编写测试 用例和开发实现两项工作，这两项可以并行进行。 根据原型编写测试用例，测试用例最好是针对单个功能的，测试用例完成 后要进行讨论确定，开发人员要通过查看并学习测试

12、用例来了解业务并指导 系统调试工作。这个工作由测试完成。 8.开发实现 开发实现，主要指开始编写代码实现系统。项目实现以原型为唯一依据， 其他任何形式的指令都不能作为项目实现依据。如果有可借鉴的代码，要谨慎 使用，禁止因原来代码的逻辑而修改当前项目的逻辑。这个工作由项目负责人 通过指导与管理项目组成员来完成。 9.单模块测试 单模块测试，指一个功能完成后进行的功能测试，单模块测试要根据具体 项目的规模来考虑，如果项目规模比较小可以不做单模块测试，添加单模块测 试的目的是提前暴露系统 BUG。这个工作由测试完成。 10. 总体测试 对系统进行整体测试。在整个流程中，我将测试拆分成了三部分，目的是

13、 在不同阶段暴露不同类型的 BUG，而不是在最后出现一大堆的 BUG。这个工 作由测试完成。 11. 上线流程 文档号：九樱天下-2011安全 MC SYSTEM第 7 页 测试通过后，按照目前的上线流程进行上线工作。 12. 项目总结 无论项目规模大小，项目是否复杂，都应该进行项目总结，来分享成功的 经验和失败的教训，以形成项目资产，来指导后来的项目。项目总结的内容包 括但不限于：对业务的理解、制定项目计划过程中的经验和教训、项目执行过 程中的经验和教训、项目监控过程中的经验和教训等。 2.2变变更管理更管理 项目在没有结束前一直面临着变更，与项目相关的任何人都有权提出变更。项目 负责人为实

14、现项目目标必须管理变更，注意管理变更并不意味着拒绝变更和回避变更， 而是面对变更。变更管理的目的是通过各种方式使变更对项目目标的影响最小。变更 管理负责处理所有的变更，未经管理的变更会造成系统蔓延。 项目负责人负责收集并记录变更请求，并对变更进行分析其影响范围，对于影响 大的变更需要经项目管理层审批。经批准或确认后的变更要纳入标准化流程中进行处 理，项目设计是变更进入的唯一入口。变更进入流程后，要先修改项目设计，然后修 改原型，然后修改系统，这个顺序要严格遵守。 2.3BUG 审审核核 BUG 审核也是新增加的内容，主要针对反馈状态的 BUG（包括建议型、需求型、 与本项目无关型等）。项目组在

15、面对这些 BUG 时，会犹豫改还是不改，我认为对这类 BUG 应该至于一种“悬浮”状态，由项目管理层来决定是否做，有些时候项目组队 BUG 的态度项目管理层并不认同。如果涉及到变更，则应进行变更管理。 文档号：九樱天下-2011安全 MC SYSTEM第 8 页 3开发注意事项开发注意事项 开发注意事项，是项目组在开发系统的过程中，形成的开发约定及规范，我们明 确的列出这些约定。 3.1团队团队基本基本规则规则 （1）每天下班前写工作日志； （2）每天下班前提交工作内容（代码、文档、文件等）； （3）工作时间（9:00-12:00, 13:00-18:00）禁止浏览与工作无关的内容； （4）每

16、天上午 9：30 开团队例会。团队例会的目的是让整个团队了解每一个成 员的工作状况，以便分享成果和总结经验。团队成员在参加例会前要准备 如下内容：昨天工作总结、今天工作计划和遇到的难点问题。每一名成员 的发言时间尽量控制在 4 分钟以内。 3.2不能自己引用第三方包不能自己引用第三方包 第三方包要统一进行管理，项目组成员不能随意在项目中添加使用第三方包。如 果需要使用第三方包，应先说明需求，然后由项目管理者组织讨论后决定，不要自己 从网上下载个包就直接用。 3.3要注意区分使用要注意区分使用单单表和服表和服务务 如果操作只涉及一个数据库表，则应该使用单表；否则使用服务，开发或修改服 务时要先向项目管理者说明。另外要注意，尽量不使用旧的服务包（例如： vinuxshop-biz-core.jar，bizviva-core.jar 等）。 3.4特定代特定代码码管理管理规则规则 特定代码指定负责人，如果开发过程中涉及特定代码修改，必须通知负责人，由 负责人修改。特定代码负责人如下表： 序号序号代码代码工程工程负责人负责人 1实体类vinux-dal-query-entity-too