Monthly Archives: December 2007

第8章  项目管理计划 项目管理计划（project management plan，简称PMP）文档是项目经理承担的所有规划任务的核心。 各种规划任务的结果都出现在该文档中，它是指导所有项目执行的基准文档。 不应当将它与详细的项目进度计划混淆起来，后者仅仅表示任务的进度和分配。 用文档记录规划任务的结果，就可以对项目计划进行评审，找出其中存在的缺陷。 在Infosys公司，项目通常由项目经理、SEPG成员和高级管理人员组成的团体进行评审。 很多情况下，项目计划评审会揭示出显著的缺点，如果不纠正它们就有可能给项目添加麻烦。 对管理计划进行全面的评审是将潜在的问题扼杀在萌芽状态的最佳方法之一——对项目经理非常有用，尤其是那些经验不多的项目经理。 该文档还能在交流方面起到重要的作用。 它向高级管理人员提供了项目目标和任务的总体视图，描述了为了实现这些目标应当如何对项目进行管理。 它为项目团队提供了一个综合的项目视图及各团队成员的角色。 尽管我们已经讨论了大部分规划任务，但我们至今还没有讨论团队与沟通问题，本章对它们进行了讨论。 本章还讨论了Infosys公司用于记录计划的模板结构，研究了ACIC项目的项目管理计划。 8.1  团队管理 软件开发是一种团队工作。 只有团队成员全力以赴并保持高度的积极性，并且整个团队稳定而高效的发挥作用，才能够实现高质量和高生产率。 团队管理不仅仅是软件工程和项目管理问题，而且还涉及人员管理问题。 人员管理是项目的一项重要内容，如果忽略它，会给项目和项目经理带来麻烦。 8.1.1  团队结构 在Infosys公司，通常采用层次性团队结构； •     一个团队由一个项目经理 领导，他向业务经理或者财务经理（或者同时向两者）报告。 •     此外，一个典型的团队由开发人员 （DV ）、配置控制人员 （CC ）和数据库管理人员 组成；所有这些成员都向项目经理报告。 •     一个大型项目可能还有模块领导 ，他们都向项目经理负责，并且他们底下还有一些开发人员。 •     此外，还从现有的团队成员中选出一些人组成一个故障预防团队 … Continue reading →

