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

第一篇：软件项目管理的理论与实践

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

摘要：本文在探讨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 Process）模型和用于个人的PSP（Personal Software Process）模型，作为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的利弊的基础上，用敏捷观点重新审视了过程改进的方法，并阐述了软件企业中管理和技术的关系。最后，我们再回顾一下敏捷宣言，权作本文的结束语吧。

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

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

第二篇：软件项目管理

软件项目经理所需的素质

许多人都以为项目经理总是与“理想与光荣”相伴的，其实作为一个有志于改进中国软件开发流程的项目经理来说，他们承担的更多的是“艰辛与痛苦”。

一个优秀的软件项目经理应该具备以下素质。

一、执着

可以这么说，在中国如果不执着是做不成任何事情的，因为在软件开发流程中推行各种规范和管理制度的时候，你可能遇到各种各样的阻力和障碍，如果没有应付挫折的思想和准备，你是很难推行成功的。要知道这样一个基本事实，项目管理成败的关键是：如果你不坚持，谁也不会坚持下去的。指望领导的扶持和群众的自觉是不可能的。只有坚定信念，努力打动别人，才能成功。

坚持到成功为止。只要决定上管理流程了，就不要后悔，唯有坚持，因为你拼命努力而实现了99%，你却不知，最后当你决定放弃的时候也许就是你要成功之时。要知道你准备放弃的时候可能正是对方也准备放弃之时，唯有坚持，你才能成功

二、亲和力

亲和力是指你和团队相互依赖，相互信任能力的大小。亲和力是你领导团队走向成功的基础，如果一个团队的向心力不够，各自为政，那么失败就会在身边陪伴你。要团队的每个成员都信任你，你必须要做到关心下属，主动与下属沟通，为下属争取合法权利等。关心下属就是在日常工作中对下属的工作状况，发展方向进行指导，避免其走弯路；在生活中也对其身体状况进行关心，促进身体和心理健康的恢复。

多找下属沟通是消除误会的润滑剂，同时也是了解下属内心真实想法唯一捷径。做项目经理的人，在某些事情上的处理的确会与人不同，也难以令人理解。这个时候只有多与下属沟通，逐步达成共识，争取大家的理解和支持。记住，没有下属的理解和支持，你永远无法实现项目管理的规范化。另外就是了解下属的真实想法，经常了解一下下属的真实想法有利于我们不断改进和调整流程，使生产流程更加符合本团队的实际。切记一点，做领导的一定要多尊重下属的想法，并且与之沟通，若一味等下属找自己，那么是一般下属与之水火不容要摊牌时，才会与你沟通，这样悔之晚矣。

为下属争取合法权利是项目经理的一项重要职责。敢负责任是项目经理基本素质，如果你不经常研究工作数据保障下属的合法权益时，你就很难让你的团队保持高效率。

三、品德高尚

“一撇一捺是个人，世世代代学做人。”在这个世界上最难做的就是做个品德高尚的人。试想一个思想猥亵的人很难取得成功，即使靠钻营取得也只是暂时的，他不可能取得长久的成功。只有品德高尚的人才能感染周围的人，使团队具有向心力，从成功走向成功。

人有三种，一种是仗势欺人，一种是持才压人，最后一种是以德服人。仗势欺人的人自持地位高而指三道四，自然是不可能团结人，更不可能获得成功；持才压人的人自持学识高而盛气凌人，或咄咄逼人。殊不知“闻到有先后，术业有专攻”，“尺有所长，寸有所短”，难以学到更高的知识，也就难以取得更大的成功。只有以德服人的人以自己的修养和品德感染人，勇于吃亏，乐于助人，以德报怨，只有这样才能使你对立面德人都不忍心伤害你，团结到一切可以团结到的人，拥有这样的环境，你怎么可能不成功。

勇于吃亏，首先要放下私心，如果一个人始终 围着自己转的人是不可能做到的。“人不为己，天诛地灭”是八十年代后出生的人心灵普遍反应；但是要记住人首先是社会中的人，如果脱离了社会，人恐怕已不会成其为人了。因此只有当你抛弃私心，主动为人，别人才会反过来支持你，帮助你。

乐于助人，是人类的一个良好品质，就象一首歌中所唱的“人字的结构就是相互支撑”。管理流程是不可能靠项目经理一个人维持的，必须要大家支持你。但是这却需要你多帮助别人，别人才会帮助你。不管团队成员发生什么事情，你要尽你所能去帮助他，这样团队才可能继续前进。

