软件项目管理的理论与实践_软件项目管理综合实践

软件项目管理的理论与实践由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“软件项目管理综合实践”。

软件项目管理的理论与实践

摘要：本文在探讨CMM/CMMI、敏捷编程等相关理论的基础上，结合软件开发实践，提出了平衡敏捷与纪律的软件管理思想，并探讨了融合敏捷与CMM/CMMI的最佳实践。

关键词：CMM/CMMI，敏捷当CMM遭遇敏捷

本世纪初，在国务院18号文件《鼓励软件产业和集成电路产业发展的若干政策》的推动，以及鼎新、东软等先驱软件企业的带动下，国内掀起了一阵CMM风暴（CMM于2000年升级为CMMI，文中在不特别针对某个具体版本时，使用CMM泛指CMM/CMMI），软件企业的CMM/CMMI评估形成了一股席卷全国的潮流。据CSDN统计，截止到2010年9月，我国通过CMM/CMMI评估的企业已达到1300家，全球排名第二。一时之间，CMM似乎成为了衡量软件企业开发能力的唯一标准，成了发展我国信息技术行业的银弹。然而，自2005年开始，一些有识之士就已经认识到CMM的局限性，纷纷撰文提出质疑。目前，随着越来越多软件企业CMM神话的破灭，CMM已经完全走下神坛。现在打开百度，搜索CMM的相关内容，除去概念、介绍性的文章外，对其持否定态度占了绝大部分，继续力挺CMM的文章几乎绝迹。由此可见，中国的软件界已经从CMM的狂热阶段转入理性阶段。

在CMM由盛转衰的同时，以强调人本、效率为核心的敏捷思想开始悄然兴起。从Kent Beck的极限编程（eXtreme Programing，简称XP）和敏捷联盟的敏捷宣言中，中国程序员开始听到CMM外的声音。而随着Martin Fowler、Robert Martin等敏捷大师登陆中国，数届敏捷大会在北京召开，整个中国软件界掀起了一股以务实、高效、简约为特征的敏捷风。目前，软件行业的媒体、杂志上，充斥着介绍XP、Scrum等敏捷方法的专题文章，秉承敏捷思想进行管理的软件企业随处可见，敏捷成了过程改进的最热门话题。

面对CMM的盛极而衰和敏捷的方兴未艾，我们不禁要问：CMM到底怎么了？敏捷真的适合我们吗？我们该何去何从？CMM怎么了

我第一次接触CMM是2000年。在此之前，我一直试图寻找一套软件开发标准，曾经学习过GB 85-88和IEEE-830、IEEE-12207等软件工程标准，但一知半解，远没有形成一个系统化过程的概念。CMM的丰富、广博确实让我眼前一亮，好象打开了一面通向世界软件技术的窗户，看到了从未想象过的世界。但是，CMM那些繁复的规定和要求，又让我望而却步，“可远观而不可亵玩焉”。2002年，在信产部政策的推动下，各地方政府纷纷出台了奖励政策，稍具规模的软件公司，都在跃跃欲试地准备CMM评估，CMM才真正走到我们面前，虽然当时还不完全了解CMM到底能带给我们什么。

其后几年，CMM/CMMI成了我工作的一部分，我对它有了更深刻的了解。可以说，CMM是中国软件行业规范化的启蒙者。CMMI-DEV 1.2的22个PA、48个特定目标、165个特殊实践，覆盖到了软件开发和管理的方方面面，让我们真正了解到什么是软件管理。每个职业软件人，无论是开发者还是管理者，都有必要了解、掌握这些内容。作为一个指导软件企业过程改进的框架，CMMI提供了阶段型和连续型两种方法论，并通过5个通用目标、17个通用实践，清晰地描绘了一条软件企业走向成熟的路线。比如CMMI-DEV 1.2 Ⅱ级的目标，就是“管起来”，无论你用什么方法，只要把计划、度量、需求、配置、质量保证等内容管起来，就认为是达到了Ⅱ级。当Ⅱ级积累到一定程度，认为各项目间有必要共享各自的经验的时候，就可以向Ⅲ迈进了。遗憾的是，我们在引进CMM的过程中，犯了急功近利的毛病，囫囵吞枣，没有真正按照框架的精神踏踏实实地进行过程改进，导致了CMM的水土不服。究其原因，我觉得问题应该出在以下几个方面：

