《软件项目管理》第二章（项目准备与启动）期末周复习总结笔记

Are you ready? 通常我们都会无意听到或者随意说出这句话。但是真的准备好了吗？这才是我们真正关心的问题。不管我们是准备出门旅行，还是参加一个宴会，或者准备一份礼物，事先我们都要进行充分的准备，否则我们出门在外一定遇到类似电视剧里的窘迫状况。

旅行途中，忘记带信用卡、现金花光。
参加宴会出门之前，衣服选好，鞋子没选对。
准备的礼物和去年的一样。
······

俗话说得好，"好的开始是成功的一半"。对于做项目，道理亦如此。有些项目启动时期没有很好地考虑到前期准备的问题，造成一些项目盲目启动、仓促进行，导致项目的投入产出分析不正确、组织混乱，给项目后期的实施、管理和维护等都带来极大的风险，甚至导致项目延期或者不符合客户需求而被弃用，最终使整个项目以失败告终。因此，做好项目启动前的准备和分析工作是非常必要的。这也是整个软件项目实施的基础。

所有项目都不是凭空产生的。不管是《人月神话》中的 IBM System/360 项目还是《梦断代码》中的 Chandler 项目，所有的项目都是为了解决一定的矛盾和满足相关的需求而产生的。

IBM System/360 项目该项目是为了解决兼容性的问题而产生的。在 System/360 之前，IBM 也研制了很多计算机，它们各自都有自己的一套配套设备，但彼此间却互不兼容，即无论是程序代码还是外设、如打印机、存储设备、输入/输出设备等，都自成一体，彼此毫不相干。System/360 的设计者们看到了这种各自为政、资源浪费，并不招来客户抱怨的局面，在 System/360 设计之初，就非常有远见地力求：

为产品家族中的最小成员所写的程序代码，能够向上兼容更强大的产品家族成员；
所有的外设都要与产品家族中的所有成员兼容。

Chandler 项目该项目是由 OSAP 支持的开源软件项目（Home - Chandler ProjectChandler Project），由米奇・卡普尔（Mitch Kapor，Lotus 1-2-3 的创始人）发起，是为了超越微软 Outlook，实现 Agenda 未曾完成的愿望而打造的一款全新的电子邮件和日程安排软件。其功能主要是个人信息管理（PIM），包括管理邮件、约会、地址簿、任务等，它具有开放架构，能够跨平台使用。

六年半的时间、上百万美元、几十号顶尖高手，只为打造卓越的软件。Chandler1.0 终于在 2008 年 8 月 8 日发布，比当初预计的发布日期推迟了整整 4 年。

大家也都清楚，无论做什么事情，不是有了意向就可以去做。我们首先都要做个分析，判断这件事情是否值得去做，怎么做，要消耗多少时间和成本等。项目不同于生活中的琐事，一旦项目运行起来，资源的需求就要被提上日程，费用也会随之产生。我们必须在做项目之前，通过专业的分析来衡量其未来的成长和收益是否和我们的投入成正比。当然，在进行专业的可行性分析之前，首先项目要得到投资方的认可才行。这也就是我们第 1 小节要介绍的内容 ------ 项目建议书。

2.1 项目建议书

项目建议书，顾名思义，就是项目的立项申请报告。它可以比较简单，也可以比较详尽，其形式是否正规是无关紧要的，重点是如何向有关的投资方或上级阐述立项的必要性。有一些项目，如上级直接指派的项目或有投资方直接需求的项目等，由于其自身的特点或者其发展条件比较成熟，没有必要进行立项的申请，这类项目就可以直接进入可行性分析阶段。

项目建议书的内容因不同的项目类型、规模而不同，但一般来说，项目建议书主要应包括下面几项内容。

项目背景。
项目的意义和必要性。
项目产品或服务的市场预测。
项目规模和期限。
项目建成后必需的条件，已具备和尚不具备的条件的分析。
投资估算和资金筹措的设想。
市场前景及经济效益的初步分析。
其他需要说明的情况。

由于软件项目是无形产品，所以在做软件项目的建议书时应该着重分析其意义、必要性和发展前景。下面借助一个具体实例，说明如何创建项目建议书。

某私立中学小型信息管理系统项目建议书

背景介绍学校过去的一年里，学生从 2000 人发展到现在的 3000 人，而学校现有的人工信息处理和更新方式完全不能满足需求。这就导致了一些信息更新不及时，甚至混乱的状况。在 5 月 8 日就发生了一件更换教师的事情。初二、3、4 班的英语老师张言由于身体不便，临时请假一天，英语组组长就立即派出初 5、6 班的王路老师代课。但是就在前两天，初一英语的李老师刚刚请产假，其教学任务由张言老师接手，而教学调度老师没有能及时更新公共信息栏，这样就导致了当天初一的一个班英语课无人授课。学校近期不断收到学生和其家长的建议，反映学校应该增加一些信息交流和课程管理的平台，让家长可以及时了解学生的情况，并给予必要的支持等。
项目的意义和必要性基于学校目前的形势和发展趋势，校领导经讨论和研究认为非常有必要建立一个学校信息系统。它可以解决学校目前的信息更新问题。它可以减轻教职工一些重复性和事务性的工作，把相关的员工解放出来，干一些更有意义的工作。有了这个系统，学校就可以实现很多资源的及时共享，对资源的利用率也会提高。这个系统还可以确保信息渠道的畅通，对家长、对学校、对学生的发展都是非常有益的。
项目产品或服务的市场预测（由于这个系统不是校方的直接收益产品，这里不做分析。）
项目规模和期限基于学校的实际情况，这个信息系统可以初步分为 3 个阶段来完成。第 1 阶段：着重处理学校现有的问题，把系统进行初步完善，重点放在教学管理方面，如教学调度、成绩管理、学籍管理等。（期限 2 个月，可以在暑假期问进行开发和实现。）第 2 阶段：注重完成学校的教学服务系统，如信息发布和共享平台、网络模拟题库等。（期限 2 个月，由于不能影响学校的事务性工作，可以在在第 1 阶段上线后 1 个月进行。）第 3 阶段：是完善和维护阶段。（这个期限根据实际情况再定。）
投资估算具体详细的投项估算，由专业人员进行。这里只能给出对比其他同类学校信息系统的估算，3 个阶段初步完成，大概需要 5 万元人民币。这个估算不包括硬件设备的预算。
市场前景及经济效益初步分析这个系统虽然不是校方的直接收益产品，但其带来的间接效益是毋庸置疑的，具体可以表现为：（1）管理决策的科学化。传统的决策只是凭经验的大致估算，无法采集到大量的数据，也无法对采集到的数据进行精确的分析。而信息系统可以比较全面、及时地采集信息数据，并选定合适的管理模式，再加上领导者的建议，就能做出科学的决策，减少决策失误。（2）管理工作的高效化。效率就是效益，信息系统可以进行全面的动态管理和及时的监控，提高效率。（3）基础数据管理现代化。学校现有的基础数据缺乏完整性、准确性、实效性和连续性，简单的师生人数由于教师的任、离职，学员的退、休学，均未能及时修正记录，以致数据的分散而不能正确统计。信息系统的开发应用，可以从根源上改变这种现象，使基础数据管理实现一致性和及时性，保证信息在整个教学管理工作中起到联络作用。（4）管理人员的工作专业化。信息系统的建立，可使管理人员，特别是中层管理人员从繁琐、重复的工作中解放出来，充分发挥其管理才能，有充分的时间从事教学研究。（5）管理人员整体素质的提高。系统建立之后，由于管理的现代化，管理人员也必须接受培训来掌握信息管理技能，从而推动了人员整体素质的提高。（6）学生个性能学习能力的提高。在信息化系统建设的第 2 阶段完成的教学服务系统中，为学生提供了跨时空、大信息量、交互性和个性化学习的环境，学生通过信息系统学习和培养在多媒体和网络环境中的学习方法和学习能力，并运用新的学习方法和观念指导自身的学习，从而提高自我学习和创新能力。