以德报怨，可能是人最难做到的。中国人就强调“人若犯我，我必犯人”，其实在这回中不会有真正的仇敌，大家明争暗斗的结果如果过20年后再去看的时候，保准一大半的人都会觉得不值得，许多人赌得就是一口气，将自己成功的希望给湮灭了。当你能用宽容喝善良对待你对立面的人的时候，还有什么东西能阻挡你成功？

“得道多助，失道寡助；多助之至，天下顺之，失道之至，亲戚叛之；以天下之所顺，攻亲戚之所叛；故君子有不战，战必胜矣。”

四、口才

良好的口才是项目经理打动项目成员的必备武器，当你拥有良好的口才将会使你无往不利。当年希特勒就是用他那天才般的口才征服了德国，使他的《我的奋斗》贯彻到每一个德国人的心中，从而成立了第三帝国。

要使自己的项目管理思想贯彻到每一个项目成员心中，就必须要做到以下的演讲原则：

1.根据项目成员的共同目标象他们制定演讲内容，只有让他们信服你才有意义；

2.调动听众的这种感官，诉之触觉、视觉、听觉，用黑板、姿势来辅助你的内容。

3.不断的总结效果，改进自己演讲宣传的接受度，如果效果不理想，尝试换一个方式来表达.调动听众的这种感官，诉之触觉、视觉、听觉，用黑板、姿势来辅助你的内容。

3.不断的总结效果，改进自己演讲宣传的接受度，如果效果不理想，尝试换一个方式来表达和描述。

4.让听众学以至用，只有他们积极反馈，才能更深入的听你的思想。

五、循序渐进

循序渐进，不急于求成是项目经理在项目管理中必需具备的品质，在中国CMM过程改进的热潮中，真正实现CMM管理的企业屈指可数，而以CMM改进过程实质性为企业带来质量提升和效益改进的公司更是寥落晨星。

为什么会出现这种情况？难道CMM真的不适应中国过情吗？不是，绝对不是。是这些企业的项目经理太心急，连CMM2还不知道怎么回事就直奔CMM3，他们忽视了事务发展的客观规律，凡事必须循序渐进。如果有一个企业在2年内通过了CMM4，我有十足的信心说，那是花钱买征；如果乐观一点，一个中小企业从CMM1走到CMM2大约要2年时间，大型企业只会更长，不会更短，因为他们需要在培训和沟通上付出更大的代价。

“循序渐进，循序渐进，再循序渐进。”这句巴斯德德经典名言同样适用于我们项目管理领域，他将逐步把我们带向成功。

六、持久求学

“书到用时方恨少，学至成时始知卑。”学无止境，我在生产实践中发现，整个项目管理过程改进就是“学习-培训-实施-发现问题-再学习”的循环过程，项目经理如果不学习将不能解决现实工作中出现的新问题，更不可能站在一个战略的角度来解决问题。

事实上，求学也不能没有目标，否则学到的知识太庞杂，而不能融会贯通，这样的知识对实际工作指导甚少，真正的知识是一个目标体系，严格按照流程来一步步的掌握我们所需要的知识。

最后，我总结一下中国项目经理所必需掌握的知识：

1.专业知识：数据结构、关系数据库、操作系统、软件工程、编译原理。（外国的项目经理可能不需要掌握）

2.管理知识：项目计划、项目配置管理、成本核算、风险预估、绩效考核。这是项目经理必须掌握的内容。

3.网络知识：服务器的架构、各种服务的配置。因为管理的大厦是基于软件的管理，没有一个服务管理的网络配合是不可以想象的。

4.“越过高峰，另一峰却又现”，这是中国项目经理在持续求学中会不停的挑战自我，向更高的山峰迈进。

七、敢负责任

一个人因为有责任才有生存的意义。一个人随着年龄的增长，责任感也会愈来愈重。成年时，法律也会赋予一些年少时没有的责任。同时地位逐渐提高，责任也会相对加重。

一个人惟有负责，才能产生做人的价值。所负责任愈大，价值就愈高。换句话说，有责任，生命才有意义。如果没有感受到自己该负的责任，即使年龄超过20岁，也不算是一个成年人。

