第1章 IT企业研发和管理综述.doc

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