软件过程改进方法与实践案例 王安生 * 电子设备产品生产企业的流程再造 主题 16.1 企业背景和目标 16.2 问题与发现 16.3 与CMMI 3的差异分析 16.4 过程定义 16.5 组织级标准化过程的建立 16.5.1 组织结构定义 16.5.2 产品开发团队架构定义 16.5.3 项目类型与流程定义 16.5.4 产品生命周期定义 16.5.5 研发项目生命周期定义 16.6 项目级管理流程定义 16.6.1 项目启动流程 16.6.2 项目计划的制定 16.6.3 项目流程的裁剪方法 16.6.4 任务分解 16.6.5 项目估计 企业背景和目标 一家在中国研发UPS(Uninterrupted Power System,不间断电源系统)的企业,在此,简称为UPSST。 UPSST运营20多年来,一直稳步上升,产品的市场占有率很高。 目前,其行业排名在国内和国际行业处于领先地位。 问题 原先,该企业主要依靠几名有丰富经验的工程师带领一个小团队努力工作、边做边改,缺乏产品规划、开发计划和监控。 产品开发项目是否能成功,完全取决于团队中核心成员的个人经验与技术能力。 企业的研发模式仍然比较混乱。 最糟糕的是出现过几次这样的情况:几个人在一起开发了几个月后发现,所开发的产品完全与该产品开发的初衷完全不符,最后只得推倒重来,白白浪费企业资源。 企业也很少进行经验教训总结,历史项目中的经验教训都保存在工程师的大脑中,一旦人才流失,项目中的经验教训都随之流失。 目标 根据企业集团的发展策略,公司计划进行大规模的扩展,必须从国内一流企业发展成为国际一流企业。 与其他国际一流UPS制造厂商比较起来,研发项目延期严重,产品质量低下,严重影响该企业产品在国际市场的客户满意度和品牌形象。 为改变这一现状,配合公司成功转型,研发部急需提升目前的研发能力。 领先的技术和好的产品不再是唯一的重点,还需要建立起成熟和规范的管理机制、良好的质量保证机制,以提升产品交付的可预测性。 问题与发现 在决定引入CMMI之前,为了了解工作量大小和难度,公司进行了一次为期一周的研发能力状况调查,访谈了22名同事,包括:项目成员、职能主管、高级经理,研究了3个最近结案项目和公司已有的各种规范文件共计360份,分析当前研发过程中存在的主要问题。 主要问题 问题1: 跨部门沟通困难 项目成员完全由研发人员组成,当产品开发团队需要寻求非研发部的支持时,往往会发现效率低下、沟通成本较高。 项目成员往往因为职责划分不明确而将工作或责任相互推诿。 问题2:项目计划质量低下,对计划未进行严格监控 在制定计划时分析得不够深入,对活动识别得不够完整,往往在工作中发现还有超出计划的很多事情要做,或者发现已计划的工作所需耗费的时间远远大于之前计划的时间。 进度执行出现偏差,缺乏有效的阶段点/里程碑设定和检查,计划更新不及时,也缺乏控制。 问题3: 需求不稳定 前期产品策划随意性较大,没有明确的产品路线图,对市场、客户和竞争对手产品分析得不够深入和充分,对需求的描述也非常简单,很难在项目团队内部达成对需求的一致理解。 在对最终产品一知半解的情况下草率开案,使得制定项目计划时的信息支持不充分或不正确,导致项目计划可执行性较低,并且产品在设计、构建和测试过程中因为需求频繁变动而带来大量的返工,导致项目周期较长、进度偏差大和质量成本居高不下等问题。 问题4:缺乏前期质量控制 不存在任何评审活动,工作产品都是通过不断发现问题然后讨论、解决问题而完成的。 总是等到具体产品组件开发出来后才能够发现问题,此时发现的问题往往很难定位和分析,其修改成本太高,影响项目进度和质量。 主要问题 问题5:开发人员自己测试,测试工作缺乏管理 开发人员边做边测试,测试没有计划,导致测试工作总是按开发人员的思路测试,测试重点很难把握,没有明确的测试通过标识,测试工作往往以将测试时间耗费完为结束标识,无法预测产品质量,测试结果随意性很大,无论是测试工作质量还是对测试进度的控制都是如此。 问题6:各种版本满天飞 开发过程中的版本控制,一般采取在文件名上标注日期的方式。没有对变更进行控制、记录和版本控制。 经常发生版本丢失、版本用错的事情。尤其是在测试阶段,因为硬件测试的需要,经常请软件工程师开发一些用于硬件测试的临时版本,因为版本控制和记录的缺乏导致经常出现对一个缺陷经过大量的分析后发现问题出在版本错误,白白浪费工作量。 问题7:产品集成困难 产品缺乏系统总体规划,总是不同的人负责不同的功能,不是从整个产品系统的角度进行规划,而各部分模块之间的接口也未进行很好的管理和规范,在产品集成时发现很多本可以避免的问题,导致大量的返工。 问题8:经验教训未积累 项目组都
原创力文档

文档评论(0)