第14章 软件项目管理“项目”如今普遍存在于我们的工作和生活之中，并对我们的工作和生活产生着重要的影响。美国著名学者罗伯特.J.格雷厄姆曾说过：“因为项目是适应环境变化的普遍方式，故而一个组织的成功与否将取决于其管理项目的水平。”由于社会环境变化是绝对的，而当今社会唯一不变的就是变化，因此，一个组织要想存在和发展，就必须适应环境的变化，就必须开展项目。美国的项目管理权威机构项目管理协会（Project Management Institute, PMI）PMI认为，项目是一种被承办的旨在创造某种独特产品或服务的暂时性势力。在经历了软件危机和大量的软件项目失败以后，人们发现正是一系列管理问题和技术问题导致了上述问题，终其原因，其一致原因可能就是：项目管理太弱。软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设范围内，有效地利用人力、资源、技术和工具，使软件系统或软件产品按原定计划和质量要求如期完成。14.1 软件项目管理概述项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目的特定目标的管理方法体系。其基本内容为 1）项目定义， 2）项目计划， 3）项目执行 ，4）项目控制， 5）项目结束。将软件进行项目管理也需采用上述5个方面的内容进行管理，由于软件项目的特殊性，将项目管理技术用于软件项目管理上，其有效的项目管理集中于四个P上：人员（people）、产品（product）、过程（process）和项目（project）。14.1.1 人员Bill Curtis曾说过：“不同的人员在完成程序设计任务的能力上存在巨大的可变性。”培养有创造力的、技术水平高的软件人员是从20世纪60年代起就开始讨论的话题。而在人员管理上达到较高成熟度的组织更有可能实现有效的软件工程实践，为此，CMU软件工程研究所专门开发了一个人员管理能力成熟度模型（PMCMM），旨在“通过帮助吸引、培养、鼓励、部署和留住改善其软件开发能力所需的人才增强软件组织承担日益复杂的应用的能力。”人员管理成熟度模型为软件人员定义了以下的关键实践区域：招募、选择、业绩管理、培训、报酬、职业发展、组织和工作设计以及团队精神/企业文化培养。在人员管理上达到较高成熟度的组织更有可能实现有效的软件工程实践。14.1.1.1 项目参与者参与软件过程（及每一个软件项目）的人员可以分为以下五类：1） 高级管理者。负责定义业务问题，这些问题往往对项目产生很大影响。2） 项目（技术）管理者。必须计划、激励、组织和控制软件开发人员。3） 开发人员。负责开发一个产品或应用所需的专门技术。4） 客户。 负责说明待开发软件的需求的人以及其他风险承担者。5） 最终用户。一旦软件发布成为产品，最终用户是直接与软件进行交互的人。每一个软件项目都有上述的人员参与。为了达到高效，项目组的组织必须最大限度地发挥每个人的技术和能力。这是项目组负责人（项目经理）的任务。14.1.1.2 项目组负责人（项目经理）项目管理是集中于人的活动，软件项目组负责人（项目经理）除对其技术要求以外，更多地应具备管理人员应有的技能。 项目经理的任务就是要对项目进行全面的管理，具体表现在对项目目标要有一个全局的观点，并制定计划，报告项目进展，控制反馈，组建团队，在不确定环境下对不确定问题进行决策，在必要的时候进行谈判及解决冲突。项目经理的责任表现的三个方面：1） 对组织（企业）应承担的责任保证项目目标与组织（企业）的经营目标一致对组织分配给项目的资源进行适当的管理，保证在资源约束条件所得资源能够被充分有效地利用与组织（企业）高层进行及时有效的沟通，及时汇报项目的进展状况，成本、时间等资源的花费，项目实施可能的结果，以及对将来可能发生的问题的预测。2） 对项目应承担的责任对项目成功负有主要责任，对项目实施计划、监督与控制，保证项目按时、在预算内达到预期结果。保证项目的整体性，保证项目在实施过程中自始至终以实现项目预期目标为最终目的，由于项目在实施过程中存在各种各样的冲突，项目经理在解决项目的冲突过程中起着重要的作用，做到化解矛盾，平衡利害。3） 对项目小组应承担的责任 为项目组成员提供良好的工作环境及氛围，项目经理作为项目负责人及协调人，首先应该保证项目组成员形成一个好的工作团队，成员之间密切配合，相互合作，拥有良好的团队精神及好的工作氛围与环境，特别地，对项目组中的关键成员及高级研究人员要进行特别的照顾，这是激励项目成员的重要手段。 项目经理有责任对项目小组成员进行绩效考评。项目经理要建立一定的考评制度，对项目组成员的绩效进行监督与考评，公正的考评制度也是激励员工的一种手段。 由于项目小组是一个临时的集体，项目经理在激励项目成员的同时还应为项目小组成员的将来考虑，使他们在项目完成之后，有一个好的归属，这样可以使他们无后顾之忧，保证他们安心为项目工作。14.1.1.3 软件项目组软件项目组织结构有多种，但软件项目组织结构是不能轻易改变。在一个新的软件项目中直接涉及到的人员的组织则是项目管理者的权限。在规划软件工程小组的结构时应考虑如下七个项目因素：1） 待解决问题的困难程度。2） 产生的程序的规模，以代码行或者功能点来衡量。3） 小组成员需要共同工作的时间（小组生存期）。4） 问题能够被模块化的程度。5） 待建造系统所要求的质量和可靠性。6） 交付日期的严格程度。7） 项目所需要的社交性（通信）的程度。从历史角度看，最早的软件小组是控制集中式（CC）结构，原来称为主程序员小组。这种结构由Harlan Mills首先提出，并由Baker描述出来。小组的核心是由以下人员组成的：高级工程师（“主程序员”），负责计划、协调和评审小组的所有技术活动；技术人员（一般2到5个人），执行分析和开发活动；后备工程师，支持高级工程师的活动，并能在项目进行过程中以最小的代价取代高级工程师的工作。项目组必须建立有效的办法以协调参与工作的人员，要建立小组成员之间及多个小组之间的正式和非正式的通信机制。正式的通信是通过“文字、会议及其他相对而言非交互的非个人的通信渠道”来实现，非正式的通信则更加个人化。 14.1.2 产品在进行项目计划之前，应该首先建立产品目的和范围，考虑可选的解决方案，标识技术和管理的约束。没有这些信息，就不可能进行合理的（准确的）成本估算、有效的风险评估、适当的项目任务划分或是可管理的项目进度安排，项目进度安排给出了意义明确的项目进展的标志。软件开发者和客户必须一起定义产品的目的和范围。在很多情况下，这项活动是作为系统工程或业务过程工程的一部分开始的，持续到作为软件需求分析的第一步。目的是标识出该产品的总体目标（从客户的角度），而不考虑这些目标如何实现。范围标识出与产品相关的数据、功能和行为，更重要的是，它以量化的方式约束了这些特性。一旦了解了产品的目的和范围，就要开始考虑备选的解决方案了。虽然这一步并不讨论细节，但它使得管理者和实践者可以选择一条“最好的”途径，该选择是根据产品交付的期限、预算的限制、可用的人员、技术接口及各种其他因素所形成的约束。14.1.2.1 软件范围软件项目管理的第一个活动是软件范围的确定。范围是通过回答下列问题来定义的：1） 语境。待建造的软件如何适应于大型的系统、产品或商业的语境，在该语境下要加什么约束？2） 信息目标。软件要生产什么样的客户可见的数据对象作为输出？需要什么样的数据对象作为输入？3） 功能和性能。软件要执行什么样的功能使得输入数据变换成输出？需要满足任何特殊的性能特征吗？软件项目范围在管理层和技术层都必须是无二义性的和可理解的。对软件范围的描述必须是界定的。也就是说，明确给出定量的数据（如同时使用的用户的数目、邮件列表的大小、允许的最大响应时间），说明约束和/或局限（如产品成本限制内存大小），以及描述其他的缓解因素（如希望使用的算法能够被很好的理解并写成C+程序）。14.1.2.2 问题分解问题分解有时称为划分或问题详细描述，它是一个软件需求分析的核心活动。在确定软件范围的活动中并不试图完全分解问题，而是将分解应用于两个主要方面：（1）必须交付的功能；（2）用于交付功能的过程。面对复杂的问题人类常常采用分而治之的策略。简单讲，就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策略。在估算开始之前，范围中所描述的软件功能必须被评估和细化以提供更多的细节。因为成本和进度都是面向功能的，所以某种程度的分解通常是很有用的。例如，考虑我们要建造一个新的字处理产品的项目。该产品的独特功能包括：连续的语音输入和键盘输入，高级的“自动复制编辑”功能，页面布局功能，自动建立索引和目录以及其他功能。项目管理者必须首先建立软件范围陈述，该陈述限定了这些特征（以及其他的通用功能，如编辑、文件管理、文档生产等等）。例如，连续语音输入功能是否需要用户进行专门的产品“训练”？复制编辑特征提供了哪些能力？页面布局能力要高级到什么程度？随着范围陈述的进展，自然产生了第一级划分。项目组研究市场部与潜在客户的交谈并找出自动复制编辑应该具有下列功能：（1）拼写检查，（2）语句文法检查，（3）大型文档的参考书目关联检查（例如，对一本参考书的引用是否能在参考书目列表中找到？），（4）大型文档中章节的参考书目关联的确认。这些特征的每一项都是软件要实现的子功能。同时，如果分解可以使计划更简单，则每一项又可以进一步细化。14.1.3 过程软件过程提供了一个框架，在该框架下可以建立一个软件开发的全面计划。少量的公共过程框架活动可应用于所有软件项目，不考虑其规模和复杂性。若干不同的任务集合（每一个集合都由任务、里程碑、工作产品以及质量保证点组成）使得框架活动能被修改，以适应于不同软件项目的特征和项目组的需求。最后是庇护性活动（软件质量保证、软件配置管理和测度）它们覆盖了过程模型。庇护性活动独立于任何一个框架活动，且贯穿于整个过程。软件过程的一般性阶段定义、开发和支持适用于所有软件项目。问题在于选择一个适合项目组要开发的软件的过程模型。我们曾讨论了多种软件工程范型：l 瀑布模型。l 原型实现模型。l 增量模型。l 螺旋模型。l 喷泉模型。l 基于构件的开发模型。l 形式化方法模型。项目管理者必须决定哪一个过程模型最适合于：（1）需要该产品的客户和将做此工作的人员，（2）产品本身的特征，（3）软件项目组工作的工作环境。当一个过程模型被选定时，项目组然后基于公共过程框架活动集合，定义一个初步的计划。一旦建立了初步的计划，便可以开始进行过程分解，即必须建立一个完整的计划反映框架活动中所需要的工作任务。14.1.3.1 合并产品和过程项目计划开始于产品和过程的合并。软件项目组要开发的每一个功能都必须通过为软件组织定义的框架活动集合。假设组织采用了如下的框架活动集合，该框架即为公共过程框架活动：l 客户交流建立开发者和客户之间有效需求诱导所需要的任务。l 计划定义资源、进度及其他相关项目信息所需要的任务。l 风险分析评估技术的及管理的风险所需要的任务。l 构造及发布构造、测试、安装和提供用户支持（如文档及培训）所需要的任务。l 客户评估基于对在工程阶段生产的或在安装阶段实现的软件表示的评估，获取客户反馈所需要的任务。开发某产品功能的项目组成员都要将每一个框架活动应用于该功能的实现上。实质上，产生了一个类似图14-1所示的矩阵。每一个主要的产品功能（图中列出了前述的字处理软件的功能）被列在左