第9章   配 置 管 理在一个软件项目中，由于工作产品的发展和需求变更而产生的变化，会接连不断地发生。所有这些变化最终将体现在包含源代码、数据或者文档的文件中所发生的变化。在一个软件项目的大量文件由多人共同创建的情况下，如果他们都可以对这些文件进行变更，则必须对这些变更进行正确地控制，否则问题会复杂化。考虑下面这些取自各种不同项目的情况：    假定客户提出了两种不同的变更申请。项目经理将一种申请交给Rao去实现，而将另一种申请交给Meera去实现。两人都必须修改模块X的代码。当Meera完成她的修改时，她保存了模块X的文件，并不经意地地覆盖了Rao几天前完成的修改。    一个模块由三个团队成员开发代码，其最后交付期限是周五。他们计划在最后2天集成经过单元测试的代码。Subbu是几个关键函数的开发者，他突然在周二晚上离开团队要去办一件紧急事情。次日，模块领导和团队成员花了很长时间来研究Subbu的文件。他们设法标识出那些包含Subbu正在开发的各种函数的文件，但是他们发现这些文件有很多个版本。因此，他们不得不让其中一个团队成员来解决该问题，该团队成员一直到周末才完成该任务。他以Subbu开发的某个版本的程序开始，开发了Subbu的程序单元并对该单元进行了测试，他重做了Subbu离开团队前几乎已经完成的工作。最后，模块的交付时间推迟了3天。    Srinath团队的精神状态很好。他们按时完成了项目开发，并且最后的测试也没有出现问题。软件被交给客户去实施。次日，Srinath收到了来自用户和客户的气愤的电子邮件，他们报告了软件存在的问题。经过团队紧张的工作，终于找到了原因：软件的发行版中的某个关键组件使用了旧版本。诸如此类的问题可以在许多组织中发现。配置管理（configuration management，简称CM）也称为软件配置管理（software configuration management，简称SCM），是项目管理的一项内容，主要涉及对变更进行系统的控制以防止此类问题的发生。 本章首先讨论一些与CM有关的基本概念，然后讨论Infosys公司遵循的CM过程。此外，还给出了案例研究的CM计划。 9.1  配置管理概念CM对于实现项目中的一个基本目标很重要：将高质量的软件产品交给客户。这种交给客户的“软件”是什么呢？它至少包含构成源和对象代码的源和对象文件、从这些文件建立工作系统的脚本及其相关文档。在项目执行期间，文件变更会导致不同版本的软件的建立。在这种情况下，程序管理员如何保证组合了正确版本的源代码文件，而又没有遗漏源代码呢？又如何保证发送了与最终的源代码一致的正确版本的文档呢？所有这一切都通过正确的CM得到保证。CM的一个主要目标是对软件系统不断变化的配置进行管理。在一个项目中，一个程序的发展要经过很多阶段。•    最初开发它时，程序处于开发状态（或者“私有”状态）。•    在程序员对程序感到满意之后，程序就进入了“准备单元测试”状态。•    只有当程序达到这个状态时，才能对它进行单元测试。•    在程序经过单元测试后，必须修复发现的所有问题。•    如果成功地通过了单元测试，则进入“准备系统测试”阶段。•    只有在所有程序都达到这个状态时，才可以开始系统测试。•    此外，如果在系统测试阶段发现故障，则程序状态返回到“私有”状态；否则程序进入“准备验收测试”状态。•    如果验收测试成功，则所有程序的状态改变成“准备发行”状态，表明可以发行它们，并进入“生产使用”状态。•    程序被发行并处于生产使用状态后，所有程序及相关文档都进入“基准（baselined）”状态，它代表生产系统的状态。除了正常的软件开发期间发生的变更，需求变更申请还可以通过提交渠道进行提交，并且它们的实施可能会改变程序。当一个项目有大量可以被变更的条目时，可能会要求开发人员采取很多措施；只有在CM过程的正确支持下，才能执行这些措施。为了更好地理解CM，让我们考虑一下项目要求的各种CM功能。尽管这些需求依赖于项目的性质和具体情况，但是某些基本功能是可以确定的。下面列出了其中一些功能，以及那些可能需要它们的环境。    给出程序的状态。你需要此信息来决定何时开始测试或者何时发行软件。    给出程序的最新版本。假设必须对一个程序进行修改。显然，必须在最后一个版本中实现修改；否则，前面的修改可能会被丢失。    处理并发更新申请。在响应两个不同的变更申请时，两个程序员可能会并发地修改同一个程序。其中一个的修改有可能覆盖另一个的修改。为了避免这种情况的发生，需要有访问控制机制，使得在某一时刻只有一个人能够对程序作出修改。如果允多人并行地修改，则应当实施协调过程以保证最后的版本体现出所有的修改。    取消一个程序变更。对一个程序作出某种变更后（为了实现某个变更申请），但后来出现某个申请，需要撤消这种变更申请。    防止未授权的变更或者删除。程序员可以决定变更某些程序，但是发现这种变更有负面影响。为了拒绝接受未授权的变更，需要有访问控制机制。    提供需求变更申请和程序变更之间的可跟踪性。假设一个需求变更申请规定要对三个程序进行修改，并且这些修改任务已经分配给三个团队成员。项目经理如何保证他们正确地实现了该变更申请呢——即，如何保证所有程序都已被修改过，并且修改过的程序正处于生命期的“准备发行”状态呢？该问题的答案是要求一种跟踪变更申请的机制，它可以规定所有要进行修改的程序以及每个程序的状态。    取消一个需求变更。某个已经被实现的需求变更申请（通过改变很多程序），事后可能需要被撤消（也许因为客户不喜欢变更后的新特征）。    显示相关的变更。假设在某个程序中发现了一个bug，并且怀疑这个bug是由于实现某个变更申请而引起的。则必须检查所有因那个变更申请而导致的变更。    收集当前系统的所有源代码、文档和其他信息，以便在文件遭到破坏或者系统崩溃时能够恢复所有文件。同样，可能需要对现有系统（正在运行的系统）作出某种变更，所以必须收集所有代表当前系统的源文件和文档。 上面所列的情况是一个项目中经常发生的需要CM过程支持的情况。此外，如果某个软件产品有多个版本同时存在，并且每个版本的软件产品使用一个不同版本的程序，则可能出现其他与变更相关的情况，要求CM具备额外的功能（例如，处理变体）。CM的主要目标是提供处理前面列出的各种情况的机制。这些机制包括：    文件命名和组织的约定    版本控制    变更申请的可跟踪性    访问控制    协调过程    修改登记程序根据标准约定命名程序文件（和文档文件），并把文件保存到指定的目录中，这有助于迅速发现某个所需的文件。正确的命名（例如，通过使用标准的扩展名）还有助于开发人员容易地理解文件内容的本质，而不必查看文件内容。此外，将程序根据它们的状态分别保存到不同的目录中，这有助于开发人员轻松地识别出程序的状态。版本控制是CM的一个关键问题，有许多工具可以帮助管理这个任务。版本控制有助于保护程序的旧版本，而不管程序如何变化。如果没有这么一种机制，则系统不能支持许多必须的CM功能。变更申请跟踪性机制提供了从一种需求变更申请到随后的程序变更的映射，有助于需求变更的管理。为了找到变更申请之前的变更，一种有效的办法是借助于修改日志。访问控制机制保证只有被授权的人员才能修改某些文件，并且在某一给定时间只有一个人能够对一个文件进行修改。协调程序规定了如何合并对一个程序独立进行的两次修改，建立一个新版本，以体现这两次修改。如果这些机制都被提供了，则可以令人满意地处理前面给定的情况。这些情况中的一些需要采用多种机制。例如，取消一个需求变更牵涉到一种表示从需求变更到随后的程序变更的可跟踪性机制，以及一种版本控制机制以切实地取消变更。一些CM机制可以得到某个工具的支持，而另一些可能需要用户显式地执行它们。例如，版本控制可以通过一个工具而实现，但是获取一个程序的状态可能要求程序员显式地维护这种信息。CM过程定义了实现这种机制的所有步骤，并说明了如何在项目中使用这些机制。前面所讨论的内容主要集中于程序。项目所产生的文档（诸如需求文档、设计文档和计划）也需要配置管理。在一个项目的正常执行期间，一个文档往往会经历3个状态：“正在开发”、“正在评审”和“基准状态”。状态转移很明确。CM过程还必须实现文档的状态图。9.2  配置管理过程CM过程定义了支持CM机制必须执行的任务序列。与项目管理中的大多数任务一样，CM过程的第一阶段也是规划，确定那些需要进行配置管理的条目（称为配置项）、保存它们的位置、变更控制的程序等等。项目经理或者配置控制人员（CC）准备这个计划。然后该过程必须被执行，也许通过部署一个工具（工具的使用也要加以规划）来实施。最后，因为任何一个CM计划要求项目人员维护版本、将配置项保存到合适的位置，以及正确地作出变更等方面的训练，所以监督配置项的状态和执行CM审计是CM过程的其他任务。本章讨论CM过程的这三种任务。9.2.1  … Continue reading →