另外需要注意的是，信息系统的效益一般是无形的，只有经过长期运行后的分析统计才能计算其收益，往往会越来越成熟、科学、优秀的信息系统，带给我们的政绩就越大，信息化管理水平提高了，学校的知名度也会随之提高，学校的生意也会越来越好。

综上所述，校领导认为建立一个学校信息管理系统是非常必要的，请上级领导批示。

Chandler 项目由于是由投资人来奇发的，起点就没有这个建议书。但是查阅 IBM System/360 项目的经过由两个技术派的争论而生的。当时与小沃森（Thomas John Watson Jr）当时的 IBM 决策层于 1961 年 5 月担着极大的危险最后采纳了伊万斯（IBM System/360 主要负责人）的意见。这也表明伊万斯和另一位在争论之前应该都给决策层提交了项目建议书。

在日常的项目中，多数的项目都由高层或者决策层发起。但是，如果在项目开发或者实施的过程中，发现自己有一个提高效率、提生产力、加快产品开发实施等对企业发展有好处的想法，并且可以作为一个项目来开发的，那么项目建议书就很必要了。

项目建议书一旦得到批准，我们就可以进入可行性研究阶段了。

2.2 项目可行性分析

项目可行性分析是项目启动阶段的关键活动，旨在判断一个项目是否值得做或者是挑选许多待选项目中的最佳项目。可行性分析的分析结果直接影响项目的实施效果。对于大型的项目来说，其本身的可行性分析就可以当作一个单独的项目来做。在软件行业中，通常称作 Research 项目。对

可行性分析之前，首先要了解客户的需求和想要达到的目标。这一阶段需要由专业的分析人员与客户业务人员组成的小组，对业务需求进行收集和初步的分析。

值得注意的是，这里所说的需求分析只是对项目的需求做出初步的分析，仅仅关注客户究竟想要哪些主要功能，并以此作为项目可行性分析的分析依据。一般来说，这类需求分析包括以下内容：

当前业务流程分析。
主要功能点需求分析。
系统的非功能需求分析，如性能需求、环境需求和安全需求分析等。
对一些限制条件的分析，如经费来源和使用的限制，软件开发周期的限制等。
需求的优先级。

Chandler 项目是个开源项目，完全能够提前在网络上征集客户的相美需求，然后进行整理、调研和分析，确定用户的真正需求并制定出可行的计划。如果能这样做，是不是 1.0 版本早就做出来了呢？在正式版本发布之前，Chandler 团队先后发布了 0.1、0.4、0.6 等版本，听取用户的反馈。

2.2.2 可行性分析因素

目标确定了，现在是时候要决定"做还是不做"了。我们先来分析一下影响项目可行性的因素。在很多软件项目专著中都对项目的可行性因素做了不同角度的分析，有的从宏观影响角度分为经济、技术、社会环境和人等 4 个要素；有的从风险影响角度分为项目风险、商业风险、技术风险、用户风险和过程风险等。结合有关专著对可行性分析因素的分析和参加项目管理的实践经验，我们在这里把影响软件项目可行性的因素归纳为 3 个方面：经济可行性、技术可行性、风险和不确定性，如图 2-1 所示。

图 2-1 可行性分析因素

2.2.3 成本效益分析方法

通过进行成本和效益的分析，可以判断项目的经济可行性，即投入产出的合理性，主要包括成本、直接收益和间接效益的分析。目前在很多项目管理和软件技术的书籍中都论述了关于成本效益分析的方法（如参考文献 [5]、[6]），我们这里只介绍比较常用的 2 种方法：回收期、净现值分析法。

回收期分析法回收期（payback period）就是使累计的净现金流入等于最初的投费费用所需的时间。假设：案例 2 项目的最初投资费用是 5 万元，如果每年的净现金流入是 2 万元，那么，它的回收期 =5 万元 /2 万元 / 年 =2.5 年。回收期分析法的优点是容易理解，计算也比较简便。可以看出回收期越短，风险越小。而不足之处是，回收期分析法没有全面考虑投资方案总的所有可能的收益，只考虑回收之前的效果，不能反映投资回收之后的情况，即无法准确衡量方案在整个计算期间内的经济效果。这种方法还忽略了货币时间价值（Time Value of Money）。由于这些局限，投资回收期分析法作为方案和项目的选择是不可靠的，它只能作为辅助评价指标。
净现值分析法净现值（Net Present Value）就是未来报酬的总现值减去原来的投入。这是一种常用的项目评价方法。其计算公式如下：

其中：t= 年数； Ft= 第 t 年的净现金流人； k= 贴现率，也可以看作是目标回报率； r= 第 t 年的预期通货膨胀率； Po= 最初投资。

净现值的决策规则是：在一个备选方案的采纳与否决策中，净现值为正者则采纳，净现值为负者不采纳。在有多个备选方案的互斥选择决策中，应选用净现值是正值中的最大者。假设：案例 1 初期投资 20 万元，预计未来 5 年中各年的收入分别为 2 万元、4 万元、5 万元、8 万元、12 万元，假定每年的贴现率是 5%，每年的通货膨胀率是 3%，那么：

因为其净现值是正数，也就是说未来的 5 年里现金的流入量大于现金流出量，这个项目是可以被采纳的。

在成本效益分析方法中，几乎都要用到现金流入量和现金流出量的数据。对于这两者的的数据统计属于财务管理的范畴，有兴趣的读者可以参阅财务管理类书籍。

2.2.4 技术及风险分析方法

软件项目除了要进行成本效益的分析，还需要进行技术、风险和不确定性等可行性分析。

技术分析技术分析是要通过对技术设计方案或者演示模型的比较和分析，判断其技术的成熟性和适用性。这里最常用、有效的方法就是专家评定（Expert Judgment），即找相关行业的技术专家进行评审。
风险分析风险分析是对项目分别进行内部和外部的风险评估，主要对市场风险、技术风险、财务风险、组织风险、法律风险、经济及社会风险等风险因素进行定性和定量的分析，从而为项目决策提供依据。最常用的方法就是定性分析法决策树，详细内容可参考本书第 7 章。

图 2-2 所示为分析师用决策树来预测、评估某软件项目上线 1 年之后的运行结果。

在此，做项目的预期收益就是：0.7×10 万元 -0.3×5 万元 =5.5 万元，而不做项目的预期收益就是：-4 万元。做项目就是比较有利的选择。

2.2.5 可行性分析结论

项目是否可行？根据可行性分析、成本效益分析、技术分析和风险分析等研究结果，就比较容易做出决策。可行性研究报告的主要内容可以包括以下几点。

项目需求分析概况。
可行性要素分析。
项目的设计方案。
项目的人员配置和培训计划。
人员配置和培训计划。
项目主要风险。
可行性研究的结论和建议。
其他重要意见。

在此报告中，重要的是对项目的可行与否提出最终建议，为项目决策审批提供全面的依据。

决策层会根据分析结论，综合其他影响因素（经费、发展方向等），来决定项目是否立项。对于外部项目，合同就标志着项目立项；对于内部项目，合作双方达成协议约定即可。

接着项目建议书的私立中学案例，给出如下所示的可行性研究报告。

项目简介 1.1 项目背景随着学校的规模逐渐扩大，学校的学生越来越多，新来的教师也越来越多。学校的教学管理比较混乱，存在教学调度信息与学生档案信息等更新不及时、不完整等现象。学校的管理者需要对学生负责，在保证高质量教学工作的同事还要确保各类信息完整、及时、准确和真实。

作为一个发展良好的私立学校，信息化管理是非常必要的。如果能保证学校的信息完整、及时、安全、真实，那么，学校的教学质量和教学管理都能相应地提高。人工化的信息管理，不仅浪费大量的人力物力，信息的及时性、完整性也得不到良好的保证。建立一个安全的、真实的、可靠的学校信息管理系统已经成为一种必然。

