第3章 过程规划
引言
在许多其他项目中也会出现与此非常雷同的情况。在实际情况中，几乎不存在某个标准过程或者以往某个项目所用的过程是最适合于当前问题的过程。为了找到最合适的过程，就要根据新问题对现有过程进行裁制。
3.1 Infosys开发过程
软件开发模型
软件开发存在几种过程模型。最常见的模型包括瀑布模型、迭代式增强模型、原型法开发模型和螺旋模型。
使用最广泛的模型是瀑布模型，它按线性顺序组织各开发阶段，但是大多数实现都对这个模型进行了改进, 以使它的缺陷最小。
为了决定使用哪种过程，项目经理必须选择基本过程，同时还要决定如何对它进行裁制以得到适合项目的过程。
3.1.1 标准过程
Infosys公司采用的标准过程类似于瀑布模型，但是原来的各个阶段被划分成更小的阶段，或者说状态，以允许并行地执行某些阶段。
例如，可以将系统测试的规划定义为系统测试 本身的一个独立的阶段，这是一种使团队可以并行地执行系统测试规划阶段和编码阶段的实践，尽管系统测试在编码完成后才进行。
该标准过程的各阶段包括需求分析、概要设计、详细设计、构建、单元测试、集成计划、集成、系统测试计划、系统测试、文档、验收和安装、维护支持。
对于进行迭代式开发或者原型法开发或者仅执行生命期中某些阶段的项目，也可以采用该基本过程。在这些情况下，需要对这个基本过程加以调整才能满足项目的需要。这些调整通过过程裁制（process tailoring）完成。
3.1.2 过程裁制
任何一个已定义的过程（不管是一个组织的标准过程，还是以往某个项目采用的过程）都不能完全满足所有的情况和所有的项目。
已定义的过程需要经过裁制才能满足当前项目的需要。
裁制是指调整组织以前定义的过程以获得一个适用于某个项目的特定业务或者技术需要的过程。
可以将裁制看成添加、删除、修改一个过程中的任务，使得最终的过程更加适于实现项目的目标。
为什么需要裁制指南
不受控制的裁制实际上意味着从头开始建立一个过程。
为了有效地使用以往定义的过程，有必要提供一些裁制指南。
– 这些指南定义了应当对一个标准过程进行修改的条件和类型。
– 实质上，指南定义了标准过程允许的偏差（permitted deviation），希望能够为项目定义一个较优的过程。
裁制的必要性例: 代码评审
为了说明裁制的需要，让我们看看开发过程构建阶段中的一个任务——代码评审。
在许多情况下代码评审会大大地增加价值，但是增加的价值并不与所需的工作量相称。
此外，评审既可以由一个小组完成（遵循小组评审程序），也可以由一个人完成。
标准开发过程没有规定应当如何执行代码评审。
通过只为某种类型的程序（例如复杂程序或外部接口）建议执行代码评审任务和建议较优的评审方式（小组评审，或者个人评审），裁制指南能够为项目经理提供帮助。
Infosys公司采用的裁制方法
Infosys公司采用的裁制方法类似于金斯伯格（Ginsberg）和奎因（Quinn）提出的基于表的方法，项目经理规定过程要素、可裁制的属性、每个属性的选项以及选择特定选项的原因。
项目经理可以在两个层次上执行裁制：概要级裁制和详细级裁制。
概要级裁制（Summary-Level Tailoring）
在概要级裁制，项目经理根据项目特征，应用总体指南对标准过程进行裁制。即，它提供了一些关于某些类型的详细任务的基本规则。执行该步骤时，项目经理首先标识出项目的某些特征。对于开发项目，过程裁制将用到如下特征：
– 团队和项目经理的经验和熟练程度
– 团队人数最多时的人数
– 需求透明度（clarity of the requirement ）
– 项目持续时间
– 应用的关键程度
特征值的确定
如果团队的大部分成员对项目所采用的技术有2年以上的经验，则设定这个团队的经验水平为高；否则为低。
如果应用程序对客户的业务或者Infosys公司的业务有非常显著的影响，则设定应用的关键程度为高，否则为低。
如果项目必须在3个月内完成，则认为项目的持续时间非常短。
对于这些特征的不同值，都提供了概要级裁制指南。概要级裁制指南一般与评审、工作量、进度计划、资源及过程形式化有关。
与评审有关的裁制指南通常规定什么时候执行评审以及应当执行什么类型的评审。这些基本指南规定了详细级过程裁制的环境，并为项目定义了一个合适的过程。
详细级裁制（Detailed Tailoring）
详细级裁制涉及任务的执行、任务的评审和文档化需要。
裁制指南可规定一个任务是可选任务，若任务是可选的，则项目经理可以决定是否执行该任务。
同样，某些文档的准备也可以是可选的，如果文档是可选的，则项目经理可以决定项目是否需要该文档。
对于评审，一般有小组评审、个人评审和不评审。此外，项目经理也可以增加一些新的任务或者可以重复某些任务。
详细级裁制完成后，项目过程要执行的任务序列就定义好了。然后，这些定义就可以用来规划和调度任务，构成项目执行的基础。
因为裁制的执行是项目计划中最重要的任务，所以在评审计划时也要评审过程定义和裁制。
3.1.3 裁制示例：短期项目的裁制
我们通过介绍短期项目的概要级裁制来说明裁制的概念。
Infosys公司注意到软件项目的持续时间在逐年下降，并且对持续时间非常短的项目的需求有所增加。
显然，这种项目要求对标准过程进行裁制，以允许最大程度地并行执行和非常严格的项目监督和控制。
过程裁制取决于需求的透明度、团队和项目领导的经验水平、团队的规模等等。
因为进度计划的主要特征是短期性，所以与进度有关的指南建议采用所谓的时间盒控制法（timeboxing）技术和微型里程碑。
对于时间盒控制法，规划以几周为限的周期，并在每个周期结束后交付一个工作系统。
为了严格控制时间盒，还要设定微型里程碑（周期内的里程碑）。在微型里程碑处，只需进行有限的里程碑分析。
3.2 需求变更管理
需求会发生变化，并且需求的变更可以在项目生命期的任何时间发生（甚至在项目生命期结束后发生）。
需求变更越是在生命期的后期发生，对项目的影响越严重。
除了希望不会发生那样的变更，或者希望初始需求做得非常完善并不需要任何变更外，更好的做法是在出现需求变更时处理变更申请。
不受控制的需求变更会对项目的成本、进度和质量产生有害的影响。需求变更最多可以占总成本的40%。
例1:
拉维意识到迫切需要一个需求变更管理过程。
– 为努力使客户感到满意，他欣然同意客户申请的变更。
– 由于没有对变更申请加以控制，因此项目经历的需求变更越来越频繁。
– 最后，团队成员不得不每周工作60 小时，并且工作量增加100% 以上，拉维才勉强地完成了项目。
– 更糟的是，他发现客户仍然感到不满意，因为他认为变更的越多会使产品更好。
例2:
在另一个项目中，玛丽（Mary）是一位经验丰富的项目经理，她记录客户每次通过电话或者e-mail发出的变更申请，然后告诉客户有关变更申请对工作量和进度产生的影响。
不仅变更申请的频度随时间减少了，而且客户将很多申请转移到下一个版本中去实现。
最终结果如何呢？项目按时完成，客户感到很满意，并且为实现变更申请导致的额外工作量付费。
3.2.1 变更管理过程
在项目规划期间，项目经理决定遵循哪个过程来处理变更申请。计划的过程要与客户进行讨论，以便客户和厂商在如何管理变更方面取得一致意见。
通常，变更管理过程规定如何发出变更申请、何时需要正式批准，等等。在出现需求变更申请时，必须执行需求变更管理过程。
因为变更申请意味着需要额外的工作量，所以必须在额外的工作量支付方面取得一致意见。
通常，在客户认可的情况下，项目必须在实现变更申请方面留有一定的余地（通常占总的项目工作量的小百分比）。
这样一种预算条款简化了实现客户认可的变更申请的管理问题。
Infosys公司常用的变更管理过程
Infosys公司常用的变更管理过程包括如下步骤：
（1）记录变更。
（2）分析变更对工作产品的影响。
（3）估计变更申请所需的工作量。
（4）重新估计交付时间表。
（5）执行累积的成本影响分析。
（6）如果影响超出一定限度，则与高级主管一起评审影响。
（7）客户不再提出变更申请。
（8）修改工作产品。
变更申请日记
维护一个变更申请日记，以跟踪变更申请。
日志中的每条记录包含一个变更申请号、关于变更的简单描述、变更的影响、变更申请的状态以及关键日期。
在评估变更申请的影响时，必须执行影响分析。
影响分析涉及标识出需要进行变更的工作产品，并估算对每种产品的变更量；通过重新查看风险管理计划，重新评估项目风险；评估需求变更蕴涵的总的工作量和进度估计的变化。
客户对分析结果进行评审，并作出答复。
变更申请一般作为需求规格说明文档的附件。有时还要修改文档的有关部分以反映所做的变更。
监督已认可的变更申请并保证它们正确实现，这部分由配置管理过程处理。
实现变更所需的总工作量
如果实现变更所需的总工作量不超过某个预先确定的值（例如，2人日），则认为此变更是次要的。
– 次要变更通常作为项目工作量的一部分，利用计划的估计中预留的缓冲工作量。
主要变更通常对工作量和进度有更大的影响，并且必须得到客户的正式批准。
高级主管通过状态报告和里程碑报告掌握变更情况。
变更的累积影响
需求变更的一种危险是：尽管每种变更本身并不大，但是生命期中所有变更的累积影响却是很大的。因此，除了研究每个变更的影响并对它们进行跟踪外，还必须监督变更的累积影响。
对于累积变更，可以使用变更日志。为了简化这一分析，通常用电子表格对日志进行维护。
从这种类型的电子表格中，你可以直接看出目前已完成的需求变更的总成本。
前面提到过，Infosys公司的项目经理有时为处理变更申请预留一定的余地。
– 只要所有变更累积的工作量不超过这一预留的工作量，就不需要做任何特殊的处理。
– 然而，如果所有变更的累积工作量超过了这一预留的工作量，则再进行变更可能会对总成本和进度安排产生负面影响。在这种情况中，项目经理必须修改估计并使它们得到承认。
3.3 ACIC项目的过程规划
因为ACIC项目是一个开发项目，所以遵循标准的Infosys开发过程。
然而，对它进行了裁制以满足Rational统一过程（Rational Unified Process，简称RUP）方法的需求，因为向客户承诺使用RUP。
– RUP是一种迭代式开发方法。
Infosys公司采用的过程裁制指南支持迭代式地执行不同阶段，但要在每次迭代中执行分析、设计、编码和测试任务。
对标准过程所做的主要修改
除了进行迭代式开发外，为了满足RUP方法，需对标准过程做如下主要修改：
– 只有在特定迭代中开始使用的用例才在该迭代中进行详细描述。
– 在最初几次迭代中，增量式地开发逻辑对象模型和物理对象模型。
– 物理数据库设计可以在以后的迭代中进行细化。
– 每次迭代将开发一个单元测试计划。
– 记录每次迭代过程发现的故障。
此外，不准备用标准的可跟踪性矩阵机制进行需求跟踪。相反，将用Requisite Pro工具跟踪需求，该工具是开发环境的一部分。
需求变更管理将使用标准过程。
尽管在每次申请时都进行影响分析，但是，如果一个变更申请可能要占总工作量的2%以上时，则必须对影响进行重新估计。
过程规划结果在项目管理计划中进行记录。