因此，经理就是要负责任，如果不负责任就可以不要经理了！项目经理关系到一个项目的成败；对于公司他必须要承担及时汇报项目进度、成本核算和质量系数的责任，同时也必须保证项目组成员绩效考核，政策落实，预留人才储备等责任，是整个项目中责任最大的人，如果没有良好的心理素质和应对能力是无法担负责任的。

实际工作中项目经理主要要负责项目组的人员安排调度、工作分配、工作审核、工作跟踪、项目计划、项目汇报总结、成本核算、利润分配等职责。

八、以身作则

项目管理的一个重要工作就是定义各种规范和制定，但是这些规范和制度的执行除了靠项目经理的执着推行，口才宣传，力主培训、惩戒得当之外，关键还是在于项目经理的以身作则。如果项目经理自己都违反自己定义的条款的话，那么就别指望团队会自觉遵守这些规定。

作为一个管理者以身作则是最基本的素质，千万不要为自己违反规范和制度找各种借口，例如我我是公司只属考核，我因为某某更重要的事情而不得不违反。“只许周宫放火，不许百姓点灯”的话，是无法将规范和制度推入人心的。项目经理如果违反了规范，只有当众加重处罚，别无他法。

因此，鉴于规范制度的权威性主要还是靠项目经理自己，只有坚持以身作则，才能将自己优秀的管理思想贯穿下去，取得开发过程改进的成功。

九、要有威信

一个项目经理说话有没有人听，必须要靠威信，这种威信是靠自身的素质，而不是狐假虎威。靠高层领导的支持来强迫团队执行项目制度过程的话，是注定会失败的。因为团队成员不信任你，表面服从，实际消极怠工，就足以让流程实质瘫痪。

做事要有信用，说一不二，不能因为朋友关心就讲情面。公是公，私是私。平时可以稀稀拉拉，关键问题决不手软，不因为朋友关系妥协，这样才能树立威信，便于工作。

威信除了必要的威信之外，最主要的还是信用，项目经理在做事没有绝对把握的时候千万不要承诺，一旦承诺就无论如何一定要实现。否则，当实现不成功而丢失信用之后，再想让团队相信你，信任你就是非常困难的事情了。

十、善于总结

项目经理要善于总结，只有不断的总结才能不停的完善自己，成功的事情总结经验，失败的事情要总结教训，总结的过程就是不断改进的过程，这也是CMM规范所必需的素质。

总结

总结的过程要多吸取别人的意见，不要武断自己的结论。博人所长，综合起来才算趋于完美。这个原因有二：其一，项目经理不是孤立的一个人，而是必须融于团队之中，一个流程合不合理，不是由项目经理说了算，而是要由团队的成员说了算，注意倾听团队成员的真实感受，不断改进流程才能成功。中国的许多CMM改进失败，并不是项目经理知识能力不够，而是他们没有一起与团队总结，经多年经验，我们发现大多数规范，必须要有一套合理的软件支持才能成功，否则无论你的理想多先进，想靠程序员工作来提高过程质量的改进是不现实的。其二，“闻道有先后，术业有专攻”，项目经理不可能是全才，什么都懂。因此要和哪些与专攻方向不同的人一起总结。比如项目经理可能精通软件开发流程的改进，但是却不知道测试流程、网络管理流程、品质保证流程的改进，而这些流程又直接作用于软件开发流程。这个时候必须与测试人员、网管人员、质量保证人员共同探讨，找出一条切实可行的改进方案。

第三篇：浅谈软件项目管理范文

浅谈软件项目管理

1.软件项目管理的概念

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，通过计划、组织、控制等一系列活动，合理地配置和使用各种资源，对成本、人员、进度、质量、风险等进行分析和管理，以达到既定目标的过程。其根本目的是对软件开发的各个阶段进行管理，增强对软件开发的控制能力，提高软件开发质量。项目管理可以让一个项目获得高额的盈利也可以让一个项目损失惨重，而编码的影响力则相对小一些。软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展(即减小开发风险)。软件因其复杂性和难以度量，使软件项目管理较之其他项目管理而言有其特殊性。

2.软件企业管理国际标准