1.2 项目目标本系统一方面对日常的教学工作进行计算机化管理，解决现存的问题；另一方面对师生提供有效的共享服务和信息即时交流平台，使其更好地为学生、教师、学校服务。

本系统在确保信息安全的基础上采用 Web 的形式，以方便学生、教职员工、家长随时更新数据，查看数据。

需求分析报告基本要求：本系统包括 2 个子系统，即教学管理系统和教学服务系统。

针对教学管理系统：管理员可以（增加、删除、修改、存储等）所有信息，管理员要区分不同管理权限（比如对应的班主任可以管理本班学生的所有信息，系统管理员可以安排教学日历，管理教学大纲，更新信息公告等）。系统要提供搜索和统计功能。

针对教学服务管理系统：共享资源平台，讨论区的功能。同时也要提供搜索和下载的功能。

外观要求：简单、简洁、美观、完整的站点布局，完整的有效的链接。

总体设计方案 3.1 系统功能结构图

图 2-3 学校信息管理系统功能结构图

3.2 数据流图

图 2-4 教学管理系统主要数据流

图 2-5 教学服务系统主要数据流

系统可行性分析 4.1 技术可行性分析当前开发小组成员以前做过类似系统的开发，对其软硬件操作环境、编译环境以及网络布局都比较熟悉。暂定开发工具用 Ruby on Rails，这是一个结构化的 Web 应用程序开发技术；操作系统用 Windows；数据库用 SQL Server。开发小组成员曾经也有过合作经验，在沟通上不是问题，所以当前这个系统从技术上来说是可行的。

4.2 经济可行性分析此系统要求增加新的硬件（如服务器、新的计算机、新的网络设施等），这是一次性的投入成本。在系统上线之后，其软硬件的维护成本也是必不可少的。对软件带来的收益和耗用的成本进行计算，可判断经济可行性。

表 2-1 私立中学信息管理系统有形收益

表 2-2 私立中学信息管理系统成本支出

用 NPV 进行成本分析，由前面数据可以得出，初始投入成本是￥57000，第 1 年到第 5 年的收入是￥33600-￥9500=￥24100。假定每年的贴现率是 5%，每年的通货膨胀率是 2%，那么经过计算 NPV=￥41762。由此可以看出开发此系统在未来 5 年里是收益大于支出的，而且随着系统的不断稳定其维护费用也会越来越低。

4.3 项目主要风险分析（1）虽然开发小组做过一些类似的项目，但是每个客户的需求都是不尽相同的。所以在进行项目详细设计的时候需要更多的思考和讨论，以防预防项目后期再修改设计的风险。（2）对人员变动，大范围的需求变更要做好足够的预防和减少的措施。因为这是个小型项目，历时本来就不长，如果有人员的变动或者大范围的需求变更就很容易导致项目的延期。

结论：经过上述分析，开发此系统的技术完备，成熟，经济效益合理，满足学校当前信息管理的要求，也满足学校不断发展后的潜在功能。此系统可进行开发。

2.3 项目投标

讲到这里，有些人可能会奇怪，怎么没有招标就开始投标了呢。其实善于思考的读者已经得到答案了。在进行可行性分析之前，我们就提到要根据实际情况来确定是否需要聘请专业顾问。如果项目需求方没有软件开发能力，那么他们需要聘请专业的机构来进行分析和开发。所以对于这样的情况，可行性研究和项目的招标就可以合二为一，既节省成本又可以选择最优的方案，何乐而不为呢？对于自主研发的项目来说，就谈不上招标和投标了。

项目投标基本可以分为 2 个阶段。（1）第 1 个阶段是参加竞标的供应商在规定的时间内提交标书。标书一般包括项目需求分析、可行性研究方案和相关的财务预算。标书要做到清晰化、条理化和规范化。（2）第 2 个阶段是需求方（客户）对投标书进行评估。在评估之前，需要制定相应的评估标准，以确保我们的评估过程和结果是公平合理的。正如 PMP 中提到的，我们的标准可以是客观的，也可以是主观的。我们应该根据实际需要来制定标准，如从需求满足、技术能力、管理方案和财务预算等多方面来考虑。

通过评估，需求方可最后选定一个最优的方案和供应商签订合同。在这里需要提及一点，无论是从业道德还是礼貌的角度，评估的结果都应该既通知成功的竞标者，也要通知没有获得成功的竞标者。

2.4 软件项目合同条款评审

法律是合同的依据，合同的条款是操作的依据。无论是成本管理、进度管理、质量管理还是沟通管理，都离不开合同约定的条款。在处理买卖双方的利益关系时，合同是最有力的裁决者。不同类型的项目一般会采用不同类型的合同。

2.4.1 合同计费的种类

不同的合同，有不同的应用条件、不同的权利责任分配和不同的风险分担。这里以合同计费的形式简单介绍 4 种常见的合同类型。软件项目计费常使用固定总价合同和功能点计费合同。（1）固定总价合同：签订合同的时候，总的价格已经确定了。只有当出现设计变更或符合合同规定的调价条件时，才允许调整合同价格。这类合同是把需求变更和成本增加的风险从需求方转移到了承包方。但由于固定价格不变，承包方不得不节约成本，从而带来软件质量下降的风险。（2）费用偿还合同：实际成本和奖励薪酬相加支付给承包方。奖励薪酬可以根据项目的情况来制定，如固定奖励、成本百分比奖励和按绩效结果奖励等。（3）时间和材料合同：按单位工作量支付报酬，如按员工的工时等来计算。这类合同和固定总价合同的风险承担刚好相反，承包商缺乏动力。（4）功能点计费合同：顾名思义，这类合同是按功能点的个数支付报酬。这种合同要求在项目开始的时候就应该估计好项目的规模，即通过功能点分析估计功能点数，每个单位功能点价格也要标注清楚，最终项目结束后通过功能点数和单位价格的计算得到总价格。表 2-3 所示为一个典型的例子。表 2-3 功能点计费表

功能点计费表

表 2-3 功能点计费表

功能点计费法（Function Point Analysis）就是从用户对应用系统的功能性需求出发，把应用系统按组件进行分解，并对各类组件以定义的功能点为度量单位进行计算，从而得到反映整个应用系统规模的功能点数。

2.4.2 合同条款评审

在正式签订合同之前，双方要对拟定中的合同进行评审。在评审过程中，要按照制定合同、评审合同和签订合同的顺序进行。

制定合同在制定合同的过程中，可以参照同类项目的合同进行讨论和修改。如果没有参照的合同内容，双方可以各自内部讨论合同草案，然后派代表通过会谈和讨论的方式确定合同的内容。合同的内容基本可以包括如下方面。（1）项目时间表（最好为项目重点部分设立对应的里程碑）。（2）项目验收标准（如项目质量标准，包括适用性和安全性等）。（3）项目维护和升级事项。（4）项目价格和付款方式。（5）双方的义务和责任。（6）相关保密条款（如价格保密和代码保密等）。（7）软件所有权问题（所有权归投资方还是开发方）。（8）合同修订方式和修订程序。（9）合同法律效力（确认合同是有效的）。（10）合同有关附件（包括需求范围，项目质量标准等）。（11）违约责任。（12）其他责任等。
评审合同评审合同就是对合同内容进行最终的评定。在合同内容制订的过程中，双方已经进行了非常充分的交流，对大部分的合同内容都达成了一致的意见。在评审中，重点是对不一致的部分进行讨论和确定。
签订合同在合同评审结束后，应确保所有不明确的问题都已得到解决，即可以请双方的代表签订合同。

2.5 软件开发模型

软件行业发展至今，出现过种类的开发模型。根据项目的需求，选用适合的开发模型，无疑对项目的开发有很大的推进作用。软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为 3 种基本类型。