1.CMM的移植问题。CMM起源于美国国防部和国家宇航局，所针对的都是大型项目。这些项目失败的成本巨大，对软件质量要求非常之高，因此，对过程的精细程度要求非常之高。在制定模型时，为了做到方法的完备性，所制定的过程框架又涵盖了各种情形，使过程模型更加复杂化。在移植到中国后，由于评估时间等的压力，我们并没有充分地消化CMM的精髓，没有考虑我们企业所能承受的成本，没有根据项目的实际情况进行有效裁剪，而是僵化地全套照搬，建立了过于复杂的管理流程，形成了大量面面俱到却无人问津的过程制品，反倒失去了对项目核心的掌控，导致生产效率降低，产品质量下降。而过程改进人员又普遍脱离了开发实践，CMM成了教条，使开发人员产生了反感情绪。

2.CMM缺少工程方法。CMM是一个能力标准，只讲要做什么，却没讲怎么做。例如CMMI-DEV 1.2 Ⅱ级的7个PA，全部是项目管理的内容，基本未提及工程方法。CMMI-DEV 1.2 Ⅲ的11个PA，虽然涉及到RD、TS、PI等技术领域的内容，但只提了宏观要求，并未涉及细节。这种设计方式，是因为CMM的创建者假定软件企业已经具备了适合本企业的、完整有效的软件工程方法论。我国企业在引进CMM前，基本上还没有形成自己的软件过程和文档体系，而是寄希望于CMM来改善这种情况。在CMM实施中，又普遍存在重管理轻技术的观点，忽视了企业资产的建立，通常是照办咨询公司提供的模板，没有进行有效的本地化，没有认真探索适合自身的工程方法，从而导致管理先进、技术落伍的不良状态，也从根本上违背了CMM“过程改进”的基本思想。

3.CMM不适合小型项目。CMM起点很高，对各个环节要求极严，是真正的重量级方法。对周期短、回报小、资源不足的小型项目来说，使用CMM的成本太高，可以说是得不偿失。这一点，在CMM刚刚进入中国时，SEI的专家们曾反复声明，CMM的创始人Watts Humphrey老先生也一再强调。在CMM之后，Humphrey先生又建立了用于小规模团队的TSP（Team Software Proce）模型和用于个人的PSP（Personal Software Proce）模型，作为CMM的补充。在为波音公司的IT部门进行CMM咨询时，Humphrey先生根据各部门的实际情况，分别制定了实施CMM Ⅲ、CMM Ⅱ、TSP、PSP的不同方案。由此可见，CMM并不是放诸四海而皆准的银弹，无论是公司还是项目，选择CMM，都应该根据自己的实际情况进行理性的选择，而不应该生搬硬套，以命令的形式强制推行。反过来，如果选择了CMM，就要提供足够的资源，否则就会事与愿违，反倒降低效率，影响产品进度和质量。

4.CMM的知识更新问题。CMM初稿是在1986年提出的，87年正式发布1.0版。它的基本内容，都是基于瀑布模型设计的。按照《人件》和《最后期限》的作者Tom DeMarco的说法，“CMM 已经有超过 20 年的历史，它的成功经验都是在 1985 年前获得的。CMM 试图将一个固定的模型强加于一个日新月异的行业之上，它鼓励你效仿 IBM 在 1970 年代所采用的软件开发方式。僵化，不敢面对变化，这是如今的软件业最忌讳的。”2006年8月发布的CMMI-DEV 1.2版本，开始寻求对这一局限进行突破，但是进展甚微。例如，目前迭代式开发已经被公认是先进的开发组织模式，可以有效应对变化。而CMM在某些方面却限制了迭代的应用。比如里程碑式的需求评审、设计评审，就是典型的瀑布模型的影响，与迭代方法中随着开发的深入逐步获取需求的思路完全矛盾，造成了两者的冲突，客观上限制了基于迭代的新式工程模型的应用。