软件项目管理 教材：《软件项目管理实践》 背景 全球每年要完成上百万个软件项目，但有1/3左右的项目在成本和时间上都超出额定限度的125%以上。 这么多的软件项目失败的关键在于软件项目管理不正确 例如，目标不明确、计划不完善、采用新技术、缺乏正确的项目管理方法，以及人员不够等等。 能力成熟度模型（CMM） 第1章  软件项目管理简介 为什么众多软件项目会失败？ 有分析认为：1/3左右的项目在成本和时间上超出额定限度的125%以上。 最重要的一条失败原因是软件项目管理不正确。 例如，项目失控的主要原因有目标不明确、计划不完善、新技术、缺乏项目管理方法以及人员不够。显然，其中至少有3个原因（目标不明确、计划不完善、缺乏项目管理方法）与项目管理有关。另外2个原因（人员不足和采用新技术）可以说是风险活动，但风险活动的管理也是项目管理的一部分。 1.1  过程与项目管理 软件项目主要涉及两方面的任务：软件工程和项目管理。 软件工程方面涉及系统的建立，并重点关注如何设计、测试、编码等问题。 项目管理方面涉及如何正确地规划和控制软件工程行为，以满足项目在成本、进度和质量方面的目标。 小规模项目 如果项目的规模较小（比如说由1到2个人组成的团队工作几个星期的项目），可以用不太正规的方法实现它。 –  项目计划可能是一个电子邮件，它规定了项目的交付日期，另外还有可能规定了一些中间里程碑。 –  需求可能通过一个便条甚至口头方式进行通知， –  而中间工作产品（诸如设计文档）可能是在个人的便条本上草草写就的东西。 大型项目 在大型商业项目中，必须遵循那些经试验证明效果良好的方法，谨慎地执行每个工程任务，并且必须用文档正确地记录工作产品，以便其他人员能够查阅它们。 项目任务必须经过仔细规划，并将它们分配给执行项目的人员，然后在项目执行的同时对它们进行跟踪。 换句话说，要成功地执行较大规模的项目，必须在软件工程和项目管理这两方面增强正规程度和严格程度。 正规方法 正规方法要求用良好定义的过程来执行各种任务，以便结果更加依赖于过程的能力。 如果通过使用合适的度量手段在过程中实现了量化方法，则正规程度得到进一步的加强。 何谓过程？ 从技术上讲，对于某个任务的一个过程，它由执行该任务时应当遵循的一个步骤序列组成。 对一个组织而言，建议其工程师和项目经理使用的过程就远非一个步骤序列了；它们涵盖了工程师们和项目经理所掌握的已成功地执行项目的实践。 – 通过过程可以将好的经验同所有人共享，包括新员工。 – 这些过程有助于管理人员和工程师借鉴过去的成功经验，从而避开导致失败的陷阱。 … Continue reading →