（1）以软件需求为出发点，各项软件活动为线性分布的瀑布模型（Waterfall Model）。（2）以响应变化、紧密沟通合作、快速持续交付有价值软件来满足客户的敏捷开发模型。（3）快速实现一个可实际运行的系统初步模型，供开发人员和用户进行交流和评审，以便较准确地获知用户需求的快速原型实现模型。

2.5.1 瀑布模型

瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这 6 个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落，如图 2-6 所示。

图 2-6 瀑布模型

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。开发过程是通过一系列软件活动顺序完成的，从系统需求分析开始直到产品发布和维护，每个活动都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好"返回"上一个阶段并进行适当的修改，开发进程从一个阶段"流动"到下一个阶段，这也是瀑布开发名称的由来。

瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下且呈线性图式的，因此瀑布模型存在一些的缺陷。（1）由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。（2）在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。

（3）在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。所以对于需求变更不太频繁的大型项目，瀑布模型还是很实用的。

2.5.2 快速原型实现模型

快速原型法其实是对瀑布模型的改进，侧重需求的快速挖掘。其第一步是建造一个快速可实际运行的系统初步原型，实现客户或用户与系统的交互，对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

它可以避免在瀑布模型冗长的开发过程中看不见产品雏形的现象。其优点一是开发工具先进，开发效率高，使总的开发费用降低，时间缩短；二是开发人员与用户交流直观，可以澄清模糊需求，调动用户的积极参与，能及早暴露系统实施后潜在的一些问题；三是原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。其缺点是产品原型在一定程度上限制了开发人员的创新，没有考虑软件的整体质量和长期的可维护性。由于达不到质量要求，产品可能被抛弃，而采用新的模型重新设计，因此原型实现模型不适合嵌入式、实时控制及科学数值计算等大型软件系统的开发。

其开发步骤如图 2-7 所示。具体如下。

图 2-7 快速原型开发步骤

快速分析在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型所要体现的特征描述基本需求以满足开发原型的需要。
构造原型在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统。这里要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，如安全性、坚忍性、例外处理等等，主要考虑原型系统能够充分反映所要评价的特性，而暂时删除一切次要内容。
运行原型这是发现问题、消除误解、开发者与用户充分协调的一个步骤。
评价原型在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并且满足因环境变化或用户的新想法引起的系统要求变更，提出全面的修改意见。
修改根据评价原型的活动结果进行修改。若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型。

2.5.3 从增量模型到敏捷方法

在一个项目中，假定我们并不能事先确定系统的所有需求，那么在项目的初期有一个详细设计阶段的想法是不现实的。系统的设计和开发必须随着软件的变化而进化。那么我们就不能采用传统的瀑布模型进行开发。我们必须找寻一种应对需求快速变化的软件开发能力------增量模型或敏捷开发（Agile development）。

增量模型增量模型融合了瀑布模型的基本软件活动，如图 2-8 所示。该模型采用随着日程时间的进展，而交错的线性序列，每一个线性序列产生软件的一个可发布的"增量"。当使用增量模型时，第 1 个增量往往是核心的产品，即第 1 个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

图 2-8 增量模型

增量模型的特点是引入了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，可则增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的方法。这样即可先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。

增量模型存在以下缺陷： ① 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这对软件具备开放式的体系结构提出了较高的要求； ② 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使它具备适应这种变化的能力，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性； ③ 如果增量包之间存在相交的内容且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

敏捷开发敏捷开发是一种思想或方法论，就是通过不断迭代开发和增量发布，最终交付符合用户价值的产品。如何用敏捷的思想来进行软件开发？现在有很多具体的敏捷开发框架、流程或模式，比如：Scrum、极限编程、行为驱动开发、功能驱动开发、精益软件开发（Lean Software Development）等。它们的具体名称、理念、过程、术语都不尽相同。相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。不但不管采用哪种具体的敏捷开发框架，都应该符合敏捷宣言的思想，遵守敏捷开发的原则。只能按照这个敏捷宣言和敏捷开发原则来判断某种开发活动和实践是否是敏捷开发。

敏捷宣言（参考 http://www.agilemanifesto.org 全文如下表述：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值。

为了更好体现敏捷宣言所阐述的价值观，就要认真贯彻敏捷宣言背后所蕴含的如下 12 条原则：

① 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 ② 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 ③ 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 ④ 业务人员和开发人员必须相互协作，项目中的每一天都不例外。 ⑤ 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支持，辅以信任，从而达成目标。 ⑥ 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 ⑦ 可工作的软件是进度的首要度量标准。 ⑧ 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 ⑨ 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 ⑩ 以简洁为本，它是极力减少不必要工作量的艺术。 ⑪ 最好的架构、需求和设计出自自我组织型团队。 ⑫ 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

至于在软件项目管理中，选择哪一种开发模型，取决于项目所处的上下文（Context），包括组织文化、产品、应用领域、项目团队等背景和特点，表 2-4 所示为简单的对比。选择一个合适的生命周期模型，并应用正确的方法，对于任何软件项目的成功是至关重要的。企业在选择开发模型时应从项目时间要求、人员状况、预算情况、需求明确程度、风险状况等选择合适的生命周期模型。

表 2-4 各种软件过程模型的特点及适用范围

模型名称	技术特点	适用范围
瀑布模型	简单，分阶段，阶段间存在因果关系，各个阶段完成后都有评审，允许反馈，不支持用户参与，要求预先确定需求	需求易于定义且不易变更的软件系统
敏捷模型	积极响应需求变化，用最短的时间提交给客户最有价值的功能，并在整个项目周期中持续改善和增强	需求难以确定，不断变更的软件系统
快速原型模型	不要求需求预先完整定义，支持用户参与，支持需求的渐进式完善和确认，能够适应用户需求的变化	需求复杂，难以确定、动态变化的软件系统

2.5.4 极限编程

极限编程（Extreme Programming，缩写为 XP），是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法之一。基本思想是"沟通、简单、反馈、勇气"。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP 的支持者认为软件需求的不断变化是再自然不过的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，传统的在项目起始阶段定义所有需求再尽心尽力地控制变化的方法相比，有能力在项目期间的任何阶段去适应变化，将是更加现实更加强效的方法。

XP 项目一开始就是收集用户故事（User Story）。用户故事由用户编写，是一段与技术无关的文本，其目的在于提供一些特殊场景的详细描述，而不是用来估计系统的复杂性。用户故事的所有细节必须在它实现之前得到客户的确认。紧接着就是制定发布计划。发布计划确定在系统的哪个发布版本中有哪些用户故事需要实现。每个发布版本都要经过好几次迭代，每次迭代实现一些用户故事，如图 2-9 所示。一次迭代包括如下阶段： ① 计划：选择要实现的用户故事及其要明确的细节； ② 编码：实现用户故事； ③ 测试：至少每个类都要有相应的单元测试； ④ 验收测试：如果测试成功，新功能开发完成；如果失败，则进入下一次迭代。

XP 的最佳实践 ● 开发人员和客户之间的交互是有益的。因此，一个极限编程的小组上理论上要求需要一个软件用户在身边，这个用户制定软件的工作需求和优先等级，并且尽可能在各种问题出现的时候马上就能回答（实际工作中，这个角色是由客户代理商完成的）。

图 2-9 XP 流程示意图

● 如果学习是有效的，那么就把它做到底：这样减少了开发和回馈周期的长度，测试也能更早完成。 ● 简单：设计最简单的、可以实施的方案。大部分项目中，开发人员往往把大部分时间都浪费在设计一些通用的解决方案上，以期适应将来可能出现的用户需求、运行平台等。要知道有时大部分变更并不是按开发人员最初想象那样的变化。 ● 代码评审是有效的。因此，极限编程的程序设计师和建筑工程师两人搭档的方式工作。他们共享一个屏幕和键盘，增加了队员之间的交流，也让代码在一被写出来的时候就被评审了。 ● 测试代码很重要。因此，在极限编程中，测试用例在实际代码之前就被编写出来。代码只有在通过测试的时候才被认为完成了（当然，需要进一步分解来降低复杂性）。整个软件系统用一种周期化的、实时的、被预先编好的自动化测试方式来保证它的确有用。这就是测试驱动的开发。 ● 一般来说，极限编程被认为对于少于 12 人的小团队很有用。然而，极限编程在一些超过 100 人的开发小组中也获得了成功。并不是极限编程不能推广到更大的团队，而是很少有更大的团队来试着用它。

