项目管理

项目来源通常可区分客户合同项目、内部产品更新换代。客户合同项目由于受到客户直接约束，有固定的工期，而且需求往往很不稳定，很多时候客户只指定一个大概的需求范围，由开发商在应标的时候列出能实现的功能需求、环境支持和开发费用，在多家开发商应标的情况下，客户有可能综合多家厂家的功能，要求开发商实现，还有一些项目客户只提出研究方向，根本没有具体的需求细节；内部产品更新换代需求相对稳定一些，而且工期也相对宽松，比较容易把握，但产品的需求是连续的，产品需要不停的升级增加新功能才有生命力；由于需求的稳定性不同，往往需要比较好的开发模型来支持，否则很容易发生到了项目后期才发现实现的功能与实际应用需求不符，达不到使用效果，导致项目失败；开发模型的不同，需要管理的力度也不同，管理花费的时间也不同。

今天，因为开发团队的体制调整，笔者在基础结构及技术调查方向上又增加了开发小组的管理工作，负责Web页面（包括业务逻辑和数据访问）的制造以及单体。因为原来主要负责技术调查工作，所以角色转换的同时需要先明确团队现有的软件开发过程是否有问题，从而进行改善。

产品开发的组织架构和产品开发过程管理是一个软件企业开发管理的两个侧面，开发组织架构指软件项目的立项和项目开发有效的人员调配和组织，开发过程管理指在项目确定后，软件开发过程的管理。本文根据作者在建立软件企业管理体系时采用的集成产品开发（IPD）和CMM2级过程控制的基本思想和体会整理而成，着重介绍企业的开发组织和开发过程管理的基本原则，并以IPD和CMM2级的管理思想为基础建立了一套完整的产品开发组织架构和过程管理体系，对提高产品的开发效率和产品研发设计的质量有指导作用。

负责对软件开发项目做出重大的资金和管理决策的筹划指导委员会，通常对迭代化开发实践不太熟悉。这篇文章介绍了，为了有效地管理一个迭代化开发项目，这些委员会应该知道些什么和他们应当问哪些问题

CMM 基本上是 15 年之前比较传统、陈旧的东西，现在我们更多地应该拿 CMMI-SW 与 Agile 进行比较。目前有关 CMM/CMMI 与 Agile 比较的最权威的一本名著是：Barry Boehm 与 Richard Turner 大师的 Balancing Agility and Discipline: A Guide for the Perplexed（BAND）。CMMI 到底与 Agile 有何不同？我向国内每一位软件项目经理、架构师和过程改进相关负责、研究人员推荐这本必读之作。

笔者认为，不要对CMM/CMMI热过了头。软件企业可以选择CMM/CMMI，也可以选择6Sigma，也可以选择ISO9001。小公司也不要急着上CMM/CMMI或者更多的过程改进框架，免得给自己上套，花了钱不算，束缚自己的手脚。

对软件企业来说，cmm是一个自我评估和自我提高的途径，是提高软件开发的管理能力，加强国际竞争力的有效手段；对软件用户，cmm也提供了一个衡量软件开发商开发水平的评估方法，有助于软件开发项目的风险识别。到底什么是cmm；为什么要引入cmm；它在我国的应用情况怎样等；本期将从这几个方面探讨cmm。

学编程的人想成为求伯君，这个中国早期软件业的神话人物成就了金山公司。但不是每个“英雄”都有求伯君的能力与运气。于是乎“成也萧何，败也萧何”，“英雄”创造了企业，但随着个人能力的局限，却成了不少企业陨落的原因。将来这种情况势必会有所控制，因为不少软件企业选择CMM管理模式来削弱“游戏”中“英雄”的地位。

首先要注意定量项目管理的目的，项目管理的质量和过程性能目标必须和企业的业务目标和组织目标相符合。在QPM前已经有了组织的过程性能基线和过程性能模型，项目是在组织级过程定义的基础上，根据目标驱动，确定项目哪些子过程需要进行定量管理，通过对项目进行定量管理以期望达到项目预定的质量和过程性能目标。

这里很类似6Sigma里面的VOC到CTQ的转化过程。项目质量和过程性能目标不是凭空产生的，而来源于具体的商业目标，客户需求，组织目标等。如果根据组织和商业目标转化为项目的质量和过程性能目标，这就涉及到两个问题，一个是要确定出需要定义哪些质量和过程性能目标，一个是要确定出这些目标和优先级和权重。最适宜的工具SP1.1里面已经谈到就是采用QFD质量功能分解。

CMM描述了五个级别的软件过程成熟度（初始级 可重复级 已定义级 已管理级 优化级，成熟度反映了软件过程能力(Software Process Capability)的大小，任何一个软件机构的软件过程必定属于其中某个级别。除了第一级以外，每级成熟度又由若干关键过程域(Key Process Area)构成。

CMM将能力成熟度分为5个级别，这5个成熟度等级为评价机构软件过程能力提供了一个有序的级别。同时也为机构的软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一步地改进过程能力而不是企图跳跃式地前进。

软件生产一般包括“需求管理”、“流程设计管理”、“开发管理”、“测试管理”等主要过程。那么，软件的质量管理是从哪一个环节开始的呢？不是从设计阶段，更不是开发阶段，而是从软件需求阶段就开始了。在软件生产过程中，“软件需求”的调查报告是一个生产过程的开始，软件质量的管理之路也就随之开始了。

需求管理是CMM二级中列出的第一个关键域，这是因为它实际上是二级引入到开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在二级的其他关键过程域中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。

CMM是软件过程能力成熟度模型（Capacity Maturity Model）的简称，是卡内基－梅隆大学软件工程研究院为了满足美国联邦政府评估软件供应 商能力的要求，于1986年开始研究的模型，并于1991年正式推出了CMM 1.0 版。CMM自问世以来备受关注，在一些发达国家和地区得到了广泛应用，成为衡量软件公司软件开发管理水平的重要参考因素和软件过程改进事实上的工业标准。据了解，美国、印度、日本等国家已有数十家公司通过了CMM不同等级的认证。

许多软件企业在实施CMM时，过多地采用“拿来主义”，实施工具要“拿来”（照搬国外的工具），体系“设计”也要“拿来”（用别人的成套模板改改来用）。这种做法不一定适合软件企业的实际，会使软件过程改进（SPI）失去意义，那么体系设计有没有方法？这里提出CMM体系设计的三步曲，就是CMM体系设计中应依次采取三种不同设计方法：概要设计、详细设计和度量设计。

CMM五级标准

CMM是Capability Maturity Model for Software的简称，中文叫“软件能力成熟度模型”，是对组织软件过程能力的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化，使企业能够更好的实现商业目标。

在世界范围内，软件项目需求正以非常快的速度增长，并且这种增长看起来还远未达到目的。这种增长已经导致软件开发活动急剧性的增长，已使得对用于构筑软件的过程，正确的说法是软件过程，得到更多的关注。软件过程可以定义为人们用来开发和维护软件以及相关产品（如：工程计划、设计文档、规章、检测事例及用户手册）的一组活动、方法、实践及转换。软件过程重要性的提高已经引起了对软件过程改进的要求，这就需要过程分析和评估的方法。

在CMM的发展进程中，曾经提议将软件评价与测试（Evaluation and Test）作为CMM的一个KPA加入到CMM中，虽然这一提议最终未获通过，但通过对这一提议的讨论，我们可以得到很多与软件测试相关的一些有益的东西。