1、IT 企业研发和管理综述企业研发和管理综述企业研发和管理综述第第第 1章章章11.1 企业研发管理的一些理念 .21.2 常见方法论介绍和优缺点分析 .31.2.1 覆盖产品生命周期的研发管理体系 31.2.2 ISO 9000 族质量管理体系 51.2.3 CMM/CMMI61.2.4 项目管理知识体系（ PMBOK） .91.2.5 敏捷开发思想 .101.2.6 RUP 和面向对象方法论 .121.3 中小型 IT 企业的研发管理需求和解决方案 .141.3.1 研发管理需求 .141.3.2 研发管理解决方案 .151.4 集成化研发管理方法论（SPP）介绍 161.4.1 SPP 的
2、概念和模型 161.4.2 SPP 的特征和优点 181.5 集成化项目管理系统（FUTURE ）介绍 181.5.1 Future 3.1 的功能介绍 181.5.2 Future 系统的特征和优点 191.5.3 Future 系统自身的开发和管理流程 21大部分 IT 企业从事产品开发或者合同项目开发，有开发就要有管理，管理是为开发服务的。IT 企业的开发过程通常指“需求开发、软件硬件设计、软件硬件实现、测试、发布、维护” 。项目管理涵盖的过程域有“组织结构和人力资源管理、立项与结项、项目规划与监控、需求开发与管理、变更管理、软件质量管理、软件配置管理、日常工作和领导综合管理等” 。本章
3、首先阐述企业研发管理的一些理念，中心思想是“围绕企业利益最大化这个根本目标开展研发和管理工作” 。接着介绍常见的研发管理方法论：产品生命周期管理、ISO9000 族质量体系、软件过程改进与 CMM/CMMI、项目管理与 PMBOK、敏捷软件开发方法、RUP 和面向对象方法论，并进行优缺点分析。之后，本章分析了国内中小型 IT 企业的研发管理需求，阐述作者创作的研发管理解决方案，核心成果是集成化研发管理方法论（SPP）和集成化项目管理系统（ Future） 。本章是全书的综述文章，给出了提纲挈领的观点和论断，有益于读者拓宽视野，取长补短。本书后面的章节将细致地解答 IT 企业项目管理的常见问题，
4、阐述行之有效的方法和工具。第 1 章 IT 企业研发管理综述2读者掌握后马上就可以在企业中应用。1.1 企业研发管理的一些理念企业的根本目标是“合法地赚取尽可能多的利润，使企 业利益最大化 ”。企业所有的特定目标和行动（例如研发和管理等）都是围绕根本目标开展的，不能和根本目标抵触。企业研发管理的指导思想是：结果导向，并且关注 过程。 “结果导向”是指：以最终产生的经济效益来衡量研发项目的业绩，追求利益最大化。 “关注过程”是指：将期望的结果分解到每个过程域（即工作环节）去实现，努力把每项工作做好，从而得到好的结果。一般地，好的过程才可能得到好的产品，而差的过程只会得到差的产品。 衡量工作优劣的
5、三个关键指标是：质量、时间和成本。人们在工作的时候总是希望：做得好（即质量高） 、做得快（即时间少）而且少化钱（即成本低） 。如果出现“三者难以同时兼得”的情况，那么决策者一定要搞清楚质量、时间、成本之间的复杂关系，判断孰重孰轻，给出优化和折衷折中的措施。综 上 所 述 ， 我 们 可 以 总 结 企 业 研 发 管 理 的 目 标 ： 基 本 目 标 ： 让 所 有 人 员 有 条 不 紊 地 开 展 工 作 ，在 预 定 的 时 间 和 成 本 之 内 ，开 发 完 成 质量 合 格 的 产 品 ，从 而 使 企 业 和 个 人 获 得 预 定 的 利 益 。 奋斗目标：调动一切积极因素，
6、努力提高 产品质量、提高工作效率并且降低成本，使企业和个人获得比预定目标更多的利益。在 IT 企业中，研发项目所涉及的主要过程域有： 项目管理过程域：立项管理， 结项管理， 项目规划、项目监控、配置管理、变更管理等； 项目研发过程域：需求开发与管理、 软件硬件设计、 软 件硬件实现、软件硬件测试等、发布与验收等； 机构支持过程域：质量保证、客 户服务、 产品维护等；上述过程域中的任何活动都会影响研发项目的质量、时间和成本。人们显然难以一股脑地把所有的事情做好。在企业里，大部分的工作是成熟的，有成功的模式可以套用，应当走规范化的路线；而另外小部分的工作可能是独特的，并不适宜套用规范（也可能没有规
7、范可以套用） ，那么应当采用超越规范化的管理方式。一般地，企业既需要大量的规范化管理方式，又需要小量的超越规范化的管理方式。通常前者约占 80%，而后者约占 20%（这里 8020 仅仅是建议比例） 。3国内大部分 IT 企业的研发管理现状是：规范化管理太少了，非规范化的管理太多了，到处都是土匪游击队的运作方式。阻碍国内 IT 企业发展的瓶颈问题通常不是技术问题，而是杂乱无章的管理。国内 IT 企业喜欢标榜自己是“高科技企业” ，在开发高科技产品的同时，自己内部的管理却非常落后。真是“鞋匠的儿子没鞋穿” ，这是对 IT 企业的莫大讽刺。本书倡导的研发管理思想是：以追求商业利益最大化为总目标，将
8、提高 质量、提高效率、降低成本的方法（ 经验）融入到所有过程域中，形成适合于本企 业的研发管理规范；开发和部署与 规范配套的管理工具，从而有效地帮助企业依据规范开展研发管理工作。1.2 常见方法论介绍和优缺点分析1.2.1 覆盖产品生命周期的研发管理体系早在 1986 年，美国 PRTM 公司创作了 PACE（Product And Cycle-time Excellence，产品及周期优化法）方法论。PACE 关注的要素有： 正确决策 项目小组构成 开发活动的结构 开发工具与技术 产品战略 技术管理 资源管理PACE 算得上是产品生命周期和流程管理领域的方法论鼻祖。PACE 诞生之后，很多企
9、业和学术机构不断地提出了适合于本行业的研发管理方法论，概念和术语“之多、之大”令人眼花缭乱、茫然失措。20 世纪 90 年代初，IBM 公司遭受了巨大的经营挫折，年亏损额高达近 80 亿美元。为了摆脱经营困境，IBM 实施了以系统性研发管理解决方案为核心的企业再造方案。IBM 引进了PACE 方法论，并获得了巨大的成功。从 1993 年到 1998 年总共节省了 120 亿美元的费用，产品平均开发周期 4 年下降到 16 个月。在 PACE 的基础上，IBM 总结了一套行之有效的产品开发模式，称之为 IPD（Integrated Product Development，集成产品开发）。IBM
10、不仅内部使用 IPD，而且还把 IPD 方案卖给别的企业赚大钱。1999 年，华为公司成为国内第一家引入 PACE 和 IPD 的大型企业，据说花费上亿元人民币，方案供应商自然是 IBM。华为公司在推广 IPD 过程中遭遇重重困难，付出了高昂代价，最终评价是成功的。目前华为已经是国内最大的电信设备供应商，也可以说是国内最大、最第 1 章 IT 企业研发管理综述4好的高科技企业。在企业流程改进领域，华为创作了一句广为流传的名言：“先僵化，再优化，后固化”。相似地，上海贝尔阿尔卡特为了建立适合自身发展需求的研发管理体系（类似于 IPD），从 2002 年开始引入 PACE 方法论，公司在研发管理体
11、系的投入累计达数千万元人民币。本人是该项目的 Process Leader。我和组员们最初接触 PACE 的时候，觉得神秘高深，很是昂慕。我们和 PRTM 公司的咨询师相处了 3 个多月，最大的工作成果是制订了“新产品开发流程”，如图 1-1 所示。有一天，我凝视着那幅花费了一百多万元经费而产生的流程图，突然发现：所有的流程细节都是我们自己制订的，咨 询师仅仅告诉我 们几个先进的概念和术语而已，并没有给予任何超出我意料的革新，竟然赚了很多钱。之后一年，我亲身感受到，所谓国际先进的研发管理方案，实际上效率低下、浪费很大。于是我和合作伙伴创作了面向国内中小型 IT 企业的研发管理方法论（SPP ）
12、和工具（Future） ，并于 2004 年创业。由于有前车之鉴，我们不做华而不实的事情，我们的价值观是“为客户创造的利益必须高于客户付出的成本” 。由于有亲身经历，我对 PACE 和 IPD 方案作个简要的评论，以便读者辨析：PACE 和 IPD 方案适合于指导大型企业的研发管理流程改进，由于涉及面很广，实施过程中会遭遇重重困难，可能导致半途而 废；投入经费巨大， 见 效时间比较长，企业可能挺不住；如果成功，则有巨大的长期收益，但是失败的可能性比成功的可能性高得多。如华为和上海贝尔阿尔卡特之类的研发管理体系，根本不适合于国内中小型 IT 企业，因为尝试不起、承担不起。图 1-1 根据 PAC
13、E 方法论制订的新产品开发流程51.2.2 ISO 9000 族质量管理体系国际标准化组织（ISO）为了满足国际经济交往中质量保证活动的需要，在总结各国质量保证制度经验的基础上，经过近十年的工作，于 1987 年发布了 ISO 9000 质量管理和质量保证标准系列。1994 年进行了第一次修订，形成了 ISO 9000 族标准。2000 年再进行了重大修订，发布了 ISO 9000 新标准（2000 版） 。ISO 9000 族标准问世至今，已经被全世界几乎所有行业广泛采纳。人们到商店买东西，随处可见“本产品通过 ISO 9000 质量认证”的标记。 “产品通过 ISO 9000 质量认证”几
14、乎成为上市销售的必要条件。尽管 ISO 9000 族标准已经在各行各业普及，功劳莫大。但是人们在实践中发现 ISO 9000 族标准对低技术的生产企业帮助很大，但是对以研发为主的 IT 企业的帮助比较弱。主要原因如下：（1）ISO 9000 称得上是放之四海皆准的标准，但是适用面越广意味着专业性越弱。一个生产瓜子的小工厂和生成软件硬件系统的企业，都可以采用 ISO 9000 族质量标准。显然前者的成功经验不能套用到后者上。ISO 9000 标准不可能对“软件、嵌入式系统、集成电路”等领域的质量问题有深入的论述，所以它对 IT 企业的质量管理缺乏专业性的指导，其专业程度远远不及 CMM/CMMI
15、。（2）基于 ISO 9000 的质量保证活动，其关注的焦点是“输入、输出”是否符合既定的流程。对于低技术的企业而言，如果“输入、输出”都符合既定的流程，那么基本可以断定产品的质量不错。然而对于高科技企业而言， “输入、输出”都符合既定的流程并不意味着能够生产出高品质的产品，因为研发水平对产品质量的影响更大。对于“软件、嵌入式系统、集成电路”这类以智力创作为核心的产品而言，ISO 9000 质量标准的指导价值不高。我对“软件、嵌入式系统、集成电路”此类研发企业的建议是，学习和应用 ISO 9000 质量标准是有意义的，但是不必费时、花钱去搞 ISO 9000 认证（除非公司策略需要） ，因为业
16、内人士并不看重 ISO 9000 认证。1.2.3 CMM/CMMI1986 年 11 月 ， 美 国 联 邦 政 府 委 托 卡 内 基 梅 隆 大 学 （ Carnegie-Mellon） 软 件 工 程 研 究 所（ SEI） 开 发 一 套 用 于 评 估 软 件 承 包 商 能 力 的 方 法 。 SEI 于 1987 年 9 月 发 布 了 一 套 软 件 过 程 成熟 度 框 架 和 一 套 成 熟 度 问 卷 。 1991 年 ， SEI 将 软 件 过 程 成 熟 度 框 架 发 展 成 为 软 件 能 力 成 熟 度模 型 （ Capacity Maturity Model
17、， CMM） ， 诞 生 了 CMM 1.0。 1993 年 ， SEI 推 出 了 CMM 1.1， 这 是 目 前 世 界 上 应 用 最 广 泛 的 CMM 版 本 。十 几 年 来 ， CMM 的 改 进 工 作 一 直 不 断 地 进 行 。 美 国 国 防 部 希 望 把 现 在 所 有 的 、 以 及 将 被 开发 出 来 的 各 种 能 力 成 熟 度 模 型 ， 集 成 到 一 个 框 架 中 去 。 到 2000 年 ， CMM 演 化 成 为CMMI（ Capability Maturity Model Integration， 能 力 成 熟 度 模 型 集 成 ） 。
18、 CMMI 不 仅 适 合 软 件 ， 而且 适 合 于 软 件 硬 件 结 合 的 系 统 ， 这 是 对 CMM 最 大 的 改 进 。从 20 世纪 90 年代至今，软件过程改进成为软件工程学科的一个主流研究方向，其中CMM 和 CMMI 是该领域举世瞩目的重大成果。 CMM/CMMI 是世界范围内用于衡量软件（硬件）过程能力的事实上的标准，同时也是软件（硬件）过程改进最权威的指南。第 1 章 IT 企业研发管理综述6CMM 将能力成熟度分为 5 个级别，这 5 个成熟度等级为评价机构软件过程能力提供了一个有序的级别，如图 1-2 所示。同时也为机构的软件过程改进工作指明了方向，让人们分
19、清轻重缓急，指导人们一步一步地改进过程能力而不是企图跳跃式地前进。图 1-2 CMM 的 5 个能力成熟度等级人 们 往 往 搞 不 清 楚 CMM 和 软 件 过 程 改 进 的 关 系 ， 将 二 者 混 为 一 谈 。 下 面 作 个 比 喻 来 解 释 ：把“软件过程改进” 比喻为“ 学英 语，提高英语能力”，那么 CMM 就好比是“英语等级评估标准（考试大纲）”。一般情况下，英 语等级考试的成 绩反映了英语能力。但是，在特别擅长应试的中国，英语 考试成绩很好并不见得英语 能力很好，甚至 可能差到“哑巴英语”的程度。这种“特性”传染到软件领域，不少企业虽然通过了高级别的CMM 等 级评
20、估，但是其实际能力却非常底下低下。软件过程改进的真正目的是提高机构的软件过程能力，而不是为了达到 CMM 高等级。 “汝果欲写诗，功夫在诗外” ，这是很好的启示。2000 年至 2003 年，我在上海贝尔有限公司负责 CMM/CMMI 的研究和推广工作，公司的每个事业部都有软件（硬件）过程改进人员。公司在 CMM/CMMI 过程改进方面的投入巨大，取得一些成效，但是没有达到我的期望值。感慨很多，一言难尽。此处，我对 CMM/CMMI 过程改进做个简要的评论，供同行企业参考。一、 CMM等级评估：从狂热回归理性2000 年2003 年是国内 IT 企业搞 CMM 等级评估最狂热的时期，主要原因有
21、：（1）2000 年，CMM 刚刚在国内兴起，感兴趣（学习、研究）的人非常多。近几年国内出版了不少关于 CMM、软件过程改进的书籍，相关论坛、会议也比较多。有良好的群众基L1 初始级L2 可重复级L3 已定义级L4 已管理级L5 优化级持续改进的过程可预测的过程标准、一致的过程有纪律的过程L1 初始级L2 可重复级L3 已定义级L4 已管理级L5 优化级持续改进的过程可预测的过程标准、一致的过程有纪律的过程7础。（2）那个时候 ISO9000 认证已经被国人搞臭了，而当时国内 CMM 等级评估还很少见，企业达到 CMM 2 级、3 级是很荣耀的事情。物以稀为贵，人们把认证的目光从 ISO900
22、0 转向了 CMM。（3）为了扶持当地软件企业，鼓励软件出口，各地方政府相继出台了“资助企业搞CMM 等级评估的政策” 。最先搞 CMM 评估的企业得尝到了甜头，自己拿到了比较吃香的CMM 等级证书，昂贵的评估费用大多由政府支付了。这一剂催化剂，进一步激发了企业搞CMM 评估的热情。2000 年2003 年期间，国内有数百家企业通过了 CMM 2 级、3 级评估，大部分企业搞CMM 评估是 “为了拿证书” 而不是“真正提高软件过程能力” 。到 2004 年，国内 CMM 评估从狂热回归理性。主要原因有：（1）地方政府基本上不再资助企业搞 CMM 等级评估了。企业自己掏钱搞 CMM 评估就舍不得
23、了，要掂量是否值得（理性的表现） 。（2）由于国内通过 CMM 2 级、3 级评估的企业已经很多，而且评估时“放水”现象严重，CMM 评估的声誉已经大不如 2000 年。（3）最让人们失望的是，虽然有些企业通过了 CMM 2 级、3 级评估，但是实际的软件过程能力却依然底下。有些企业实施 CMM 后，质量没有明显提高，进度更落后了，成本增加了，人员更累了。现在软件业界普遍关注的是：企业如何以比较低的代价有效地提高软件过程能力。CMM等级评估则退居次要地位。二 、 CMM的盲区和常见应用问题用 CMM 指 导 企 业 的 软 件 过 程 改 进 工 作 是 相 当 不 错 的 ， 但 是 企 业
24、 要 做 的 重 要 事 情 显 然 不 仅是软 件 过 程 改 进 。 企 业 最 关 注 的 是 生 存 和 发 展 问 题 ， 一 切 离 不 开 赚 钱 。CMM 本 身 不 谈 如 何 赚 钱 的 问 题 。 它 假 设 了 美 好 的 前 提 条 件 ， 即 企 业 有 充 足 的 人 员 、 资 金 、时 间 从 事 软 件 过 程 改 进 ， 当 软 件 过 程 能 力 提 高 了 ， 那 么 产 品 的 质 量 、 生 产 率 自 然 上 去 了 （ 同 时 成本 也 下 降 了 ） ， 企 业 自 然 能 够 获 取 更 多 的 利 润 。 软 件 过 程 改 进 对 企
25、业 经 济 效 益 的 贡 献 是 间 接 的 ，从 投 入 到 产 出 ， 时 间 相 对 比 较 长 。遗憾的是，国内大部分企业没有能力提供那么好的前提条件，企业最缺乏的资源往往就是人员、资金和时间，企业领导当然想把资源用在“刀刃”上，即赚钱最多最快的地方。当软件过程改进和其它直接赚钱的事情“发生资源冲突”时，人们只好“拆东墙，补西墙” ，往往减少软件过程改进的资源。如果人们完全按照 CMM 的要求遍历“18 个关键过程域和百余个关键实践”的话，无疑会占用大量的资源，资源冲突在所难免，失败的风险很高。所以人们切勿照搬 CMM，一定要根据企业的实际情况（企业发展战略、产品特征、资源状况）给出
26、软件过程改进的措施。CMM 对软件项目管理和机构过程管理论述很深入，但是对软件开发的核心工作即“需求开发、软件设计、编程、测试、维护”论述非常少，CMM 把它们压缩为一个过程域叫做第 1 章 IT 企业研发管理综述8“产品工程” （Product Engineering） ，近乎一笔带过。所以导致一个怪现象，管理人员们觉得CMM 真是好，而大量开发人员学了 CMM 后却很是迷惘，感觉 CMM 对他们的开发工作没有直接的指导。CMM 方法论有个明显的倾向，即 “管理的规范化”重于“开发的规范化” 。CMM 2 级的 6 个关键过程域全部是论述项目管理的，而唯一论述“需求开发、软件设计、编程、测试
27、、维护”的“产品工程”关键过程域则放在 CMM 3 级。对 于 国 内 大 多 数 软 件 项 目 而 言 ， 技 术 开 发 占 总 工 作 量 的 80 以 上 ， 而 项 目 管 理 占 总 工 作 量的 20 以 下 ， 因 为 企 业 销 售 的 是 软 件 产 品 ， 而 不 是 管 理 。 明 眼 人 都 看 得 出 ， 技 术 开 发 的 规 范 化要 比 项 目 管 理 的 规 范 化 尤 为 重 要 与 迫 切 （ 至 少 也 是 同 等 吧 ） 。由于 CMM 强调过程改进要循序渐进，不要跳跃式前进。人们自然而然地会先把精力集中在 CMM 2 级的 6 个关键过程域上，而
28、忽视了技术开发的规范化，这显然是误导。如果这样做的企业通过了 CMM 2 级评估，然后声称他们能够把产品做得又快又好，无疑是自欺欺人。三、对应用 CMM/CMMI的建议在软件过程能力比较低的企业里，经常会发生项目开发过程混乱、产品质量低下、进度延误、成本高昂等问题。一批人马累死累活地做完产品后，马上又因质量问题被折腾得焦头烂额。这种现象反反复复地发生，让人疲惫不堪。有远见的企业领导应当下决心去改进软件过程能力。提高软件过程能力实际上就是“练内功” ， “练内功”没有捷径可走，唯有走“规范化”之路。即：制定适合于本企业的软件过程规范，并按照此规范执行。CMM 是衡量企业软件过程能力的国际标准，它
29、对软件过程改进有很多有益的指导。CMM 仅仅对等级评估做了强制要求，但是对企业“如何进行软件过程改进”没有强制要求，CMM 的数百页文本并不是“ 放之四海皆准”的，企业可以采纳也可以不采纳。对于软件过程改进而言，CMM/CMMI 和 ISO 等等都是用来参考的，而不是用来迷信的。企业在参考业界推荐的标准或规范时，要舍弃那些听起来很先进但是对本企业无益处的东西，只选取对企业有实用价值的东西。1.2.4 项目管理知识体系（PMBOK）项 目 管 理 协 会 （ Project Management Institution， PMI） 于 1966 年 在 美 国 宾 州 成 立 ， 是 目 前 全
30、球 影 响 最 大 的 项 目 管 理 专 业 机 构 ， 该 机 构 的 项 目 管 理 专 家 认 证 （ Project Management Professional， PMP） 被 广 泛 认 同 。 PMI 的 突 出 贡 献 是 总 结 了 一 套 项 目 管 理 知 识 体 系 （ Project Management Body Of Knowledge， PMBOK） 。PMBOK 总结了项目管理实践中成熟的理论、方法、工具和技术，也包括一些富有创造性的新知识。PMBOK 把项目管理知识划分为九 9 个知识领域：综合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、
31、沟通管理、风险管理和采购管理。每个知识领域包括数量不等的项目管理过程。9PMBOK 把项目管理过程分为五 5 个阶段：（1）启动。开始项目或进入项目的新阶段。启动是一种认可过程，用来正式认可一个新项目或新阶段的存在。（2）计划。定义和评估项目目标，选择实现项目目标的最佳策略，制定项目计划。（3）执行。调动资源，执行项目计划。（4）控制。监控和评估项目偏差，必要时采取纠正行动，保证项目计划的执行，实现项目目标。（5）结束。正式验收项目或阶段，使其按程序结束。每个管理过程包括输入、输出、所需工具和技术。各个过程通过各自的输入和输出相互联系，构成整个项目管理活动。根 据 重 要 程 度 ， PMBO
32、K 又 把 项 目 管 理 过 程 分 为 核 心 过 程 和 辅 助 过 程 两 类 。 核 心 过 程 指 那些 大 多 数 项 目 都 必 须 具 有 的 项 目 管 理 过 程 ， 这 些 过 程 具 有 明 显 的 依 赖 性 ， 在 项 目 中 的 执 行 顺 序也 基 本 相 同 。 辅 助 过 程 指 那 些 是 视 项 目 实 际 情 况 可 取 舍 的 项 目 管 理 过 程 。 在 PMBOK2000 中 ，核 心 过 程 共 17 个 ， 辅 助 过 程 共 22 个 。PMBOK2000 一共有 39 个项目管理过程，按所属知识领域分为九 9 类，按时间逻辑分为五类，
33、按重要程度分为两类。如表 1-1 所示，其中斜体为辅助过程。表 1-1 PMBOK 项目管理过程一览表第 1 章 IT 企业研发管理综述10启动 计划 执行 控制 结束综合管理 项目计划编制 项目计划执行 综合变更控制范围管理 启动 范围规划范围定义 范围审核范围变更控制时间管理活动定义活动排序活动周期估计进度安排进度控制成本管理资源计划成本估计成本预算成本控制质量管理 质量计划 质量保证 质量控制人力资源管理 组织计划人员获取 团队建设沟通管理 沟通计划 信息分发 绩效报告 行政收尾风险管理 风险管理计划 风险识别定性风险分析定量风险分析风险响应计划风险监控采购管理 采购计划招标计划招标选择
34、供应商合同管理合同收尾PMBOK 和 CMM/CMMI 对比简评：CMM/CMMI 论述的项目管理方法仅仅适用于软件项目，但是不适用于其它行业的项目管理。PMBOK 论述的方法适用于任何行业的项目管理，但是对软件项目管理而言，PMBOK 的针对性不够强 。CMM/CMMI 不 仅 论 述 软 件 项 目 管 理 ，而 且 论 述 整 个 机 构 的 软 件 研 发 管 理 。PMBOK的 方 法 局 限 于 项 目 管 理 ，对 于 企 业 研 发 管 理 则 不 够 用 。CMM/CMMI 基本上不谈“成本管理”和“ 人力资源管理”，它先假设机构有充足的资金和人力资源，通常不切合企 业实际情
35、况。因此 PMBOK 的“成本管理”和“人力资源管理”可以弥 补 CMM/CMMI 的不足。建议：对于软件机构研发管理或者软件项目管理，采用 CMM/CMMI 为主导的方法论，并结合 PMBOK 的知识，取长补短。111.2.5 敏捷开发思想2001 年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭，一批业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟（Agile Alliance） 。他 们 起 草 了 一 个 旨 在 鼓 励 更 好 的 软 件 开 发 方 法 的 宣 言 ， 称 为 敏 捷 联 盟 宣 言 （ The Manifes
36、to of the Agile Alliance） ， 如 表 1-12 所 示 。 然 后 在 该 宣 言 基 础 上 制 定 了 12 条 原 则 用 于 指 导 实 践 。 该 宣言 和 12 条 原 则 是 敏 捷 软 件 开 发 方 法 的 核 心 。表 1-2 敏捷软件开发宣言我们正在通过亲身实践和帮助他人实践，揭示了更好的 软件开发方法。我们认为： 个体和交互 胜过 过程和工具 可以工作的软件 胜过 详尽的文档 与客户合作 胜过 合同谈判 及时响应变化 胜过 遵循计划虽然右项很有价值，但是我 们认为 左项有更大的价值。Kent Beck James Grenning Robert
37、 C.MartinMike Beedle Jim Highsmith Steve MellorArie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff SutherlandWard Cunningham Jon Kern Dave ThomasMartin Fowler Brian Marick 敏捷软件开发的 12 条原则如下：（1） 我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 （2） 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。（3）（3
38、） 表 1-1 敏捷 软 件开 发 宣言（3） 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 （4） 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 第 1 章 IT 企业研发管理综述12（5） 围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 （6） 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 （7） 可以工作的软件是首要的进度度量标准。 （8） 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 （9） 不断地关注优秀的技能和好的设
39、计会增强敏捷能力。 （10） 简单把无需做的工作最大化的艺术是最根本的。 （11） 最好的构架、需求和设计出于自我组织的团队。 （12） 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 人们在敏捷软件开发宣言和 12 项原则的指导下，创作了更多的富有特色的开发方法和最佳实践。例如“敏捷的面向对象设计” ，请参考 Agile Software Devolopment : Principle, Patterns, and Practices, Robert C. Martin 著，中译本为敏捷软件开发：原则、模式与实际 。例如“敏捷建模” ，请参考 Agi
40、le Modeling: Effective Practices for extreme Programming and the Unified Process, Scott W. Amber 著，中译本为敏捷建模：极限编程和统一过程的有效实践 。本文作者的观点如下：敏捷软件开发的宣言和 12 条原则并非普遍适用。我大约赞同 60，我和软件人员交流的时候，有时会引用其中的原则，感慨甚多，忍不住拍案叫好。但是约有 40%的内容我并不认同，主要原因是“过于理想化、绝对化，不适合国情” 。我认为“宣言”中的左右 4 项都很重要，但是不能绝对地说左边 4 项“胜于”右边 4 项，这是“一刀切”的结论，
41、没有考虑成千上万企业的具体情况。上述 12 项原则中的（2） 、 （4） 、 （5）项，看似很好，但是不符合中国软件机构的普遍现状，实际上可能行不通。我个人比较赞同的是（1） 、 （3） 、 （6） 、 （7） 、 （12）项。敏捷开发方法表达了“简单、快速、实用”的软件开发思想，它不是成熟的理论、也不是事实上的标准（不象像 CMM, 、PMBOK 那样具有严密的理论体系，被企业广泛接受） 。即使人们认同某些原则，但是不同的人往往有不同的理解，实践差异很大。敏捷开发方法对于提高个人、小型团队的工作效率是很有帮助的（如果用对了的话） 。但是企图用它指导大型、中型软件机构的研发管理是有很高风险的，它的某些主张是局部观点而不是全局观点，如果把握不好分寸的话可能导致整体混乱，而“整体的混乱”会淹没“局部的好处” 。作者研制的“精简并行过程（SPP） ”的理论基础是“经典软件工程、 CMM、PMBOK” 。11为了提高效率，在局部地方借鉴了“敏捷软件开发的思想” ，用于裁减过于冗长、笨重的过程规范。