XP 特点 ● 快速反馈：当反馈能做到及时、迅速，将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。与传统开发方法不同，XP 的客户能够清楚地洞察开发中系统的状况。他 / 她能够在整个开发过程中及时给出反馈意见，并且在需要的时候能够掌控系统的开发方向。 ● 假设简单：认为任何问题都可以"极度简单"地解决。传统的系统开发方法要考虑未来的变化，而极限编程拒绝这样做。 ● 增量变化：极限编程的提倡者总是说：罗马不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。例如说，可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式，使得整个开发进度以及正在开发的系统对于用户来说变得更加可控。 ● 包容变化：可以肯定的是，不确定因素总是存在的。"包容变化"这一原则就是强调不要对变化采取反抗的态度，而应该包容它们。比如，在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员，必须包容这些变化，并且拟定计划使得下一个阶段的产品能够满足新的需求。

2.5.5 行为驱动开发

行为驱动开发（Behavior-driven development，缩写为 BDD）是一种敏捷开发的技术，它鼓励软件项目中的开发者、QA 和非技术人员或商业参与者之间的协作。

行为驱动开发的根基是一种"通用语言"。这种通用语言同时被客户和开发者用来定义系统的行为。由于客户和开发者使用同一种"语言"来描述同一个系统，可以最大程度避免表达不一致带来的问题。表达不一致是软件开发中最常见的问题，由此造成的结果就是开发人员最终做出来的东四就不是客户所期望的。使用通用语言，客户和开发者可以一起定义出系统的行为，从而做出符合客户需求的设计。但如果没有验证的手段，就无法检验我们的实现是不是符合设计。所以 BDD 还是要和测试结合在一起，用系统行为的定义来验证实现代码。

行为书写格式：

行为实例：

BDD 的做法包括：

通过由外及内的软件开发方法，把涉及到的利益相关者融入到实现的过程中；

使用例子来描述应用程序的行为或代码的每个单元；

通过自动运行这些例子，提供快速反馈；

使用"应当 (should)"来描述软件的行为，以帮助阐明代码的职责，以及回答对该软件的功能性的质疑；

使用"确保 (ensure)"来描述软件的职责，以把代码本身的效用与其他单元 (element) 代码带来的边际效用中区分出来；

使用 mock 作为还未编写的相关代码模块的替身。

2.5.6 功能驱动开发

功能驱动开发（Feature-Driven Development，缩写为 FDD）是由 Peter Coad、Jeff de Luca、Eric Lefebvre 共同开发的一套针对中小型软件开发项目的开发模式。

FDD 是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于开发团队接受，适用于需求经常变动的项目。简单地说，FDD"是一个以 Architecture 为中心的，采用短迭代期，Feature 驱动的功能设计"的选代完成项目开发。此处的"功能"是指"用户眼中最小的有用的功能"。它是可理解的、可度量的，并且可以在有限的时间内（两周）实现。由于在 FDD 中采用了短周期的选代、最小化的功能划分法，所以可以对项目的开发进程进行精确及时的监控。

在 FDD 中，将开发过程划分为如下四个阶段，如图 2-10 所示。

图 2-10 FDD 开发过程

开发一个全局的模型在一个有经验的组件/对象建模专家（首席架构师）指导下，业务领域人员与开发人员一起协调工作，业务领域人员和开发人员会依此产生初始的模型，然后再结成单独小组，进行详细继续讨论阶段，将模型轮廊描绘出来，然后丰富之前产生的初始模型。
建立功能列表（Feature List）当初始模型产生以后，就开始构建（feature list）功能列表，体现为下面形式： <action> the <result> by [or for] a <object> 就是动作、主体、结果的关系，每个动作发生都是围绕一个对象为主体的。建立功能列表就是将这些功能进行分类、合并和整理。例如功能需求中有：用户注册、用户修改注册资料和用户登录等功能，那么输入到功能列表中后就可能是：围绕对象模型用户（User）的新增、修改、删除以及查询等功能。
依据功能计划（Plan By Feature）这一步工作就是将这些功能进行排序和计划，然后分配给相应的程序员组。
依据功能进行设计和实现（Design By Feature / Build By Feature）程序员组针对自己的功能列表按选代进行设计和实现。

每次选代的内容包括： ● 工作包的启动会议：详细描述被包括的特征； ● 设计：创建必须的类、方法及相关文档； ● 设计评审：对提供的设计进行评审，或者接受，或者拒绝； ● 开发：实现并进行单元测试； ● 代码评审会议：执行代码同行评审； ● 发布会议：将已实现的特征进行集成。

2.5.7 敏捷开发模型 Scrum

在敏捷开发模型中现在比较盛行的就是 Scrum，作为压轴戏留到最后讲解。Scrum（原意：英式橄榄球争球赛），将软件开发团队比成橄榄球队，有明确的最高目标，具有高度自主性，高度自我管理意识，紧密地沟通合作，以高度弹性来解决各种挑战，确保每天、每个月都朝着目标有明显的推进。

Scrum 开发流程通常以 2 周到 4 周（或者更短的一段时间）为一个阶段，由客户提供新产品的需需求规格，开发团队与客户在每一个阶段开始时按优先级挑选该完成的规格部分，开发团队必须尽力于该阶段后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭受的困难并排除。

Scrum 是一种迭代式增量软件开发过程，包括了一系列预定义过程的角色过程骨架。其五大价值观如下：

五大价值观 ① 承诺（Commitment）：鼓励承诺，并授予承诺者完成承诺的权力。 ② 关注（Focus）：集中精力做好工作，关注并完成承诺。 ③ 公开（Openness）：Scrum 提倡公开、透明，不管是计划会议、平时工作、每日站会还是最后的总结回顾，都需要大家公开信息，以确保大家及时了解工作进度，如有问题及时采取行动来解决。 ④ 尊重（Respect）：团队是由不同个体组成，成员间相互尊重是很必要的。 ⑤ 勇气（Courage）：有勇气承诺任务，采取行动完成任务。
三种角色 ① 产品负责人（Product Owner）：负责维护产品需求的人，代表利益相关者的利益。 ② Scrum Master：为 Scrum 过程负责的人，负责 Scrum 的正确使用并使得 Scrum 的收益最大化。 ③ 开发团队（Team）：自我管理开发产品的人员组成的团队，建议一个 Scrum 团队 5-9 人。大于 9 人的，可以用 Scrum of Scrums（SoS）模式来管理。详见第 5 章 7 小节第 2 部分。

按照对开发过程的参与情况，Scrum 还定义了其他一些角色。这些角色被分为两组，即猪组和鸡组。这个分组方法的由来是一个关于猪和鸡合伙开餐馆的笑话，如图 2-12 所示。

图 2-12 猪和鸡合伙开餐馆的笑话

一天，一只猪和一只鸡在路上散步。鸡对猪说："嘿，我们合伙开一家餐馆怎么样？"猪回头看了一眼鸡说："好主意。那你准备给餐馆起什么名字呢？"鸡想了想说："叫'火腿和鸡蛋'怎么样？"猪回答："可我不行啊"，猪说"：我把自已全搭进去了，而你只是参与而已。"

猪组的角色：猪是在 Scrum 过程中全身心投入项目的各种角色，他们在项目中承担实际工作。有他们有些这个笑话中的猪。

鸡组的角色：鸡并不是实际 Scrum 过程的一部分，是利益相关者，必须考虑他们。敏捷方法的一个重要方面是使得利益相关者参与到过程中的实践。比如，参与选代的评审和计划，并提供反馈。