5.实施过程中理论和实际的脱离。国内的CMM实施，最头疼的就是找不到合适的SEPG和QA人选。按照CMM的思想，SEPG和QA应该来自具有丰富开发经验的技术人员，能在开发过程中得到软件人员的尊重，并给予全方位的指导，从而得到客观的洞察力。而我们的软件企业通常比较年轻，人才积累少，SEPG和QA的软件经验普遍不足，兼之过于追求理论上的完美，不注重跟踪过程执行情况，不注重收集反馈信息，导致我们的流程、制度脱离开发实际，引起开发人员反感。正如软件界泰斗Boehm博士所说的那样，“过程改进黑暗面的诱惑力是巨大的，实施者们很容易受其诱惑而陷入只追求表面文章的黑暗面之中”。这样的过程改进只注重满足标准，片面追求过程与规范的符合度，脱离了软件开发实践，忽略了实践对理论的验证、反馈，违背了过程改进的初衷，偏离了提高效率、提高软件质量的根本目标。敏捷的特征

以CMM为代表的传统意义上的软件方法学描述，通常“能够”处理任何大小的项目，而实际上真正的困难就来自于如何对这些方法加以裁剪以适合较小的项目。针对这种理论与实际的脱节现象，敏捷方法应运而生。相对于CMM这样的重量级方法，敏捷方法常被认为是“轻量级”方法。敏捷的倡导者认为，软件产品开发无法一开始就能定义产品最终的规程，开发过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。开发团队应有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

相对于传统方法，敏捷方法更重视“人”在软件研发中的作用，重视效率，重视对变化的积极响应，倡导迭代式开发，反对机械地盲从既有过程，反对面面俱到、堆积如山却无人问津的文档。自1996年敏捷先驱Kent Beck提出极限编程思想后，敏捷方法得到了广泛响应，敏捷爱好者于2001年成立了敏捷联盟，并发表了敏捷宣言：

 注重个人及互动 胜于 过程和工具  注重可用的软件 胜于 详尽的文档  注重客户协作 胜于 合同谈判  注重响应变化 胜于 恪守计划

2002年后，敏捷方法得到了迅猛发展。其中影响至深、波及至广的当属极限编程（XP）和Scrum方法。

极限编程是敏捷理论的先驱，“极限”的含义是将在开发中总结的最佳实践发挥到极至。例如，如果你认为迭代是好的，那么就将迭代的周期压缩至最小，甚至几天、几小时一次迭代。严格来说，极限编程并不是一套完整的方法论，而是一组核心理念和一套最佳实践的组合。XP倡导沟通、反馈、简单、勇气四个核心价值观，主张项目的设计、结构要保持简单，要注重沟通和用户反馈，要有勇气接受变化、重构代码。XP提出了项目计划（The planning game）、小版本（Small releases）、隐喻（Metaphor）、简单的设计（Simple design）、重构（Refactoring）、测试驱动（Test-driven）、结对编程（Pair programming）、代码共享（Collective ownership）、持续集成（Continuous integration）、不加班（40-hour week）、现场客户（On-site customer）、编码标准（Coding standards）等十二个核心实践，其中重构、测试驱动、小版本（迭代）、持续集成等实践已经成了敏捷思想的核心，被现代软件工程理论广泛接受。XP作为敏捷方法的先驱，最大贡献是为敏捷方法提供了大量基础实践。它的基本思想被各种敏捷方法广泛接受、继承，为敏捷的盛行奠定了基础。

Scrum方法的名字取源于英式橄榄球争球队，其用意就是要把体育比赛中那种团结、拼搏的精神施加于软件团队。和XP相比，Scrum提供了更具体的工程管理机制，从而使Scrum的可操作性更强。这也是近年来Scrum方法盛行的原因。Scrum方法的核心，是将开发过程分解为一系列小的迭代，每次迭代称为一个Sprint（冲刺）。每个Sprint通过计划会议明确任务，通过每日例会掌控进度、问题，通过评审会议总结成果。如此反复，经过一系列可控的“冲刺”，最终达成项目目标。其基本流程描述如下：

1.列举可以预知的所有任务，包括功能性和非功能性任务，形成所谓Backlog。2.将整个产品的Backlog分解成一系列Sprint Backlog，这个Sprint Backlog是按照目前的人力物力条件可以完成的。3.召开Sprint计划会议，划分、确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。Sprint的任务是以小时计算的，并不是按人天计算。

4.进入Sprint开发周期，在这个周期内，每天需要召开15分钟的每日Scrum例会。5.整个Sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner。该会议为外部会议，邀请干系人参加，一般不超过4小时。

6.团队成员最后召开Sprint retrospective meeting，总结问题和经验。该会议为内部会议，时间不超过3小时。

