需求开发与需求管理指南

《需求开发与需求管理指南》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

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