用户、客户、供应商、经理等对项目有影响的，但又不实际参与项目的角色都是鸡组成员。

三个工作 ① 产品列表（Product Backlog）：按照优先级排序的需求代办事项。 ② 选代列表（Sprint Backlog）：要在选代中完成的任务的清单。 ③ 选代燃尽图（Burndown Chart）：在选代长度上显示所有剩余工作时间逐日递减的图，因整体上总是递减而得名。
五个活动 ① 计划会（Sprint Planning Meeting）：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。 ② 每日立会（Daily Standup Meeting）：团队每天进行沟通的内部短会，因只有 15 分钟且站立进行而得名。 ③ 评审会（Review Meeting）：在冲刺结束后给产品负责人演示并接受评价的会议。 ④ 回顾会（Retrospective Meeting）：在冲刺结束后召开的关于自我持续改进的会议。 ⑤ 选代（Sprint）：一个时间周期（通常在 2 周到 1 个月之间），开发团队会在此期间内完成所承诺的一组需求的开发。

Scrum 模型的一个显著特点就是响应变化，它能够尽快地响应变化。所以随着软件复杂度增加，项目成功可能性相比传统模型要高一些，图 2-13 所示为 Scrum 模型和传统模型的对比。

图 2-13 Scrum 模型和传统模型的对比

Scrum 使我们能在最短时间内关注最高的商业价值。它使我们能迅速及不断地检验软件，以此来确定是否立即进行发布还是通过下一个选代完善。

2.6 软件项目组织结构和人员角色

在本节开始之前，我们先来看一个耐人寻味的幽默故事。

有两个划船队 J 队和 M 队要进行划船比赛。两队经过长时间的训练后，进行了正式比赛，结果 M 队落后 J 队 1km。输给了 J 队，M 队领导很不服气，决心总结教训，在第 2 年比赛时，一定要把 J 队赢回来。M 队领导分析后认为 J 队是 8 人划桨，1 人掌舵；而 M 队是 8 人掌舵，1 人划桨。没有中心，缺少层次，这是失败的主要原因。

于是，M 队重新组建了船队的领导班子。新班子结构如下：4 名掌舵经理、3 名区域掌舵经理、1 名划艇长，还专设 1 名勤务员，为船队领导班子指挥工作服务，并具体观察、督促划船员的工作。这一年的比赛结果是 J 队领先 2km。M 队领导班子感到脸上无光，讨论决定由于划船员表现太差，予以辞退：勤务员监督工作不力，应予处分，但考虑到他为领导班子指挥工作的服务做得较好，将功补过，其错误不予追究：领导班子成员每人发一个红包，以奖励他们共同发现了划船员工作不力的问题。

仔细分析起来，这个故事说明了 3 个密切相关的问题。（1）凡做一件事，如参加划船比赛，必须有一个组织。（2）这些组织的内部成员应有不同的分工，如上面的两个划船队里的成员都有不同的分工，由此形成其内部的一定结构，即组织结构。（3）作为一个组织，内部结构不同，行为效果也会不同，例如，上面例子中的 M 队 2 次都输给了 J 队。

据统计，在软件开发项目中，项目失败很重要的一个原因就是项目组织结构设计不合理，责任分工不明确，组织运作效率不高。

在《人月神话》中，也通过外科手术的例子强调了组织结构和分工的问题，如图 2-14 所示。

Mills 的建议，程序员如同外科手术的队伍要进行专业化分工，使程序员从书记的杂事中解放出来，同时还可以对那些杂事进行系统整理，确保了它们的质量，并强化了团队最有价值的财富------工作产品。

在这一节中，我们先简单介绍一种项目组织结构的几种主要类型，重点讨论软件项目的组织结构设计。

2.6.1 项目的组织结构

项目的项目组织结构有 3 种主要的类型：职能型、纯项目型和矩阵型。

职能型（Functional type）该结构是金字塔形，图 2-15 所示为一个典型的职能型组织结构图。高层位于金字塔的顶部，中层和底层则沿着塔身向下分布。公司的经营活动按照职能划分为部门（如设计部门、生产部门和检测部门等）。在职能型组织里，一般没有项目经理，项目功能都是在本职能部门内部实现再提交到下一个部门。如果实施期间涉及其他职能部门的问题，只能报告给本职能部门经理，由各职能部门经理进行协调和沟通。这种类型的组织结构适合传统产品的生产项目，一个部门的工作结束，下一个部门的工作开始。所以职能型的组织结构不适合软件开发项目。

图 2-15 职能型组织结构

纯项目型（Projectized type）在这种组织形式中，以项目经理为核心构造一个完整的项目组，包括各工种人员，如图 2-16 所示。项目经理拥有领导权，项目内所有成员直接向项目经理汇报。每个项目就是一个独立自主单位。它就如同一个子公司那样运作，拥有完整的人员配备，包括技术人员、行政人员和财务人员等。

图 2-16 纯项目型组织结构

矩阵型（Matrix）由于职能型和纯项目型是两个极端的代表，为了综合它们各自的优势，矩阵型应运而生。它是职能型和纯项目型的结合体，项目内的成员受项目经理和职能经理双重领导。如图 2-17 所示，项目 A 和项目 B 的成员是由不同职能部门的人员组成的，这些人员由项目经理进行协调组织工作，同时他们还要受其职能部门经理的领导。

图 2-17 矩阵组织结构

通过前面的介绍，大家可以看出，每一种组织结构形式都有其优点和缺点。对不同的项目，应根据项目具体目标、任务条件、项目环境等因素进行分析、比较、设计或选择最合适的组织结构形式。通常来说，职能式的组织结构适用于项目规模小、专业面单一、以技术为重点的项目，如某种设计原型的研究；对于大型的、重要的、复杂的项目，应采用纯项目式的组织结构；而对于项目周期短以需要多个职能部门参与的，则应选择矩阵式组织结构。当然，这 3 种组织结构是最基本的类型，在项目实战中，还有很多其他的演变类型，如弱矩阵、强矩阵和混合型等。项目管理者必须针对具体的项目特点和实施要求，选择合适的组织结构。软件项目基于自身的特点（需求多变、技术复杂、多方快速交流等），一般都会采用偏项目型的组织结构。

2.6.2 软件项目的组织架构

选定组织结构类型只是软件项目组织架构的第一步，我们还要清晰地设计出组织架构中各种角色及其相互关系和其岗位职责，以便每个团队成员都能在其位尽其才，并高效地发挥团队潜能和积极性，最终实现项目的目标。

软件项目的组织架构是以项目经理为核心领导，由各个分工不同的任务组所构成的。图 2-18 所示为一个典型的项目内部组织结构图。首先由项目总监对项目立项，其下设有项目经理和各个项目组。

图 2-18 软件项目组织结构

图 2-18 反映了软件项目的任务组成以及不同工种之间的平行关系。有时，人们还关心项目

图 2-18 软件项目组织结构

图 2-18 反映了软件项目的任务组成以及不同工种之间的平行关系。有时，人们还关心项目是如何运行的，即从形成决策到执行的不同层次之间的关系。图 2-19 展示了这 3 层 ------ 项目决策层、项目管理层和项目执行层之间的关系和主要的工作内容，而表 2-5 详细地描述了软件项目中的主要角色及其职责。

图 2-19 项目决策层、项目管理层和项目执行层之间的关系

表 2-5 软件项目主要角色和职责描述