第2章  项目规划基础结构 重蹈覆辙 每个项目经理都在努力工作，力争建立最优的项目过程来执行其项目和实现他能够实现的结果 –    尽管其他团队以前已经执行过类似的项目，并且他们的经验和数据能够极大地减轻项目经理的痛苦。 不仅项目经理从头开始重新进行他们的规划工作，而且他们“计划”重蹈他们之前的项目经理犯过的同样的错误。 解决问题的重点 解决这种困境的办法在于：建立一个所有项目的管理人员都能够访问的公共知识库（institutional memory）。 问题的重点在于如何建立这么一个公共知识库，并用它塑造项目规划的基础结构。 –     该知识库的要素是什么？ –     如何系统地记录以往的经验，并使它们可重用？ –    Infosys 公司又如何保持项目规划基础结构最新？ 关键要素 过程数据库（process database，简称PDB）：保存已完成项目的绩效数据。 过程能力基准（process capability baseline，简称PCB）：概括了各个项目的绩效，定量地规定了遵循过程所能达到的结果范围。 如果遵循相同的过程，就能预测出项目的结果范围 过程资源 （process asset ）：是一些文档，诸如检查表、模板、方法及所吸取的经验教训。 即总结以往经验的材料，它们能帮助项目经理和工程师有效地使用过程。 2.1  过程数据库 过程数据库(PDB)是项目过程绩效数据的永久性存储库，可以用于项目规划、预测、生产率和质量分析以及其他一些用途。 2.1.1  PDB内容 在项目规划期间使用PDB中的信息时，项目经理经常发现同类项目的信息非常有用。 为了实现相似查询，应当在PDB中保存项目的基本信息，诸如项目所用的语言、平台、所用的数据库、所用的工具、项目规模和工作量等等。 –     有了这些信息以后，项目经理就可以搜索和查找所有项目的信息。 –     … Continue reading →