7.这样周而复始，按照同样的步骤进行下一次Sprint。

无论是XP还是Scrum，其基本思想都是互通的。它们所倡导的最佳实践，看似一个个独立活动，实际上具有很高的耦合度，不能孤立地执行。例如，XP的共享代码权，如果没有编码标准、结对编程作为基础，是很难实现的；小版本没有重构作为保障，会导致结构的混乱；Scrum的每日例会，要以“站立会议”的方式进行，以保证效率；Scrum的Sprint要以持续集成、重构等实践作为保证，否则无法维护产品的完整性和可靠性，等等。

敏捷以一种充满活力的方式，挑战了传统软件工程思想的沉闷，激起了全球软件人员的强烈反响。然而，任何事情都有其不利的一面，敏捷也是如此。敏捷无法管理大型项目，即使对比较适合敏捷的中小项目来说，敏捷也有自身的弱点，例如：

1.敏捷过于依靠个人素质和Team leader的领导能力，因此在团队成员较新，缺乏足够的经验、技巧和敬业精神时，敏捷会失效；

2.敏捷经常会被误解成不写文档。事实上，敏捷反对的只是面面具到、求全责备的文档和过程，而不排斥必要的文档。例如XP的12个核心实践，就提到项目计划、隐喻和简单的设计三个涉及文档的活动。敏捷只是提倡用一种更直接、更轻量、更易于理解的方式编写文档，而不是一概否定文档。

由此可见，以CMM为代表的传统方法和敏捷思想实际是事务对立统一的两个方面。传统方法强调过程、强调纪律，而敏捷方法强调个体、强调创造。如果将两种思想有机结合起来，取长补短，达到平衡，就能找出更合适的过程改进之路。平衡敏捷与规范

在敏捷与传统为谁是谁非的问题争论的不可开交的时候，一些有识之士已经在考虑两者的融合。其中比较有代表性的一位，是以创造了COCOMO模型、螺旋模型和经典名著《软件工程经济学》而闻名的Boehm博士。Boehm博士在2003年出版了《Balancing Agility an Discipline》一书，对平衡敏捷和规范的问题进行了详细的论述。该书的中文版《平衡敏捷与规范》也已经于2005年由清华大学出版社出版。可见，平衡敏捷与规范，已经是被国内外学者所认同的发展之路。敏捷与规范之争，大致可以归结为以下两个方面：

1.人与过程孰重孰轻之争，或者软件到底是“工程”还是 “艺术”之争； 2.质量尺度的把握，或者说，需要为质量付出多少成本。

人与过程之争，焦点是软件开发过程创造性的地位问题。CMM把软件开发过程看作一个工程过程，希望利用在制造业等传统行业中获得的经验来管理软件开发，对开发中的“个人英雄主义”行为持明确的否定态度，倍加推崇正确的过程、严格的工序和绝对的纪律。而敏捷方法的核心就是强调发挥个人或团队的创造性，主张按照项目特点选择过程。在敏捷专家看来，没有什么规范是固定不变的，所有过程都由人而定，都是为项目成功服务的。敏捷和规范各有所长，以CMM为代表的规范过程更适合需求明确的大型项目，而敏捷更适合具有挑战性的研究项目。

质量尺度的把握。CMM强调质量至上，不会因为效率牺牲质量。敏捷强调效率，一些敏捷方法提出了“满意质量”的概念。满意质量基于“任何事情都带来成本，而我们所想要的总是超过我们的支付能力；质量在本质上是有条件的和主观的；为了在软件方面达到完美，我们不得不解决许多困难问题、达成许多折衷和解决相互冲突的价值，完美不会很容易或机械性地实现”的基本前提，提出了满意质量的定义：（1）可带来足够的利益；（2）不存在致命性问题；（3）所带来的利益超过问题所造成的损失；（4）在当前条件下综合考虑所有因素后，进一步的改进所带来的损害大于其带来的帮助。满意质量否定了质量至上的观念，说明了敏捷思想更加务实的价值观。应该说，CMM的质量目标更适合作为一种文化或信念，而满意质量是对质量目标更理性的思考，更具有说服力和实用性。