角色	角色描述	主要责任
项目总监（高级项目经理）	项目管理最高决策人，对项目的总体方向进行决策和跟踪	对项目立项、撤销进行决策；任命项目经理；审批项目实施计划；负责项目实施过程中的重大事件的决策；根据项目过程中的进度、质量、技术、资源、风险等实行宏观监控
项目经理	项目经理直接报告给项目总监，负责完成项目的具体管理，是项目综合管理的焦点，是客户、高层和部门沟通的中心	在一定的时间、成本、品质和技术要求下，交付产出的成果；负责管理预算、工作计划及所有项目程序（范围、风险和难题等）；建立团队鼓舞士气；协调项目组内人员的分工合作，资源分配；为项目成员设定合理、有挑战性的目标；向项目总监汇报项目状况，提出建议及改进措施；与用户进行有效的沟通协调，争取关键用户的支持
业务组	完成软件项目的需求任务小组	负责项目原始需求的收集，并争取关键用户的支持；参与需求评审和需求变更控制；负责系统确认测试的实施和完成（即产品交付之前的客户模拟测试，因为这个小组是最清楚客户需求的）
架构组	负责建立和设计系统的总体架构	负责用户需求汇总和分析；负责系统总体设计；指导程序员的详细设计；配合系统的集成测试
开发组	负责完成系统的详细设计和编码任务	负责完成系统的详细设计；负责完成软件代码编写；负责完成软件的单元测试和集成测试；发送完成软件包给测试人员；修复代码中的错误
测试组	负责计划和实施对软件的测试，以确保软件产品满足其需求	负责计划、设计和编写测试用例；负责实施测试用例，并对软件完成功能测试、系统测试和接收测试；提交软件错误（bug）给程序人员，并跟踪直到错误解决；提交测试结果和完整的测试报告
质量组	负责计划和实施项目的质量保证活动	负责质量计划的编制、实施、监督和控制；提交质量计划和实际结果的差异报告，提出差异原因和改进方法；不定期召开质量会议讨论质量提高方案
配置组	负责计划、协调、实施和维护项目的配置管理活动	负责软硬件配置项的定义；负责基线建立和维护；负责版本控制；负责软硬件的分配；负责开发测试环境的搭建和维护

前面所描述的都是软件项目中典型的的角色划分，我们还可以根据具体项目来定义某些特别的角色。角色和项目组成员是两个不同的概念，一个成员可以兼多个角色，而一个角色可以由多个人承担。如在大型项目中，有多个项目经理，几百个开发人员和测试人员；而在小型的软件项目组织中，部分角色可以兼任，即一个人可以兼任多个角色，但是开发组和测试组应尽量保持独立运行。

对软件开发和软件测试这两个角色，在软件项目开发过程中对整个软件质量的好坏起着关键性的作用，而它们之间的相互联系也是十分密切的。很多人在软件开发过程中，经常忽视这两种角色的不同职责和作用的重要性。这种现象在规模较小的软件企业中比较多见，一个开发人员经常身兼多职，既要承担设计、编写代码等工作，又要充当测试人员，同时可能还要兼顾保证项目质量。这样做的后果是显而易见的。一心多用，缺乏专注：做事片面，不能从多个角度考虑问题：人为因素增加，制度规范约束力降低，缺乏有效的制约和监督，这对保证软件质量是极为不利的。但近年来盛行的敏捷 Scrum，倡导多角多能（Cross Functional- 多面手），每个人都可以胜任项目中的任何模块的开发和测试工作。这个理念非常好，但是实际情况是我们的人员素质很难达到这个要求，我们要逐步往这个方向努力。可以通过培训，结对工作，知识讨论共享等方式来逐步改进。

图 2-20 所示为微软公司开发产品的基本组织机构图，其中程序经理基本上分为 3 类：项目经理、设计经理和其他辅助经理（如业务部门、市场部门等协作部门经理，以及用户培训经理等）。程序经理的使命就是和客户保持沟通，协助项目组按时提供高质量的软件产品。

在 Chandler 项目中，组织结构开始有点乱，分不清谁是主要负责人和决策人。有时在一个设计问题上各有各的说法，观点难以统一，而且也没有人来做最后的定夺，导致浪费了不少的时间。后期虽然米奇指定了相关负责人，但是很多分歧和争议还是要由米奇来定夺。在 Chandler 项目中，缺乏项目管理的工作，也是项目失败原因之一。

2.6.3 软件项目经理

一位牧师正在考虑明天如何布道，他 6 岁的儿子总是来搞乱。情急之下，他将一本杂志内的世界地图页撕碎，递给儿子说："来，我们做一个有趣的拼图游戏。你回房里去，把这张世界地图还原。"

谁知没过几分钟，儿子又来敲门，并说图已经拼好。父亲大惊失色，急忙到儿子房间去看，果然那张撕碎的世界地图完整地摆放在地板上。

"怎么会这么快？"他吃惊地望着儿子，不解地问。

"是这样的，世界地图的背面有一个人头像，人对了，世界就对了。"

牧师爱抚着儿子的小脑袋若有所悟地说："说得好啊，人对了，世界就对了！"

在第 1 章我们已经阐述了软件项目管理是"以人为本"的，在此过程中需要充分地集成技术方法、工具、过程、资源（人力、资金、时间等）等要素，谁来领导这个集成（综合性）的工作呢？自然是软件项目经理。软件项目经理是整个软件项目的权威和灵魂。《三国演义》中的诸葛亮就是一个很好的项目经理。他的军事才能和领导管理才能都是毋庸置疑的。如果没有诸葛亮对刘备的团队进行规划、组织、指导和协调，也就没有三分天下的蜀。在软件开发过程中，如果能选对人，放对位置，做对事情，那么做出的软件也就对了，成功的几率会大大地增加。由此可见，项目经理是多么的重要，选择了合格的项目经理也就是选择有了有效的项目管理。由此可见，项目经理是何等的重要，选择了合格的项目经理也就是选择了有效的项目管理。由此可见，一个合格的项目经理必须具备以下良好的自身素质和较强的管理、技术能力。

自身素质

项目经理在整个软件项目开发过程中要和很多形形色色的人交流，包括高层、客户、项目成员等。项目经理是整个沟通链的灵魂人物，必须能够有效地理解其他人的需求和动机，并具有良好的沟通能力。项目经理的能力首先体现在个人素质方面，如热情、专注、执著和勤奋等：其次体现在团队合作方面，具有良好的素质。

亲和力------领导团队走向成功的基础。
号召力、感染力------调动下属工作积极性的能力。
威信力------公私分明、信守承诺。
沟通表达力------理解他人行为的能力，有效表达自己的意见，最后达到双赢的目的。
应变能力------灵活、知识面广。

管理能力

在第 1 章，我们提到了有效的项目管理集中在对 3P 因素的管理上。现在我们又从 3P 角度来分析项目经理应具有的管理能力。从项目流程的角度看，项目经理要具备计划、组织、控制和指导项目的能力；从人员的角度看，项目经理又必须对现有的人力资源进行合理的选择、分配和调整；从处理问题的角度看，项目经理必须先分析出问题的根本原因，再找出问题涉及的项目各部分之间的相互联系和制约关系，最后和项目成员一起讨论出彻底的解决方案。

技术能力

软件项目对项目经理的要求是懂技术，不要求精通，但要全面。因为项目经理要处理项目组之间的内外协调工作，就必须有足够广博的专业知识，而技术的细节问题则是由项目的开发组长、测试组长或其他工程师来处理。

2.6.4 QA 与 QC

近年来，QA（Quality Assurance）和 QC（Quality Control）两种角色经常被提及。他们虽然都属于项目质量保证的范畴，但是在实际的项目管理中，他们的关系比较容易混淆。下面对它们的关系进行说明。

● QC------质量控制者，检验产品的质量，保证产品符合客户的需求，是产品质量检查者。在软件开发过程中，QC 其实就是测试组成员。QC 所关注的是产品，而非质量体系或组织流程，这是他与 QA 的主要区别。 ● QA------质量保证者，通过建立和维持质量管理体系来确保产品质量没有问题，是过程质量审计者。在软件开发过程中，QA 就是质量组成员。QA 所关注的是软件产品质量保证体系。

表 2-6 所示为 QA 与 QC 在项目各个不同阶段工作内容的比较。

表 2-6 QA 与 QC 各个阶段工作对照表

