大部分it企业从事产品开发或者合同项目开发(编辑修改稿)

大部分it企业从事产品开发或者合同项目开发(编辑修改稿)内容摘要：

价 值不高。 我对“软件、嵌入式系统、集成电路”此类研发企业的建议是，学习和应用 ISO 9000质量标准是有意义的，但是不必费时、花钱去搞 ISO 9000 认证（ 除非 公司策略 需要 ），因为业内人士并不看重 ISO 9000 认证。 CMM/CMMI 1986 年 11 月，美国联邦政府委托卡内基梅隆大学（ CarnegieMellon）软件工程研究所（ SEI）开发一套用于评估软件承包商能力的方法。 SEI 于 1987 年 9 月发布了一套软件过程成熟度框架和一套成熟度问卷。 1991 年， SEI 将软件过程成熟度框架发展成为软 件能力成熟度模型（ Capacity Maturity Model， CMM），诞生了 CMM。 1993 年， SEI推出了 CMM ，这是目前世界上应用最广泛的 CMM 版本。 十几年来， CMM 的改进工作一直不断地进行。 美国国防部希望把现在所有的、以及将被开发出来的各种能力成熟度模型，集成到一个框架中去。 到 2020 年， CMM 演化成为 CMMI（ Capability Maturity Model Integration，能力成熟度模型集成）。 CMMI 不仅适合软件，而且适合于软件硬件结合的系统 ，这是对 CMM 最大的 改进。 从 20 世纪 90 年代至今，软件过程改进成为软件工程学科的一个主流研究方向，其中 CMM 和 CMMI 是该领域举世瞩目的重大成果。 CMM/CMMI 是世界范围内用于衡量软件（硬件）过程能力的事实上的标准，同时也是软件（硬件）过程改进最权威的指南。 CMM 将能力成熟度分为 5 个级别，这 5 个成熟度等级为评价机构软件过程能力提供了一个有序的级别，如图 12 所示。 同时也为机构的软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一步地改进过程能力而不是企图跳跃式地前进。 图 12 CMM 的 5 个能力成熟度 等级 人们往往搞不清楚 CMM 和软件过程改进的关系， 将二者 混为一谈。 下面 作个比喻来解释： 把“软件过程改进”比喻为“学英语，提高英语能力”，那么 CMM 就好比L1 初始级 L2 可重复级 L3 已定义级 L4 已管理级 L5 优化级 持续改进的过程 可预测的过程 标准、一致的过程 有纪律的过程 7 是“英语等级评估标准（考试大纲）”。 一般情况下，英语等级考试的成绩反映了英语能力。 但是，在特别擅长应试的中国，英语考试成绩很好并不见得英语能力很好，甚至 可能 差到“哑巴英语”的程度。 这种“特性”传染到软件领域，不少企业虽然通过了高级别的 CMM 等级评估，但是其实际能力却非常 低下。 软件过程改进的真正目的是提高机构的软件过程能力，而不是为了达到 CMM 高等级。 “汝果欲写诗，功夫在诗外”，这是很好的启示。 2020 年至 2020 年，我在上海贝尔有限公司负责 CMM/CMMI 的研究和推广工作，公司的每个事业部都有软件（硬件）过程改进人员。 公司在 CMM/CMMI 过程改进方面的投入巨大，取得一些成效，但是没有达到我的期望值。 感慨很多，一言难尽。 此处，我对CMM/CMMI 过程改进做个简要的评论，供同行企业参考。 一、 CMM 等级评估：从狂热回归理性 2020－ 2020 年是国内 IT 企业搞 CMM 等级评估最狂热的时期，主要原因有： （ 1） 2020 年， CMM 刚刚在国内兴起，感兴趣（ 学习、研究）的人非常多。 近几年国内出版了不少关于 CMM、软件过程改进的书籍，相关论坛、会议也比较多。 有良好的群众基础。 （ 2）那个时候 ISO9000 认证已经被国人搞臭了，而当时国内 CMM 等级评估还很少见，企业达到 CMM 2 级、 3 级是很荣耀的事情。 物以稀为贵，人们把认证的目光从ISO9000 转向了 CMM。 （ 3）为了扶持当地软件企业，鼓励软件出口，各地方政府相继出台了“资助企业搞 CMM 等级评估的政策”。 最先搞 CMM 评估的企业 尝 到了甜头，自己拿到了比较吃香的 CMM 等级证书，昂贵的评估费用大多由政府支付了。 这 一剂催化剂，进一步激发了企业搞 CMM 评估的热情。 2020－ 2020 年期间，国内有数百家企业通过了 CMM 2 级、 3 级评估，大部分企业搞 CMM 评估是“为了拿证书”而不是“真正提高软件过程能力”。 到 2020 年，国内 CMM 评估从狂热回归理性。 主要原因有： （ 1）地方政府基本上不再资助企业搞 CMM 等级评估了。 企业自己掏钱搞 CMM 评估就舍不得了，要掂量是否值得（理性的表现）。 （ 2）由于国内通过 CMM 2 级、 3 级评估的企业已经很多，而且评估时“放水”现象严重， CMM 评估的声誉已经大不如 2020 年。 （ 3）最让人 失望的是，虽然有些企业通过了 CMM 2 级、 3 级评估，但是实际的软件过程能力却依然底下。 有些企业实施 CMM 后，质量没有明显提高，进度更落后了，成本增加了，人员更累了。 现在软件业界普遍关注的是：企业如何以比较低的代价有效地提高软件过程能力。 CMM 等级评估则 退居次要地位。 二 、 CMM 的盲区和常见应用问题 第 1 章 IT 企业研发管理综述 8 用 CMM 指导企业的软件过程改进工作是相当不错的，但是企业要做的重要事情显然不仅是软件过程改进。 企业最关注的是生存和发展问题，一切离不开赚钱。 CMM 本身不谈如何赚钱的问题。 它假设了美好的前提条件，即企业有充 足的人员、资金、时间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然上去了（同时成本也下降了），企业自然能够获取更多的利润。 软件过程改进对企业经济效益的贡献是间接的，从投入到产出，时间相对比较长。 遗憾的是，国内大部分企业没有能力提供那么好的前提条件，企业最缺乏的资源往往就是人员、资金和时间，企业领导当然想把资源用在“刀刃”上，即赚钱最多最快的地方。 当软件过程改进和其它直接赚钱的事情“发生资源冲突”时， 只好“拆东墙，补西墙”，往往减少软件过程改进的资源。 如果 完全按照 CMM 的要求遍 历“ 18 个关键过程域和百余个关键实践”的话，无疑会占用大量的资源，资源冲突在所难免，失败的风险很高。 所以 切勿照搬 CMM，一定要根据企业的实际情况（企业发展战略、产品特征、资源状况）给出软件过程改进的措施。 CMM 对软件项目管理和机构过程管理论述很深入，但是对软件开发的核心工作即“需求开发、软件设计、编程、测试、维护”论述非常少， CMM 把它们压缩为一个过程域叫 做 “产品工程”（ Product Engineering），近乎一笔带过。 所以导致一个怪现象，管理人员 觉得 CMM 真。