1. 软件项目管理概述

1.1 软件项目管理

软件项目管理的提出是在20世纪70年代中期，当时美国国防部专门研究了软件开发不能按时提交、预算超支和质量达不到用户要求的原因，发现70%的项目是因为管理不善引起的，而非技术原因。

软件项目管理和其他的项目管理相比有相当的特殊性。

首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。

其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。

Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。这样庞大的系统如果没有很好的管理，其软件质量是难以想象的。

1.2 项目成功的标志

• 达到项目预期的软件产品功能和性能要求。也就是软件产品达到了用户已认可的需求规格说明的要求。
• 时限要求。项目应在合同规定的期限内完成。
• 项目开销限制在预算之内。

研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则、方法，同时避免前人的失误。

软件项目管理的内容主要包括：人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理等。

2. 人员的组织与管理

2.1 人员的组织与管理

美国卡内基·梅隆大学软件工程研究所的Bill Curtis在1994年发表了“人员管理能力成熟度模型”（people capability maturity model，P-CMM）。力图通过吸引、培养、激励、部署和骋用高水平的人才来提升软件组织的软件开发能力。

2.2 项目管理委员会

软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。如果是单独开发，成立软件项目组即可；如果是产品开发，需成立软件项目组和产品项目组（负责市场调研和销售），组成软件产品项目组。

公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。

例如：项目管理办公室PMO。

公司项目管理的最高决策机构，一般包括总经理、副总经理。 主要职责：

• 依照项目管理相关制度管理项目；
• 监督项目管理相关制度的执行；
• 对项目立项、项目撤消进行决策；
• 任命项目管理小组组长、项目评审小组组长、软件产品项目组组长。

2.3 项目管理小组

由公司管理人员组成，主要职责：

• 草拟项目管理的各项制度；
• 组织项目阶段评审；
• 保存项目过程中的相关文件和数据；
• 为优化项目管理提出建议。

2.4 项目评审小组

可下设开发评审小组和产品评审小组，一般包括技术专家和市场专家。 主要职责：

• 对项目可行性报告进行评审；
• 对市场计划和阶段报告进行评审；
• 对开发计划和阶段报告进行评审；
• 项目结束时，对项目总结报告进行评审。

2.5 软件产品项目组

可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理，成员一般由公司技术人员和市场人员构成。

主要职责： 根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。

2.6 开发人员的配置

软件开发中的开发人员是最大的资源，对人员的配置、调度安排贯穿整个软件过程，人员的组织管理是否得当，是影响软件项目质量的决定性因素。 在软件开发的一开始，要根据项目的工作量、所需要的专业技能，再参考各个人员的能力、性格、经验，组织一个高效、和谐的开发小组。

（1）一般来说，一个开发小组人数在5到10人之间最为合适，如果项目规模很大，可以采取层级式结构，配置若干个这样的开发小组。 并不是一群高水平的程序员在一起就一定可以组成一个成功的小组，作为考察标准，技术水平、与本项目相关的技能和开发经验、以及团队工作能力都是很重要的因素。

例如，一个一天能写一万行代码但却不能与同事沟通融洽的程序员，未必适合一个对组员之间通讯要求很高的项目。

（2）还应该考虑分工的需要，合理配置各个专项的人员比例。

例如一个网站开发项目，小组中有页面美工、后台服务程序、数据库几个部分，应该合理的组织各项工作的人员配比。 对于一个中型农技网站，对数据采集量要求较高，一个人员配比方案可以是2个美工、2个后台服务程序编写、3个数据采集整理人员。

（3）由于工作环境、待遇、工作强度、公司的整体工作安排和其他无法预知的因素，一个项目尤其是开发周期较长的项目几乎无可避免的要面临人员的流入流出。 对人员风险进行控制：

• 保证开发组中全职人员比例，项目核心的工作尽量由全职人员担任。
• 建立良好的文档管理机制，包括项目组进度文档、个人进度文档、版本控制文档、整体技术文档、个人技术文档、源代码管理等。
• 加强项目组内技术交流，比如定期开技术交流会等。
• 对于项目经理，可以从一开始就指派一个副经理在项目中协同项目经理管理项目开发工作，如果项目经理退出开发组，副经理可以很快接手。
• 为项目开发提供尽可能好的开发环境，包括工作环境、待遇、工作进度安排等等。

3. 软件度量

3.1 软件度量

软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。

通过软件度量可以改进软件开发过程，促进项目成功，开发出高质量的软件产品。软件项目度量目的在于度量软件项目规模、软件项目成本、软件项目进度、顾客满意度等，辅助项目管理进行项目控制。

3.2 规模度量

是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。

有效的软件规模度量是成功项目的核心要素：基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。

规模度量的要点：由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。

软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。软件规模的估算方法有很多种，如：功能点分析、代码行、德尔菲法等，这些方法不断细化为更多具体的方法。

3.3 成本度量

软件开发成本度量主要指软件开发项目所需的财务性成本的估算。主要方法：

类比估算法

通过比较已完成的类似项目来估算成本，适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目。估算的精确度依赖于历史项目数据的完整性、准确度以及现行项目与历史项目的近似程度。

细分估算法

将整个项目分解成若干个小系统，逐个估算成本，然后合计起来，这种细化的方式可能获得贴近实际的估算成本。难点：难以把握各小系统整合为大系统的整合成本。

4. 软件项目计划

4.1 软件项目计划

软件项目计划是一个软件项目进入系统实施的启动阶段，主要工作包括：确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。

软件项目计划的首要任务是进度安排，进度安排将为项目管理者建立起一张计划图。常用的制定进度计划的工具主要有甘特图和网络图两种。