阶段	QA 工作内容	QC 工作内容
项目启动	定义产品质量指标
参与项目规划的评审
项目计划	编制 QA 计划	测试计划管理
过程审计	参加评审
需求分析	阶段交付物审计	分析测试需求
过程审计	参加评审
设计	阶段交付物审计	设计测试用例
过程审计	参加评审
可能的话参与部分设计
编码	阶段交付物审计	单元测试
过程审计	集成测试
参加评审
测试	阶段交付物审计	集成测试
过程审计	系统测试
性能测试	回归测试
测试管理工作	用户手册验证
实施	产品质量状态评估	内部验收测试
过程审计	验收测试
项目交付审计

QA 和 QC 各司其职，相辅相成。拿一部汽车来作比喻，质量控制者（QC）就是所有那些显示汽车当前各种状态（速度、发动机转速等）的仪器仪表；质量保证者（QA）包括各类标准，是写有所有部件操作方法的用户手册。QA 和 QC 的工作内容虽然不同，但工作性质是不冲突的，所以这两种角色可以单独存在，也可以由同一角色担任。

在微软公司中，QA 和 QC 是由同一角色担任的，统称为 Quality Assure，就是测试与评估软件项目品质的人员。

在印度的知名公司（如 TCS、Infosys 和 Wipro）中 QA 和 QC 是由不同的角色担任的。在一个项目中会有 1 到 2 个 QA 人员负责监督和确保项目的进展遵循各项流程和模板，并收集项目中发现的一些问题和解决方法以优化流程。

2.7 车件软件项目干系人

先说一个身边的小故事。同事计划搬新家（刚刚装修好的），搬家公司都联系好了，就在搬家的前晚，同事把事情告诉了婆婆。婆婆说了一句话"你们的新房环境指标合格吗？"同事还真的忘记测试环境指标了，结果导致这次搬家计划失败。我们可以把搬家当作一个项目来看，这次项目失败的原因就是没有考虑到婆婆这个干系人。

软件项目干系人（stakeholder），也称软件项目的相关利益人，PMBOK 是这样定义的，是指积极参与项目或其利益在项目执行中或成功后受到积极或消极影响的组织和个人。干系人也可能对项目及其可交付成果和项目团队成员施加影响。图 2-21（引用 PMBOK）所示为项目、项目团队和项目干系人的关系。

在软件项目的开发过程中，项目相关利益人分析管理不足是造成项目负面影响的一个重要因素。例如：在一个矩阵型的组织中，高层决定启动一个新的项目，要求几个部门在限定的时间内联合完成。但是有个别部门站在自己的角度，认为新项目会"冲击"部门利益，导致部门的重要性降低、权力变小等，因而对于项目的实施不配合，这就对项目的整体影响很大。

在 Chandler 项目中，还有个致命的缺点，就是那些技术让人们忽略了"使用者"这个相关利益人。有网友说："做技术的人，尤其是对技术痴迷的人，遇到一个问题首先想到的不是用户的体验，而是自己在技术上的快感，好像不用点什么新鲜的技术就对不起客户似的，其实这些都不是用户关心的。用户关心的是什么？用户关心的只是实现！只要能实现客户的业务需求，那用什么技术用什么方式真的有很大关系吗？"所以米奇最初的想法其实是不对的。他不想用 server 来实现信息传递，但是用 P2P 最后也没有能够实现，还是绕了回来用 server。其实大可不必这样做，可以先满足需求，之后再来研究别的途径是不是更好。

对软件项目中涉及的各种干系人的利益和影响进行分析并加以有效引导是非常必要的，尤其是在软件项目之初。为了明确项目的要求和所有相关方的期望，项目管理团队必须在项目进行过程中识别所有的内部和外部干系人。为了确保项目成功，项目管理团队还必须针对项目要求来管理各种干系人对项目的影响。一个项目团队必须明确地识别项目干系人，分析每个干系人对项目的要求或需求，满足不同的干系人，从而确保项目的成功。如在一个软件项目开发中，某个核心程序员因为感情问题而心情不好，项目经理就需要关注他 / 她最近的日常举动、言语，给予支持、鼓励或多谈心，适当地减少他 / 她的工作量，让他尽快调整重新加入到项目中来，避免项目进度延期等情况发生。如何有效识别、分析和管理干系人，请详见第 8 章第 6 小节。

2.8 软件项目项目启动动员会

万事俱备，只欠东风了。前面几节介绍的都是项目正式开始前的准备工作，一旦准备工作完成，就可以召开项目启动动员会（Kick off meeting）了。启动动员会的召开就是项目正式开工的标志。"Kick off"原意是足球比赛"中线开球"的意思，在项目管理中引申为项目启动动员会。下面，就详细介绍召开高效项目启动会议的注意事项。

会议目的项目启动动员会的目的是给团队鼓舞士气，确立项目统一的目标。万事开头难，有了一个确定的奋斗目标，大家就不再是一只只孤帆，而是一支舰艇，向着目标前进。
会前准备和其他会议一样，要想会议进行得高效，准备工作必须充分，包括会议时间、会议地点和会议议程等，如图 2-22 所示。会议议程是准备工作的重点，其内容大致可以包括以下几个方面。

项目背景、价值、目标。
项目进度、质量、资源的要求。
项目交付标准要求。
项目组织机构及主要成员职责介绍。
项目开发模型。
项目初步计划、风险分析和制约关系分析。
项目管理制度。
相关问题的讨论和解决。

参会人员应该包括项目组织内部人员和项目相关利益人员，如项目总监、项目经理、出资方代表、客户代表、供应商代表和项目组成员等。

会议进行会议开始后，可以按照事先安排的会议议程，按顺序阐述、讨论，并根据情况设定相关的后续行动计划（action item）。其中值得注意的就是在讨论环节的控制问题。如果各个部门对讨论的问题或解决方法有较大分歧时，项目经理应予以引导，必要时做出决定，如果决定不了可在会后进行一对一的讨论，给出几种解决方案请相应高层做出决定。
会议结束会议结束后，项目经理需整理会议记录给与会人员，并抄送给相关高层人员。项目经理要及时跟踪和报告相关的后续行动计划（action item）的进度和状态。

小结

本章讲述了软件项目启动之前的一系列标准的准备工作，包括从软件项目的立项、可行性分析、合同签署、软件开发模型、确立组织结构直到软件项目的正式启动。本章还介绍了在项目准备工作中几种常用的方法，如可行性分析的 NPV、决策树方法，还有项目利益相关人员分析的影响力量/利益矩阵和 SWOT 分析方法等。

本章重点阐述了软件项目可行性要素分析，选择适合的软件开发模型，软件项目的内部组织结构和角色划分，以及软件项目相关利益人分析等过程，使读者从中掌握项目准备和启动过程中一些关键环节所需的方法和技术。

习题

软件项目的可行性分析包括哪些方面？影响决策的关键因素又是什么？
项目的组织结构主要分哪几类？软件项目的组织结构通常采用哪一类？
软件开发模型有哪些？各自的特点是什么？针对你的项目会选择哪个模型？
针对 XP 和 Scrum 两种开发模式进行比较，了解它们有什么不同和各自的优势。
针对 BDD 和 FDD 两种开发模式进行比较，了解它们有什么不同和各自的优势。
用一句话概括软件项目经理的作用是什么，软件项目经理应具备哪些能力和素质？
什么是软件项目相关利益人？如何对他们进行分析和管理？
一个软件企业现在面对两个项目的抉择，他们经过分析得出这样的结论：如果做 A 项目，盈利的概率是 20%，可以盈利 30 万元，但是同时亏损的概率是 80%，亏损 4 万元；如果做 B 项目，盈利的概率是 70%，盈利 6 万元，同时有两种亏损的可能：其一是 10% 的概率亏损 2 万元，其二是 20% 的概率亏损 5 万元。请用决策树的方法计算出两个项目的预期收益，并判断哪个项目是比较有利的选择？