第3章  过程规划 引言 在许多其他项目中也会出现与此非常雷同的情况。在实际情况中，几乎不存在某个标准过程或者以往某个项目所用的过程是最适合于当前问题的过程。为了找到最合适的过程，就要根据新问题对现有过程进行裁制。 3.1  Infosys开发过程 软件开发模型 软件开发存在几种过程模型。最常见的模型包括瀑布模型、迭代式增强模型、原型法开发模型和螺旋模型。 使用最广泛的模型是瀑布模型，它按线性顺序组织各开发阶段，但是大多数实现都对这个模型进行了改进, 以使它的缺陷最小。 为了决定使用哪种过程，项目经理必须选择基本过程，同时还要决定如何对它进行裁制以得到适合项目的过程。 3.1.1  标准过程 Infosys公司采用的标准过程类似于瀑布模型，但是原来的各个阶段被划分成更小的阶段，或者说状态，以允许并行地执行某些阶段。 例如，可以将系统测试的规划定义为系统测试 本身的一个独立的阶段，这是一种使团队可以并行地执行系统测试规划阶段和编码阶段的实践，尽管系统测试在编码完成后才进行。 该标准过程的各阶段包括需求分析、概要设计、详细设计、构建、单元测试、集成计划、集成、系统测试计划、系统测试、文档、验收和安装、维护支持。 对于进行迭代式开发或者原型法开发或者仅执行生命期中某些阶段的项目，也可以采用该基本过程。在这些情况下，需要对这个基本过程加以调整才能满足项目的需要。这些调整通过过程裁制（process tailoring）完成。 3.1.2  过程裁制 任何一个已定义的过程（不管是一个组织的标准过程，还是以往某个项目采用的过程）都不能完全满足所有的情况和所有的项目。 已定义的过程需要经过裁制才能满足当前项目的需要。 裁制是指调整组织以前定义的过程以获得一个适用于某个项目的特定业务或者技术需要的过程。 可以将裁制看成添加、删除、修改一个过程中的任务，使得最终的过程更加适于实现项目的目标。 为什么需要裁制指南 不受控制的裁制实际上意味着从头开始建立一个过程。 为了有效地使用以往定义的过程，有必要提供一些裁制指南。 –    这些指南定义了应当对一个标准过程进行修改的条件和类型。 –    实质上，指南定义了标准过程允许的偏差（permitted deviation），希望能够为项目定义一个较优的过程。 裁制的必要性例: 代码评审 为了说明裁制的需要，让我们看看开发过程构建阶段中的一个任务——代码评审。 在许多情况下代码评审会大大地增加价值，但是增加的价值并不与所需的工作量相称。 此外，评审既可以由一个小组完成（遵循小组评审程序），也可以由一个人完成。 标准开发过程没有规定应当如何执行代码评审。 通过只为某种类型的程序（例如复杂程序或外部接口）建议执行代码评审任务和建议较优的评审方式（小组评审，或者个人评审），裁制指南能够为项目经理提供帮助。 … Continue reading →

第4章  工作量估计和进度计划 引言 在很多工程方面，不正确的估计是项目管理失败的根源；软件工程也不例外。 当Infosys公司总经理南丹•尼尔克尼（Nandan Nilekeni）被问及他希望项目所需具有的一样特性时，他回答道：“没有意外”。 –    在客户满意度方面没有意外， –    在收入和利润方面没有意外。 一个项目出现这两方面的意外多半是由于工作量或者进度估计不准确。 对于估计问题既没有特效的办法，也没有现成的办法。然而，项目经理可以采用经以往的经验和数据验证过的指南来提高估计精度。 4.1  估计和进度安排概念 工作量估计通常在项目的初期进行，即在明确了所要构建的软件时。 但是在项目后期有更多的信息可供参考时，也可能要对工作量进行重新估计。 工作量估计可以根据直觉，也可以根据以往的经验，但是一种更加科学而理想的方法是采用估计模型。 软件项目中合理的估计很容易变成一种自我实现的预言: 人们努力地去满足进度计划（进度计划是从工作量估计中推断出来的）。 –    在软件项目中，甚至没有人能够精确地回答这样一个问题：“这种估计是正确的吗？”因为判断某个估计正确性的惟一办法是将它同实际所需的工作量进行比较。 –    由于人类心理学“在有效的时间内尽量扩大工作量”的原则中反映的基本原则，因此我们不能仅仅因为扩展后的工作量满足了估计的工作量就认为估计是正确的。 因此，项目经理的目标是制定合理的估计，既使目标得到满足，又不至于让项目人员感到筋疲力尽。 4.1.1  工作量估计模型 软件估计模型（estimation model）定义它所需的项目特征（需要这些特征的值或者它们的估计）以及用这些值来计算工作量的方法。 4.1.2  进度估计 在工作量已经知道或者确定以后，根据项目投入的资源（人员）量，就可以制定各种进度计划（即项目的持续时间）了。 –     例如，对于一个工作量估计是56 人月的项目，则一个7 个人工作8 个月的进度计划是可能的。 –     一个由8 个人工作7 个月的进度计划也是可能的， … Continue reading →

