1. 为什么需要软件项目管理方法和工具

　　软件开发和项目管理是软件企业最主要的工作，两者相辅相成，缺一不可。项目管理应当覆盖整个软件开发过程。

　　软件项目管理的主要工作有：立项与结项、项目规划与监控、风险管理和变更管理、需求管理、质量管理、软件配置管理等。

　　软件开发的主要过程域有：需求开发、软件设计、软件实现、软件测试、软件发布、客户验收、软件维护等。

　　由于软件开发和项目管理都是智力型工作，人们很难靠常识和直觉形成和谐的团队工作。如果企业没有统一的项目管理方法和工具，每个人都采用自己的做事方法的话，那么人越多就越乱，形成了“土匪、游击队”的工作方式。阻碍国内IT企业发展的瓶颈问题通常不是技术问题，而是杂乱无章的管理。

　　项目管理方法和工具对企业的主要贡献是：让所有项目成员有条不紊地开展工作，在预定的时间和成本之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。

　　2. 常见软件项目管理方法介绍

　　2.1 CMM/CMMI

　　1986年11月，美国联邦政府委托卡内基梅隆大学（Carnegie-Mellon）软件工程研究所（SEI）开发一套用于评估软件承包商能力的方法。SEI于1987年9月发布了一套软件过程成熟度框架和一套成熟度问卷。1991年，SEI将软件过程成熟度框架发展成为软件能力成熟度模型（Capacity Maturity Model，CMM），诞生了CMM 1.0。

　　十几年来，CMM的改进工作一直不断地进行。美国国防部希望把现在所有的、以及将被开发出来的各种能力成熟度模型，集成到一个框架中去。到2000年，CMM演化成为CMMI（Capability Maturity Model Integration，能力成熟度模型集成）。CMMI不仅适合软件，而且适合于软件硬件结合的系统，这是对CMM最大的改进。

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

　　CMM有一个重要的概念是关键过程域（Key Process Area）。关键过程域指出为了达到某个成熟度等级必须要解决的一族问题。除了初始级（即CMM 1级）以外，每个成熟度等级都有若干个关键过程域。

　　CMM 2级有6个关键过程域：需求管理，软件项目规划，软件项目跟踪与监督，软件子合同管理，软件质量保证，软件配置管理。
　　CMM 3级有7个关键过程域：机构过程焦点，机构过程定义，培训大纲，集成化软件管理，组间协调，软件产品工程，同行评审。

　　CMM 4级有2个关键过程域：定量过程管理，软件质量管理。

　　CMM 5级有3个关键过程域：预防缺陷，技术革新管理，过程变更控制。

　　CMM共有18个过程域，基本上覆盖了项目管理和软件开发的工作。目前CMM/CMMI已经成为世界范围内用于衡量软件开发和管理能力的事实上的标准。

　　CMM/CMMI的主要应用问题：

　　用CMM/CMMI指导企业的软件过程改进工作是相当不错的，但是企业要做的重要事情显然不仅是软件过程改进。企业最关注的是生存和发展问题，一切离不开赚钱。CMM/CMMI本身不谈如何赚钱的问题。它假设了美好的前提条件，即企业有充足的人员、资金、时间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然上去了（同时成本也下降了），企业自然能够获取更多的利润。软件过程改进对企业经济效益的贡献是间接的，从投入到产出，时间相对比较长。

　　遗憾的是，国内大部分企业没有能力提供那么好的前提条件，企业最缺乏的资源往往就是人员、资金和时间，企业领导当然想把资源用在“刀刃”上，即赚钱最多最快的地方。当软件过程改进和其它直接赚钱的事情“发生资源冲突”时，只好“拆东墙，补西墙”，往往减少软件过程改进的资源。

　　作者对应用CMM/CMMI的建议：

　　CMM/CMMI是衡量企业软件过程能力的国际标准，它对软件过程改进有很多有益的指导。CMM/CMMI仅仅对等级评估做了强制要求，但是对企业“如何进行软件过程改进”没有强制要求，CMM/CMMI的数百页文本并不是“放之四海皆准”的，企业可以采纳也可以不采纳。

　　对于软件过程改进而言，CMM/CMMI是用来参考的，而不是用来迷信的。企业在参考业界推荐的标准或规范时，要舍弃那些听起来很先进但是对本企业无益处的东西，只选取对企业有实用价值的东西。

[本文共有 4 页，当前是第 1 页] <<上一页 下一页>>