4.2 甘特图

又称为横道图、条状图，以提出者的名字命名，通过条状图来显示项目、进度和其他时间相关的系统进展的内在关系随着时间进展的情况。

甘特图通过活动列表和时间刻度表示出特定项目的顺序与持续时间，横轴表示时间，纵轴表示项目，线条表示期间计划和实际完成情况，直观表明计划何时进行，进展与要求的对比，便于管理者弄清项目的剩余任务，评估工作进度。

4.3 甘特图优缺点

甘特图的优点

直观、简单、通用、容易制作，便于理解，能很清晰地标识出直到每一项任务的起始与结束时间；有专业软件支持，无须担心复杂计算和分析。

甘特图存在的局限性

甘特图仅仅部分地反映了项目管理的三重约束（时间、成本和范围），因为它主要关注进程管理（时间）；尽管能够通过项目管理软件描绘出项目活动的内在关系，但是如果关系过多，纷繁芜杂的线图必将增加甘特图的阅读难度。

4.4 甘特图的绘制

甘特图的制作工具：Microsoft OfficeProject，微软出品的通用型项目管理软件，凝集了许多成熟的项目管理现代理论和方法，可以帮助项目管理者实现时间、资源、成本的计划、控制。

5. 软件项目风险管理

5.1 软件项目风险管理

风险管理的主要目标是预防风险。

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。

如果项目风险变成现实，很可能使软件项目不能实现。

当对软件项目给予较高期望时，一般都会进行风险分析。

在标识、分析和管理风险上花费的时间和人力可以从多个方面得到回报：更加平稳的项目进展过程；更高的跟踪和控制项目的能力；由于在问题发生之前已经做了周密计划而产生的信心。

5.2 需求风险

• 需求已经成为项目基准，但需求还在继续变化。
• 需求定义欠佳,而进一步的定义会扩展项目范畴。
• 添加额外的需求。
• 产品定义含混的部分比预期需要更多的时间。
• 在做需求中客户参与不够。
• 缺少有效的需求变化管理过程。

5.3 计划编制风险

• 计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致。
• 计划是优化的"最佳状态"，但计划不现实，只能算是"期望状态"。
• 计划基于使用特定的小组成员，而此人其实指望不上。
• 实际产品规模比估计的要大。
• 完成目标日期提前，但没有相应地调整产品范围或可用资源。
• 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期要多。

5.4 组织和管理风险

• 仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长。
• 低效的项目组结构降低生产率。
• 管理层审查决策的周期比预期的时间长。
• 预算削减，打乱项目计划。
• 管理层作出了打击项目组织积极性的决定。
• 缺乏必要的规范,导致工作失误与重复工作。
• 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

5.5 人员风险

• 作为先决条件的任务(如培训及其他项目)不能按时完成。
• 开发人员和管理层之间关系不佳，导致决策缓慢,影响全局。
• 缺乏激励措施，士气低下，降低了生产能力。
• 某些人员需要更多的时间适应还不熟悉的软件工具和环境。
• 项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低。
• 项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作。
• 不适应工作的成员没有调离项目组，影响项目组其他成员的积极性。
• 没有找到项目急需的具有特定技能的人。

5.6 开发环境风险

• 设施未及时到位。
• 设施虽到位，但不配套，如没有电话、网线、办公用品等。
• 设施拥挤、杂乱或者破损。
• 开发工具未及时到位。
• 开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具。
• 新的开发工具的学习期比预期的长，内容繁多。

5.7 客户风险

• 客户对于最后交付的产品不满意,要求重新设计和重做。
• 客户的意见未被采纳，产品无法满足用户要求，必须重做。
• 客户对规划、原型和规格的审核、决策周期比预期的要长。
• 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更。
• 客户答复的时间(如回答或澄清与需求相关问题)比预期长。
• 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

5.8 设计和实现风险

• 设计质量低下，导致重复设计。
• 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能。
• 代码和库质量低下,导致需要额外测试,修正错误,或重新制作。
• 过高估计了增强型工具对计划进度的节省量。
• 分别开发的模块无法有效集成，需要重新设计或制作。

5.9 过程风险

• 大量的纸面工作导致进程比预期的慢。
• 前期的质量保证行为不真实，导致后期的重复工作。
• 缺乏对软件开发策略和标准的遵循（太不正规），导致沟通不足，质量欠佳，甚至需重新开发。
• 教条地坚持软件开发策略和标准（过于正规)，导致过多耗时于无用的工作。
• 向管理层撰写进程报告占用开发人员的时间比预期的多。
• 风险管理粗心，导致未能发现重大的项目风险。

5.10 风险分析概况

分析风险概况：假设某一风险出现后，分析是否有其他风险出现，或是假设这一风险不出现，分析它将会产生什么情况，然后确定主要风险出现最坏情况后，如何将此风险的影响降低到最小，同时确定主要风险出现的个数及时间。

5.11 建立风险清单

建立风险清单：列举出任何时候可能碰到的风险，而且要随时更新风险清单，鼓励项目团队的每个成员勇于发现问题并提出警告。

建立风险清单的一个办法是将风险输入缺陷追踪系统中，建立风险追踪工具，缺陷追踪系统一般能将风险项目标示为已解决或尚待处理状态，也能指定解决问题的项目团队成员，并安排处理顺序。

5.12 风险清单案例

风险清单给项目管理提供了一种简单的风险预测技术。 一个风险清单的例子：

风险	类别	概率	影响
资金将会流失	商业风险	40%	1
技术达不到预期效果	技术风险	30%	1
人员流动频繁	人员风险	60%	3