软件项目管理日趋成熟，并且已在软件业发达的欧美日及印度等国得到广泛应用，而在我国，由于大多数软件企业规模较小，生产方式依然是倚仗个人英雄主义的作坊式生产，软件开发缺乏严格的项目管理和质量保证体系。标准化、管理过程标准化、度量标准化、应用领域内业务的标准化，都是推动整个软件行业内、软件产业链上各个企业规范软件开发过程的前提基础和有力保障。目前，软件研发项目进行管理必须依据一定的标准，主要有ISO9000系列和能力成熟度模型(capabilitymaturity modeloISO9000系列和CMM的比较从背景上看，ISO9000系列国际标准是在总结了英国的国家标准基础之上产生的，因此，欧洲通过ISO9000认证的企业数量最多，约占全世界的一半以上。受此影响，相当多的欧洲软件企业选择了IS09001认证。CMM是由美国卡内基一梅隆大学的软件工程研究所(SEI)开发的软件成熟度模型，美国的软件企业更多的选择取得CMM等级证书。在形式上，CMM分为5个等级(第1级级别最低，第5级级别最高)，与ISO9000审核后只有“通过”和“不通过”两个结论相比，CMM是一个动态的过程，企业在取得低级别证书后，可根据高级别的要求确定下一步改进的方向。从内容上看，IS09001和CMM都十分关注软件产品质量和过程改进。尤其是ISO9000：2000版标准增加持续改进、质量目标的量化等方面的要求后，在基本思路上和CMM更加接近。尽管ISO9001标准的一些要求在CMM中不存在，而CMM的一些要求在ISO90O1标准中也不存在，但两者之间的关系非常密切，都强调“该说的要说到，说到的要做到”。对每一个重要的过程应形成文件，包括指导书和说明，并检查交货质量水平。CMM强调持续改进，ISO9001的1994版标准主要说明的是“合格质量体系的最低可接受水平”(ISO9001的2000版标准也增加了持续改进的内容)。

对于企业来说，取得ISO9001认证并不意味着完全满足CMM某个等级的要求。表面上看，获得ISO9001标准的企业应有CMM第3至第4级的水平，但事

实上，有些获得CMM第1级的企业也获得了ISO9001证书，原因是ISO9001强调以顾客的要求为出发点，不同的顾客要求的质量水平也不同，而且各个审核员的水平也有些差异，取得ISO9001认证所代表的质量管理和质量保证能力的高低与审核员对标准的理解及自身水平的高低有很大的关系。

3.软件项目管理软件

项目管理技术的发展与计算机技术的发展密不可分，随着计算机性能的迅速提高，大量的项目管理软件涌现出来。它们可以用于各种商业活动，提供便于操作的图形界面，帮助用户制定任务、管理资源、进行成本预算、跟踪项目进度等。根据项目管理软件的功能和价格水平，大致可以划分为两个档次：一种是供专业项目管理人士使用的高档项目管理软件，这类软件功能强大，价格一般在2000美元以上，如Primavera公司的P3、Gores技术公司的Artemis、ABT公司的WorkBench、Welcom公司的OpenPlan等。另一类是低档项目管理软件，应用于一些中小型项目，这类软件虽功能不很齐全但价格较便宜，如TimeLine公司的TimeLine、Scitor公司的Pro—iectScheduler、Primavera公司的SureTrak、Microsoft公司的Project等。根据我国软件行业的现状，下面介绍目前软件开发进程中的一些有用的工具。

3．1项目计划工具MicrosoftProject2003是一个业界领先的项目管理应用软件，利用它可以发现新的、更有效率的方法来分配任务和资源、跟踪项目进程及互相沟通项目的状况直观的计划编制。在“项目指南”这种新的交互式工具的协助下，用户将逐步建立一个新的项目、管理任务和资源。全面的整合，在MicrosoftProjec和微软其他应用程序之间，用户可以进行更加紧密的整合和更为流畅的转换。更好的状况更新，在新Wizard的指导下管理项目，可以允许调整MicrosoftProject计算实际状况的方式。合理分配资源改进的搜索和过滤功能及新的图表可以为项目鉴别和分配合适的资源。增强的个性化功能，个性化的MicrosoftProject之所以能具有更大的弹性，是因为它具有一种新的基于XML的文件格式、一种可扩展的对象模式及更强的OLEDB提供者。

3．2软件开发管理工具美国Intersolv公司的PVCS，是世界知名的软件开发管理工具。它作为当今优秀的软件开发管理解决方案，可通过对软件开发过程中产生的变更进行追踪、组织、管理和控制，建立规范化的软件开发环境。PVCS是软件开发的基础结构，在软件开发过程中可以完善地管理软件系统中的多种版本自动创建完整的文档，保障软件的维护；全面记载系统开发的历史过程，包括谁作了修改、修改了什么、为什么修改；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化；管理需求分析等。

PVCS在以下几个方面给软件开发带来了益处：规范开发过程缩短开发所需的时间、减少开发成本：它能完整详细地记载开发历史过程，便于软件维护；同时通过排除开发中的错误、加强软件一致性和可重用性，以提高软件质量。当前的开发人员常常工作在含有众多开发工具的环境中，如：编辑器、语言、编译器、Debugger、数据库等。而在这样的环境中，PVCS这种跨平台开发管理工具带来的效益会十分明显。

3．3软件配置管理工具Rational公司推出的软件配置管理工具ClearCase是目前所有配置管理工具中功能较全面和使用最广泛的工具之一。它提供了全面的配置管理功能，包括版本控制、工作空间管理、建立管理和过程控制。版本控制ClearCase可对所有文件系统对象(包括文件、目录和链接)进行版本控制，同时还提供了先进的版本分支和归并功能，用于支持并行开发。

4结语

在软件项目管理活动中，既要研究技术层面的问题，也要仔细考虑认识层面的问题，成功的软件项目开发一定是两者相辅相成的结晶。现阶段，我国软件业的业内项目管理人员仍然更多关注于技术问题而忽视了认识问题，但对于成功的软件项目管理二者是缺一不可的，甚至后者在更高的层次上决定着一个软件项目的最终成败。运用项目管理软件来指导、管理软件开发，用软件能力成熟模型对软件质量进行管理，是科学可行的。

第四篇：《软件项目管理方法与实践》课程设计报告

软件项目管理方法与实践 课 程 设 计 报 告

1006602-** ***

一、设计时间

2013年12月23日-----1月6日

二、设计地点

湖南城市学院信息楼406机房

三、设计目的1，2，3，四、设计小组成员

五、指导老师

阳王东老师、费雄伟老师

六、设计课题

七、基本思路及关键问题的解决方法

八、流程图

九、调试过程中出现的问题及相应解决办法

十、课程设计心得体会

十一、源程序

参考文献

第五篇：软件项目管理工作总结

软件项目管理工作总结

软件项目管理这门课程是我们软件工程专业学生的一门重要的课程，这门课程的开设必有其重要性。软件项目管理的提出是在20世纪70年代中期的美国。由于开发项目不能按时提交、超出预算、质量达不到用户的要求等原因，70%的项目出现问题。于是，软件开发者开始逐渐重视软件开发中的各项管理。软件项目管理和其他项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。因此，项目管理对软件生产具有决定性的意义。

只有相信团队合作才可能把项目做到最好，从整个项目的过程来看，团队合作中需要沟通、分工、协作和监督。只有做好这四项才算是一个好的合作团队。首先，团队合作最基本的技能就是沟通。沟通的目的就是让别人了解你的想法，因为每个人考虑问题的时候总会有各种各样的偏差，我们只有沟通很好的沟通来综合所有人的好的想法，以减少走弯路，而让事情进行的更顺利。因此我们也开了几次会议来互相了解沟通，当然最重要的是与项目经理的沟通。会议中他很认真负责地跟我沟通，我在沟通中用词不当或犯什么错误时，他都会指出来，并改正我的说法，因此单从与他的沟通中就学到了不少以后工作时将会用到的实在的知识。我们项目每人都是按照他给我们的计划提交相应的文件给他，但质量是参差不齐的，他都会进行审核，然后给出建议，让我们修改优化后，他才会通过。

我在此次课程中负责的部分是质量保证计划书，这是从未了解过的内容。从课程和书本上的知识不足以让我完成质量保证计划书，于是又从网上找了很多模板和每一小项是在说些什么内容来完成我们组的质量保证计划书。在这个过程中我学到了很多。我也感受到软件项目管理是一门非常需要学习的课程。它对软件工程项目的作用是至关重要的。现在，作为学生的我所做的项目虽然都是一些小的项目，但是在小组共同开发的时候还是需要用到项目的管理。如：人员的分配，时间、进度的计划，沟通计划，项目执行变更管理，以及质量管理控制等多种管理。我相信在今后的实习及工作当中，能更好的体验和感受到项目管理的精髓，对软件项目管理有更深入的了解。我也希望，学校的老师能够在今后的教学当中重视软件项目管理课程，多让学生了解实例，去感受、体会软件项目管理所遇到的问题和解决方案，理解软件项目管理的精髓。