敏捷强调个体、强调效率，但同时对个体素质要求较高，局限性较大。而CMM强调过程，强调质量，更适合于简单、重复的生产活动，很难应付复杂多变的情况。事实上，敏捷与规范正是软件开发过程中两个不可或缺的方面。过分强调自由，开发过程就会失控，回到软件危机前的“混沌”状态；而过分强调规范，又会导致僵化，扼杀人的主动性和创造力。因此，软件管理的目标，就是平衡敏捷和规范的矛盾，使开发活动高效、有序地进行。对已经通过了CMM/CMMI评估，但仍希望持续改进的软件企业，我觉得最直接的平衡方法，是用敏捷的观点重新审视既有规范，用效率观点重新评价各种管理活动，逐步剔除其僵化、低效的部分，最终达到平衡。具体方法可概括如下。

1.对项目分类进一步精细化，提供更丰富的生命周期模型，并提供与之相适应的模板和规范要求，使之能够尽量适应不同类型项目的情况。通过CMM/CMMI评估的企业所采用的流程规范，大多是继承自咨询公司提供的模板。虽然在改进过程中有适当裁减，但并未真正接受实践的检验，而且普遍不能支持新的生命周期模型。要想让规范更好地支持开发过程，帮助企业提高开发效率、产品质量，就应该不断吸纳新知识、新思想，不断建立新模型，使企业资产库不断得到扩充。另一方面，企业资产库对开发部门应该是开放的。开发人员是推动企业知识更新最积极的因素，管理人员应该积极支持、帮助、配合项目组使用创新方法、过程，认真跟踪、观察新方法的执行效果，及时总结经验教训，将新方法及时合并到企业资产库。

2.提供更灵活的裁减条件，减少不必要的中间环节，给予项目经理更多的控制权限。任何过程都有其局限性，而每个项目都有其特殊性，不可能通过机械地复制既有过程就达到复制成功的目的。这一点，SEI的专家也是认同的，CMM的Ⅱ级命名为“可重复级”，升级到CMMI时更名为“管理级”，就隐含了这个道理。软件不同于简单的生产加工活动，是一个充满挑战和创造性的工作，软件管理也不可能完全照搬企业管理的经验，而必须强调“人”，特别是项目经理在整个过程中的主导作用。给予项目经理更多的控制权限，尤其是过程裁减的权限，更有利于发挥项目经理的聪明才智，引导项目走向成功。这是敏捷思想的精髓所在。对开发过程中的管理活动，要深入分析其对具体项目的作用，才能作出是否需要的合理判断。以专家评审为例。理论上，专家评审可以集中专家的智慧，对开发活动肯定是有益的。但某些企业由于环境、业务复杂度、技术复杂度、人际关系等等原因，专家可能不愿意或没能力提供有效意见，这样评审就不能达到预期目的。如果评审成了走过场，就要引发深度思考，考虑评审所带来的收益是否大于付出的成本，并决定是否裁减评审活动了。裁减的最终决策权应该交给项目经理，而不是SEPG人员。因为项目经理要对项目总体负责，只有他最了解、最关注项目的成本、进度、质量，其它人员的意见都具有局限性、片面性。

3.管理体制要从实践中来，到实践中去。所有针对软件开发的管理活动，都是为了让开发工作更有效、更可靠、更可控，都是为开发服务的。敏捷的最大魅力，就是所有最佳实践都是来自于开发活动的，所以才会得到开发人员的广泛拥戴。因此，管理制度的制定，尤其是过程、文档模板的制定，要坚持实践是检验真理唯一标准的原则，坚持从开发实践中总结经验，积累财富。要杜绝闭门造车式的过程改进，无论多么完美的理论，都要经过实践检验后，才能验证其正确性。软件管理人员必须具备软件开发经验，并不断深入开发实践，体会规范的实际运用效果。管理规范要经过实践检验后才能形成制度，并且要考虑是否能为开发人员所接受，所增加的管理成本是否物有所值等因素。如果脱离了实际，制度就会僵化，变成阻碍开发工作的束缚，达到适得其反的目的。

4.发现问题，量体裁衣，逐步实现过程改进。罗马不是一天建成的，任何进步都要有一个普及、接受、适应的过程。CMMI 的组织过程焦点（OPF）明确地列举了组织过程改进的方法。在CMM实施阶段，由于时间的压力，企业可能没有真正按照CMM的精神来实施过程改进，急于求全、求大，或多或少地存在制度与实际两层皮的情况。要改变这种状态，应该坚持持续改进的精神，改进要按照OPF的要求，评价组织过程，发现最薄弱环节，找出最紧迫的过程改进需要，制定改进计划，实施过程改进。按照这种方式，即使每次改进仅完成一个PA，只要真正落到实处，就会取得实际的进步。如此反复，企业就会得到真正的发展。如果违背了这个规律，一味求大求全，浮于表面，过程改进可能永远是一句空话。5 平衡管理与技术