第5章  质量规划 直到最近几年，软件工程才经受到了制造业在很早以前就已经受过的悲剧般的质量概念——质量是在装配/开发过程结束之后但在产品即将交付使用前完成的任务。 一些有质量意识的项目经理通常计划在开发过程结束后进行系统测试，但是在开发时却不重视质量控制任务，而另一些项目经理甚至连正确的系统测试计划都没有，这是很常见的情况。 结果怎样呢？系统测试往往会发现比期望的故障多得多的故障。而修复这些故障所需的工作量也往往比计划的要更多，最终导致软件的bug很多，并且交付日期也比计划的要晚。 随着情况的好转，项目经理开始作评审与单元测试的规划。 但他们不知道如何判断这些措施的有效性及其所需的成本。 换句话说，项目仍然缺乏明确的质量目标、令人信服的目标实现计划，以及监督诸如单元测试等质量控制任务的有效性的机制。 在合理利用度量标准和以往数据的情况下，就有可能在对待质量问题上如同对待另外两个重要的参数那样：工作量和进度。 即，可以设置定量化的质量目标，以及有助于跟踪项目的质量目标实现情况的子目标。 本章讨论Infosys公司的项目经理如何设置项目的质量目标，如何制定实现这些目标的计划（这些计划用中间质量目标监督质量目标的实现情况）。 在描述Infosys公司采用的方法之前，我们先简单地讨论一些有关质量管理的基本概念。 5.1  质量概念 确保最终交付的软件高质量是项目经理最关心的事情之一。但是，如何定义软件质量呢？ 软件质量概念不容易定义，因为软件有很多质量特征。 实际上，质量管理通常围绕故障而展开。因此，我们用已交付软件的故障密度作为软件质量的定义——即，已交付软件中每个单位规模的故障数。 此定义是当前业界的事实标准。之所以用它定义软件质量，是为了表明软件项目的目标是使交付的软件具有尽量少的故障。 那么，何谓故障呢？ 同样，也没有关于故障的通用的且广为接受的精确定义（如果一个软件拼错了一个词，是否认为该软件有一个故障呢？）。 通常，我们认为软件的故障是某种使软件表现出与客户的要求或者需要不一致的方式进行运转的问题。 在考虑质量的管理技术之前，必须先知道故障引入和排除周期。 软件开发是一种高度依赖于人的任务，因此很容易出现错误。 故障可以在软件过程的任何阶段引入。 这些引入阶段主要有需求规格说明、概要设计、详细设计和编码。 对于高质量的软件，要求最终产品含有的故障数应尽可能地少。 因此，为了发行高质量的软件，必须积极排除故障；这可以通过评审和测试等质量控制任务而实现。 故障排除的成本随着故障潜伏时间（从故障引入到检测到这个故障的时间间隔）的增长而增加，任何成熟的过程都将在每个可能引入故障的阶段之后执行质量控制任务。 故障排除任务包括需求评审、设计评审、代码评审、单元测试、集成测试、系统测试和验收测试（我们没有包括计划文档的评审，但是这种评审也有助于改进软件的质量）。 质量管理的任务是规划合理的质量控制任务，然后正确地执行和控制它们，以实现项目的质量目标。 5.1.1  质量管理的过程化方法 前文已经提到过，通过执行评审或者测试可以检测故障。 评审是结构化的、面向人的过程，而测试是以一种试图识别出故障的方式执行软件（或者软件的一部分）的过程。 在质量管理的过程化方法中，评审与测试任务的过程和指南是既定的。 在一个项目中，这些任务都经过规划（即，执行哪个任务及什么时候执行是确定的）；执行时，根据已定义的过程实现这些任务。 总之，过程化方法在已定义的点上执行某些检测故障的过程。 过程化方法不支持声明已排除了多少故障或者故障排除过程结束后的软件质量。 换句话说，只执行一系列的故障排除过程不能提供判断它们的有效性或者评价最终代码质量的基础。 此外，这种方法高度依赖于过程的质量及过程执行的质量。 … Continue reading →