在平衡敏捷与规范的讨论中，还有一个不容忽视的问题，就是平衡管理与技术的关系。软件是一个技术密集型行业，是一种纯脑力劳动，技术对于项目成功的重要性，是不庸质疑的。在CMM登陆之前，我们普遍存在重技术、轻管理的现象。CMM作为一个管理框架，重点在于强调管理，正是对片面强调技术的纠正。然而，随着CMM思想的不断深入，又难免产生矫枉过正的情况，反倒让软件企业忘记了立身之本，忽略了技术的地位，造成管理至上的错误。管理与技术孰轻孰重？如何摆正管理与技术的关系？要想平衡管理与规范，这些问题都是不可避免的。

1.软件开发活动中技术的地位问题。软件不同于传统企业，软件产品的形成过程，主要依靠人的思维活动，是看不见、摸不着的。管理的目的，是为了引导人的思维活动按正确的方式发展，但是决不能替代人的思维。有人说，产生文档的根本原因，来自于项目经理的恐慌，因为项目经理无法感知、控制软件项目的进度和质量，只能依赖文档来进行监控。如果忽视了技术、技能的培养，忽视了软件人员的素质建设，思维就失去了基础，仅仅依靠管理、纪律，是不可能获得成功的。尤其在客户要求日益复杂、技术日新月异的今天，技术的重要性越发突出。一个良好的设计思路、技术决策，往往是觉得项目成功的关键。因此，应该正确认识技术在软件活动的地位，尊重知识，尊重技术，让管理为技术服务。

2.客观分析企业的状态。管理和技术是保证项目成功的两个决定因素，不能偏废。作为企业领导，要实现过程改进，就要客观分析企业的状态，分析清楚企业现在的弱项是管理还是技术，然后再制定相关政策，而不能想当然地片面强调某一方面，加剧不平衡状态。我个人认为，在没有实施任何认证的企业，忽视管理的可能性较大；在通过了ISO9000、CMM的企业，则往往夸大了管理，忽视了技术。

3.客观分析管理和技术的分别。面对企业在开发过程中暴露出来的问题，要进行客观、深入的分析，判断是管理问题还是技术问题，再采取相应措施。比如现在普遍存在的需求失控的问题，从表面上看，是需求开发（ReqD）和管理（ReqM）的问题。但是，如果深入到问题本质，可能会发现，需求变更是不可避免的。那么，就要从架构设计和开发过程方面找问题。例如可以采用组件式开发，让软件易于适应变化；可以使用原型法，让用户尽早看到产品；或者使用迭代式开发，及时规避风险，让产品逐步接近用户目标。如果死钻牛角尖，一味在需求调研、文档、评审上下功夫，就会事倍功半，降低效率。

4.注重技术人才的培养。“盖成非常之事，必待非常之人”。两千年前的汉武帝，就已经认识到人才的重要性。正是因为具有不拘一格用人才的非凡气魄，汉武帝才能挖掘出卫青、霍去病这样的军事天才，建立不世之功。在软件行业，也不乏盖茨、裘伯军、王江民这样以一己之力获得巨大成功的先例。因此，软件研发，尤其是开拓性软件的研发，必须要有大批具有专业知识、超凡能力的“非常之人”。软件企业要具备容纳百川的胸怀，重视技术人才的挖掘、培养，提供钻研技术的环境，打造尊重技术的企业环境，造就技术过硬的拔尖人才，才能提高自身素质，建立企业的核心竞争力，在市场上保持竞争优势。结束语

前文在剖析CMM的利弊的基础上，用敏捷观点重新审视了过程改进的方法，并阐述了软件企业中管理和技术的关系。最后，我们再回顾一下敏捷宣言，权作本文的结束语吧。

 注重个人能力，注重创新，注重互动，反对僵化的过程和低效的工具  注重编写好用的软件，反对面面具到却无人问津的文档  注重客户协作，避免生硬的商务谈判

 注重适应变化，响应变化，反对墨守成规，恪守计划