第6章  风 险 管 理 •    软件项目是一项复杂的任务。很多不可预见的事件会对项目的成本、进度或者质量产生负面影响。 •    风险管理（risk management）试图使由于意外事件而导致项目失败的概率降到最小。 •    风险管理的目标不是避开研究有风险的项目，而是使风险对正在从事的项目的影响最小。 •    拿Infosys公司的CEO奈良亚那•墨西（Narayana Murthy）的话来讲：“任何值得一做的事情都有风险，领导者面临的问题不是避开它们，而是通过解除风险的策略有效地管理它们。” •    不正确的风险管理是很多项目失败的根源，主要是由于过于乐观的通病造成的。 •    例：瓦苏（Vasu）被任命为一个著名的跨国公司所承担的一个大型项目的项目经理。该项目的任务是构建全球人力资源综合管理系统的多个部件。对于最终系统，瓦苏团队准备要开发的软件必须与另一个软件商开发的系统相集成。客户提供了专门供项目使用的工具，不久以后该工具就发行了新版本。瓦苏团队有35人，他们在1年略多的时间内交付了软件。尽管项目雇佣了一个良好的团队，并且项目经理作出了合理的估计，但是该系统晚了6个月才正式投入使用，Infosys 公司为此项目承受了50%的工作量蔓延。 •    为什么该项目会失败呢？有两个原因是很明显的。 –     首先，另一个软件商开发的软件没有按时完成，并且提供给瓦苏团队的接口不断改变。 –     第二，开发期间客户发行了一个新版工具，并要求软件使用这个新版工具。 •    这两个事件显然都是没有得到正确管理的风险实例。这些风险在开始时是显而易见的，然而，如同任何一个风险一样，它们是否会成为实际的危险却是不确定的。项目开始时，项目经理、业务经理和客户都希望那个软件商会按时交付软件，并且新版工具不会对项目产生影响。 •    事后，瓦苏认识到如果当时成立了一个指导小组（由两个项目的项目经理和一个客户代表组成），以正确地协调这两个项目及其软件交付时间，很可能会使延迟时间最短。 –     对于第2 个风险，他认为软件应先用旧版工具进行开发，然后通过另一个新项目将它移植到新版工具上。 –     解决第1 个风险的方案所需的额外工作量最小，并且客户的成本的微不足道。 –     解决第2 个风险的方案要客户付出额外的成本。也许为了避免客户感到不满意，所以没有强调该风险，也没有规划缓和该风险的措施。 •    … Continue reading →

第7章  计划的度量和跟踪 项目管理计划仅仅是一个可以用来指导项目执行的文档。除非根据计划对项目执行的实际绩效进行跟踪，否则计划所起的作用是有限的。 而对于项目跟踪，某些关键参数的值必须在项目执行期间得到度量。 跟踪不是一项轻松的任务，并且与其他任务一样，如果要正确地执行它，必须制定跟踪计划。 制定跟踪计划时，必须确定如何跟踪任务、工作量和故障等问题、使用什么工具、遵循什么报告结构以及多长时间报告一次，等等。 本章讨论Infosys公司的项目如何进行度量，同时还描述了项目跟踪规划和绩效变化阈值的选择，阈值用于触发管理行为。 7.1  度量概念 项目度量的基本目的是有效地控制项目。本节讨论与指标和度量有关的概念，以及控制一个项目时应当度量的基本指标。 过程控制的一种方法是统计过程控制（SPC）。本节还讨论了一些与SPC相关的概念以及SPC在软件中的使用方法。 7.1.1  指标与度量 软件指标可用于定量表示软件过程或者软件产品的各种特征。 过程指标使软件过程或者开发环境定量化，而产品指标是软件产品的度量。产品指标独立于生产产品所用的过程。 •     例如，生产率、质量、资源指标、故障引入率以及故障排除效率就是过程指标； •     而产品的规模、可靠性、质量（质量既可以看成产品指标，也可以看成过程指标）、代码复杂性和功能就是产品指标。 要使用指标必然要求制定度量方法以获取数据。 •    对于任何一个指标方案，必须明确地理解收集数据的目标以及基于这些数据的判断模型。 •    通常，使用哪些指标及采取哪些度量方法将取决于项目和组织目标；可以使用一个框架（诸如目标-问题-指标模式）来确定需要度量的指标。 大多数情况只要几个指标就足够了，只有在特殊情况下才需要特殊的指标。 进度、规模、工作量和故障都是项目的基本度量，它们形成了一个稳定的指标集。 进度是最重要的指标之一，因为大多数项目都是在进度和最后期限驱使下进行的。 进度是最容易度量的，因为它通常使用日历时间。 工作量是软件项目消耗的主要资源。因此，工作量跟踪是监督项目执行时的关键任务；它对于评价项目是否在预算内执行很重要。 •     即，工作量数据是声明诸如“ 项目的成本可能比以前的项目高出30% 左右” 或者“ 项目有可能在预算内完成” 所需的。 因为故障直接关系到项目质量，所以故障跟踪对于确保质量很重要。 一个大型软件项目可能包含上千个故障，它们由不同的人在不同阶段发现。通常修复故障的人并不是发现故障或者报告故障的人。 项目经理希望在最后发行软件之前排除大部分或全部故障。此时，故障报告和结论不能用非形式化的方法完成 •    … Continue reading →