第二部分有效开发

第10章面向客户的开发

很多例子都可以证明，并非所有开发人员提出的方案都适合客户。如果对比客户对开发速度和需求实现的认可，就会发现需求实现才是最重要的。如果客户不喜欢产品，他们就不会付款，而你的开发速度与此无关，次品终究是次品。所以即使你的上司，管理层，客户，市场人员，客户都盯在开发速度上，你应该理智的认知速度与需求的关系。

本章中穿插介绍了一些有助于维系良好客户关系的常规做法，其他一些特殊的方法，可以参见第三部分“最佳实践方法”。

1客户对于快速开发的重要性

项目成功的第一要素是客户参与。

造成进度延误，成本超出，达不到预期功能的前三个因素分别是：缺乏与用户的沟通，需求说明不完备，中途变更需求说明。你可以通过面向客户的开发方式来克服这几个问题。以下是项目中需要花费精力去维护客户关系的非常重要的理由：

l良好的客户关系能够提交实际开发效率。

l良好的客户关系能让客户感觉开发速度较快。

2面向客户的开发方法

面向客户的开发方法可以分为四个方面：计划，需求分析，设计，实现。

1．计划

使用以下方法可以增加客户对项目的满意度：

1)选择恰当的生命周期。

2)弄清楚项目最终是让谁满意。

3)建立有效的客户沟通渠道。

4)力争采取双赢的方案。

5)进行风险管理。

2．需求分析

需求分析中最具挑战性的问题是如何获取真正的需求。

3．设计

在需求分析阶段的工作可能完成得很好，也可能完成得不好。因此在设计阶段还应该进一步实现面向客户的目标。

在系统设计阶段，应该允许客户偶尔提出需求变更。在开发中甚至不允许出现对项目目标没有影响的变更，这种缺乏灵活性的做法是项目的一大弱点。

4．实现

3合理控制客户的期望值

软件开发中的诸多问题，尤其是关于进度的争执，大都来源于客户对项目抱有过高的期望值。

造成过高期望值的原因之一就是进度计划。许多项目在需求和资源都不清晰的前期，便由客户指定了进度计划。因此协助用户在制作进度计划时，树立现实的期望是项目成功的关键之一。

努力弄清客户的期望值，可以减少大量的矛盾和额外的工作量。因为客户并不愚蠢，只是对软件开发没有充分的认识，所以培训客户以使他们更好的理解软件开发过程，是PM以及开发人员应该承担的工作，这项工作使得控制客户的期望成为可能。

以任何理由(为使有争议的项目上马，为项目争取足够的资金，为获得项目的开发权)使客户对项目进度，费用或功能造成不切实际的期望，都将给项目带来不可克服的风险。这点在孕育之家二期表现非常明显，我为了获得项目的开发权，而给商务和客户对费用产生了较高的期望，而给项目带来了非常大的风险。

如果期望过高，即使项目运作良好，也会看起来处于困境之中，即使开发人员做的很好，也总像一个失败者。

期望过高也将损害团队的可信度，破坏同客户的关系。

因此轻易的许诺，在项目初期也可能会令各方满意，在长远来看是非常有害的。

第11章激励机制

开发人员，过程，产品，技术，在快速软件开发的四维中，开发人员是最优可能缩短项目开发周期的。而激励机制又是影响开发人员生产力最大的因素。

在许多项目中，管理层都是捡了芝麻丢了西瓜，以士气大减的代价去换取微不足道的方法改进或预算节省，这样实际上大大减低了开发人员的积极性。

本章将阐述一些激励开发人员以提高生产速度的方法。

人的内在动力来自三个方面：感受到工作的意义，对工作成果的责任，以及了解工作的实际结果。

工作中有5个方面对提高工作动力有所贡献：

l技术的多样性。使工作不至于枯燥。

l任务的完整性。进行一项完整的工作，能让人对其更加关注。

l任务的重要性。

l自主性。能按照自己的工作习惯处理工作的自由度。

l工作反馈。

1．开发人员的典型动机

不同的人会因为不用的因素而得到激励；同一个因素会应该开发人员，管理人员，普通人的身份不同而影响不同。以下是对于三种身份的动机顺序表：

开发人员更容易受到发展机遇，个人生活，成为技术主管的机会以及同事间人机关系的影响。而不容易受地位，受尊敬，责任感，与下属关系及受任何程度的影响。

与管理人员相比，开发人员较少关系责任感或受认可程度。如果要激励开发人员，则应该强调挑战性，自主性，学习并使用新技能的机会，职业发展以及对他们私生活的尊重等。

2．最重要的五个激励因素

踹一脚并不能产生动力，只能产生被动行为。所以在设置激励机制时，不仅要让开发人员表面上动起来，更要调动内在的动力。

激励开发人员的最重要的五个激励因素是：成就感，发展机遇，工作自主性，个人生活和成为技术主管的机会。

1．成就感

1)自主权

自主是激励的一种方法。当人们为实现自己设置的目标而工作时，会比为别人工作更加努力。如果让开发人员自己决定工作进度，你不必过分担心他们是否在努力工作，而是应该关注一些诸如过于乐观的进度，自愿加班太多等问题。而那些都不是激励的问题。

2)设定目标

设定切实可行的目标是激励的另一种方法。在设定目标时，需要注意一些问题：第一个问题是目标一定要可行，不要定的不切实际或者太远。第二个问题是目标不要同时设置太多。

2．发展机遇

最聪明优秀的人才必定会流向鼓励个人发展的企业。

3．工作乐趣

工作的乐趣是造成质量比进度更可能有效地激励程序员的原因之一。

4．个人生活

个人生活因素对开发人员的影响是管理人员难以理解的。与之对应的就是责任感，责任感对管理人员的影响也是开发人员难以理解的。

对一个公司来说，想要用个人生活作为激励，就必须做出实际计划使开发人员有时间享受个人生活，比如安排假期，同意开发人员在工作日偶尔外出。

5．成为技术主管的机会

3．利用其它激励因素

1．奖赏和奖励

2．对业绩的评价

正确进行业绩评价，具有很大的激励作用。对业绩的评价是管理者能提供的，最贴切最重要的工作反馈。不论是正面还是负面的评价，都能长时间的影响下属的表现，因此业绩评价应该经过高度权衡才做出的。

4．士气杀手

1．保健因素

当保健因素不具备时，将产生不满情绪。然而保健因素达到一定程度后，并不能提高积极性。这些保健因素包括：合适的光线，适合的空调，足够大的桌子，安静的环境，好用的计算机，高效的通讯设备，自由的上下班时间等。

2．管理操控

有些管理者试图以虚假的最后期限的方式来实施项目控制，而大部分开发人员对此非常敏感。

3．执行计划的压力

一个根本不可能的最后期限，带给开发人员的是积极性降到最低谷。极少人会明明知道不可能还会拼命地要实现目标。

4．缺乏对开发付出努力的表扬

通常的理解是这样：人们既然不能亲眼见到开发人员正在如何工作，也就不会认为他们做了很多工作，从而觉得计划出现阻碍是开发的责任。然而真实情况是开发人员正在努力的自我激励，勤奋工作，加班加点。当开发人员被误解为磨洋工时，他们就会觉得沮丧，而降低工作效率。

所以当你的项目出现一些问题后，应该适当表扬开发付出的努力。

5．干涉技术决策

如果管理人员干涉自己并不在行的技术决策，一定会在项目组内成为笑料。而绝大部分人不会受到一个自己不尊重的人的激励。对非技术型管理人员来说，干涉技术决策是一个非常严重的错误。

6．开发人员没有参与同自己有关的决策

开发人员没有参与同自己有关的决策，似乎说明管理层对开发小组不够重视和关心。如果要保持开发人员的士气高涨，必须让开发人员参与决策。下面是一些典型的场景：

新的计划讨论会。产品设计。过程优化讨论会。来了新的开发人员。

7．生产率障碍

如果环境阻碍了开发人员的生产率，管理人员应该设法消除障碍，是开发小组可以集中精力在开发工作上，而不是应对环境。

8．低质量

项目管理者如果坚持为了苛刻的计划而降低质量要求，那么开发人员会感到沮丧。低质量的产品剥夺了开发人员的成就感。

9．过分夸张的激励形式

海报，标语，信口开河以及其他一些打哈哈一样的激励行为，不仅不会激励开发者，还会使他们感觉自己受到了侮辱。

第10章团队合作

当多个人合作，整体成果比个体成果的和加起来要大时，才有组建团队的必要。反之，如果大家有冲突，整体会比所有部分相加的总和要小，就没有团队的必要了。

所以，并不是所有项目都需要建立团队。有些项目只需要由多人小组就可以做得很好了，不需要建立团队。一些项目并不需要达到团队合作所需要承担的水平。

1.创造高绩效团队

1.共同的，可提升的愿景或目标

在项目开始运作之前，项目团队需要“buy in”一个共同的愿景或目标。任何一个高效的团队对于自己的目标都有清楚的认知。

项目愿景可以使一些小问题的决策得以简化。

挑战性的工作。高效团队从来不为了一个无聊的目标组建。你呈现项目的方式，将决定团队将它视为挑战，还是视为困难。

例子：“我们想建立一个市场排名第3往后的，质量低于市场平均质量水准的数据库产品”。没有人会为了这个目标而高效工作。或者你可以这样呈现项目：“我们将建立一个数据库产品，使我们的市场份额从0提升到10%，市场和生产需要一个绝对可靠的进度计划。所以我们以内部里程碑和最终时限作为目标，一定要有100%的把握实现它。”这样的方式，团队有可能会为这100%的精确目标而奋斗。

2.团队的成员认同感

团队的认同感，使得成员把团队目标看得比个人目标重要，他们从团队的成功中获得满足感。而认同感的来源，就是成员在团队中有机会实现他们个人无法实现的东西。

3.结果驱动的结构

结果驱动结构的基本特征：

l角色必须明确。每个人在任何时刻都应该对各自的工作负责。责任对有效决策的制定，和对已制定的决策的快速实施十分关键。

l团队必须存在有效沟通系统，以支持信息在成员之间自由流动。

l团队必须以某种方式监控个人表现并提供反馈。团队应该知道谁应该受到奖励，谁需要个人的进一步发展，谁能够承担更多责任。

l任何时候的决策制定都要以事实为基础。而不是以个人主观意见为依据。

4.胜任的团队成员

对于快速开发，要以项目目前最需要的技能为标准，其中三种能力最为重要：项目需要的特殊技能；强烈投身于工作的愿望；善于与团队成员有效合作。

5.团队的承诺

愿景，挑战和团队认同感，结合在一起会使成员可以向团队做出承诺。

6.相互信任

信任包括四个部分的内容：诚实，开放，一致，尊敬。

7.团队成员间的相互依赖

8.有效的沟通

团队应该提供一个环境，让团队成员表达他们真实感受，当他们感觉不好时，需要及时提出来，哪怕团队不得不宣布坏消息。在相互依赖的环境里，一旦成员意识到问题，就可以立马提出来，也许还有时间补救。而与之相反就是掩盖错误，直到错误越来越严重而无法掩盖。这对于快速开发来说，是致命的。

9.自主意识

自主意识与成员从项目经理那里感觉到的信任感有关系。经理信任团队是非常重要的。这意味着经理不要进行事后的批评或施加强硬的决策。当团队很明显都正确的时候，任何经理都会支持团队，这不叫信任。只有当团队看上去好像错误的时候支持他们，这才叫信任。

10.授权意识

高效团队需要意识到被授权可以采取任何为获得项目成功所需要采取的行动。哪怕是抵制组织的不合理要求。

11.小的团队规模

一些专家认为一个团队的成员最好少于8到10个人。

12.高层次的乐趣

以下是成功管理高凝聚力团队的几个关键：

l建立一个愿景。

l创造变化。

l管理团队。使团队为团队的行为负责，而不是团队成员为他们各自的行为负责。

l以具有挑战性的，清楚的和支持的方式委派任务。

l将如何完成任务的细节留给团队。

l当团队运行不好的时候，想想MOI模式：多数的团队问题来源于：动机，组织或信息。尝试清除有关这三个方面的障碍。

2.团队为什么会失败

1.缺乏共同的愿景

2.没有认同感

3.相互缺乏认可感

4.生产力阻碍

5.低效率的沟通

6.缺乏信任

7.有问题的员工

3.长期的团队建设

如果能长期保留一个团队，将对快速开发提供非常坚实的基础。PMP里，团队的生命周期按次序是形成，震荡，规范，成熟，解散。长期保留团队，将大大缩短每个项目的形成，震荡和规范期。下面是长期保持团队的一些原因：

1.更高的生产效率

2.更低的启动费用

3.较低的个人问题风险

4.减少人事变动

5.时间空闲问题

组织有时不愿意保留团队，因为假如团队空闲，他们还不得不继续付钱。直到有一个项目适合他们来做。这听起来似乎有道理，但实际上在多数情况下并不划算。

组织仅仅看到团队空闲时间的成本，而忽略了每一个项目新建团队的花费。新建团队并非是把人集合在一起就完事了。

组织总是忽视了拆散一个高业绩团队带来的损失。他们宁愿冒一个风险，就是把高业绩团队可能变成一个普通团队或比较差的团队。

4.团队合作指导方针总结

第11章团队结构

即使你拥有了技术，有动力并且努力的员工，错误的团队结构也会削弱他们的努力。

本章描述了组建快速开发团队时需要考虑的因素。包括团队结构中最棘手的问题之一：项目经理与技术领导之间的关系。

1.团队结构应该考虑的因素

1.团队的种类

l问题解决团队

问题解决团队的重点在于解决一个复杂，没有被明确定义的问题。例如一组为疾病控制中心工作的流行病专家。对问题解决团队成员的要求是可信赖的，聪明的和活跃的。团队结构应该支持这个问题的重点。

l创新团队

创新团队的宗旨是探索可能性和选择性。例如一组麦当劳食品科学家尝试发明一款新的麦当劳食品。创新团队成员需要自我激励，独立，富于创新和百折不挠。团队结构需要支持团队成员的个人和集体自治。

l战术执行团队

战术执行团队的重点在于执行一个定义良好的计划。例如一个棒球队参与一个由教练制定好的战术比赛打法。这种团队是以高度集中的任务和清楚定义的角色为特点。战术执行团队成员需要对他们的团队使命有紧迫感，对行动比推理更有兴趣，并且忠诚于团队。

2.附加的团队设计特征

除了以上三种基本团队种类，还有四个团队特征，几乎可以代表所有有效运行的团队：

l明确的角色和责任

l监控个人表现和提供反馈

责任感的另一方面是团队成员能通过某种方式知道他们无愧于团队的期望。团队应该有一种机制让成员知道他们的表现是可以接受还是有待进一步提高。

l有效的沟通

信息必须易于获得。

信息必须有可信来源。

成员必须有权利在任何时候，正式或非正式提出问题。

l以事实为依据制定决策

3.何种团队类型最适用于快速开发

组织快速开发团队的关键，是理解没有一种团队结构可以适用于每一个项目。

2.团队模式

本节中描述的各种模式，并非是一个个不相关的集合。在这些模式中，你会发现很多重复或矛盾。你需要结合许多不同的模式中的一些成分，来分析你的项目。这一节中，我们希望使你对用不同方式来构建你的团队产生更多想法，而不是对所有团队结构做系统化的陈述。

1.业务团队

最常见的团队结构。由一个技术领导带领团队，其他成员都有相同的身份。

技术领导通常是在技术专家中选择，而不是在职业管理者中选择。

从外面看来，业务团队的结构是典型的等级层次结构，它通过确定一个人主要负责项目中的技术工作来改善与管理部门的沟通；允许员工在自己的领域内工作，允许团队自己划分谁工作于哪一部分。

业务团队可能适用于所有项目：问题解决型，创新型，和战术执行型。

但是它的普遍性也是它的弱点。

2.首席程序员团队

首席程序员团队，又称外科团队。

首席程序员团队利用了某些程序员的开发效率是其他人10倍这一现象。一般的团队结构，将普通程序员和超级程序员放在相同的位置上，你受益于超级程序员高效的同时，也被其他低效程序员拖累。

在首席程序员团队中，一个超级程序员被认为是外科手术的主刀医生，由他起草整个说明书，完成所有设计，编写大部分代码，最终负责几乎所有产品的项目决策。

后备程序员是首席程序员的战友。他作为助手，批评家，技术联络人，后备力量等支持首席程序员的工作。

管理员处理管理事务，诸如财务，人员，场地，机器设备等。管理员的存在是为了将首席程序员从大量日常管理工作中解脱出来。

工具员负责制作首席程序员要求定制的工具，运行每日构建的内容。

首席程序员团队适合创新项目，战术执行项目。

3.臭鼬项目团队

臭鼬项目团队是工程领域不可欠缺的一部分。臭鼬项目团队有一批有才华的，有创造性的产品开发者，将他们放在一个不受官僚限制的组织中，使他们能放手开发和创新。臭鼬团队是典型的黑箱管理方式。

臭鼬团队有利于创建一种紧密的所有权关系，以及调动有关开发人员的特别投入，因为它的激励效果是惊人的。不利方面在于没有为团队进展提供足够的可视度。

臭鼬团队对于创造性最为重要的探索性项目非常适合。当你要解决精确定义的问题，或需要执行一个精确理解的计划时，臭鼬团队是难得的最快速的结构。

4.特征团队

特征团队从每一个部门中抽取一个或多个成员，每个部门的成员还是向自己部门的经理汇报。(类似PMP里的职能型组织)。

特征团队有授权，责任和平衡的优势。团队成员能够被明确的授权自己负责的领域，因为它包括来自开发，产品，文档，质量管理等各个部门的代表。

5.搜索救援团队

搜索救援团队的重点在于解决特定的问题。

搜索救援团队特别适合问题解决团队。但它太基础，不能支持创造性，太短期，不能支持战术执行。

6.SWAT团队

SWAT团队中，每一个成员都被严格训练成某一方面的专家，他们共同合作，天衣无缝。

SWAT团队通常是最持久的团队。他们也许不是用全部的时间来做项目，但是他们习惯在一起工作，并有明确定义的角色。

SWAT团队非常适合战术执行团队。他们的工作不是去创新而是用他们熟知的技术和实践来执行一个方案。SWAT团队在解决问题团队中也很出色，团队成员相互信任。

7.专业运动员团队

管理者对于软件开发者的挑选，就像教练对运动员的挑选一样认真，可能这对项目的成功更为关键。

管理者的角色是清理障碍，使开发者能更有效地工作。

8.戏剧团队

戏剧团队是以强烈的方向性和很多关于项目角色的协商为特点的。

导演，是项目的中心角色，他保持产品的愿景目标和指定人们在各自范围内的责任。

制片人，是软件管理者，他为项目获得资金，协调进度，确保每个人在适当的时机到达适当的地点。在项目的艺术方面，制片人通常不会起到作用。

戏剧团队的优势是在创新项目团队中。

9.大型团队

大型团队在沟通上存在特殊的问题。类似PMP里沟通路径条数的计算(n*n-1)/2。

形式化的沟通是大型项目成功的重要因素。所以简化沟通会对团队结构有很大影响。

简化沟通的方式主要是创造某种层次。就是说划分成小组，小组的功能像团队一样，然后小组中指定代表来相互沟通。你可以以多种方式划分小组：

l建立一系列的业务团队。

l建立一系列的首席程序员团队。

l建立特征团队。

不管小的团队如何组织，我认为有一个人最终负责产品概念上的完整性是非常关键的。这个人的工作是确保把所有团队的所有成功解决方案拓展成为成功的全局解决方案。

3.管理者与技术领导

在很多团队项目中，都存在技术领导角色，他是以技术专家的身份为委派这个角色，他并非管理专家。涉及开发和管理两个方面的只能对于这个人来说，通常是个棘手的问题。

技术领导角色最大的障碍之一，就是在技术与管理之间缺乏明确的职责划分，通常是职能混乱。

从团队的角度来看，管理者的角色是减轻技术领导处理非技术事物的职责。从组织的角度看，管理者的角色是控制团队以和组织的目标保持一致。

第10章功能限定

软件开发人员和管理者都声称了解功能限定的必要性，但是真实情况却不是这样，开发人员，管理者，市场人员和最终用户始终在为已经很庞大的产品填充着更多特性，以至于有人以此为理由为低劣的软件产品进行维护。

最严重的功能限定问题，就是需求蔓延。需求蔓延是指在产品开发的晚期增加需求。

功能限定问题，将带来成本超支，进度延迟等问题。

在普通功能限定方法中包括三点：

l项目早期控制。制定一个与进度和预算目标一致的功能集。

l项目中期控制。控制需求和蔓延。

l项目晚期控制。剪切部件以适应进度和成本目标。

1.项目早期：功能的简化

项目早期阶段的功能限定主要是不要把不必要的功能引入到产品原型中。有三种方法缩小范围：

规格说明最小化。

需求提炼。

版本开发。

1.规格说明最小化

需求规格需要详细到什么程度？传统的做法是越详细越好。一个能够把握更多需求的，详尽的规格说明书，会避免在项目晚期由于追加需求而引起的时间和费用问题。

传统规格说明书存在的问题

l浪费。你可以花费时间描述十分详细的系统特征。比如本来该由开发人员作出判断的地方：对话框的大小，位置，光标移动次序等。

l退化。项目中期的变更会很快导致需求说明书的过时。维护需求说明书的任务变成了一个道德上的，官僚政治任务，而不是一个有益于项目进程的工作。

l缺乏功效。以十分详细的方式陈述系统需求，并不能保证系统的成功。系统可以满足规格说明书，但仍然不能令人满意。

l过度限制设计。过分的限定软件，可能会使设计者是实施者浪费大量时间。

一份传统的，详尽的规格说明书，能够让人感觉软件开发的目标是开发一个与计划一致的软件。但真正的目标应该是在可利用的时间内开发一个最合理的软件。

写一份最小的规格说明书

以下是一些最小规格说明书的方案：

l一份简短的纸面规格说明。要构建的软件产品的文本描述。最好不要超过十页纸。

l起程点规格说明。这是一次性的规格说明，写完后不再变更。主要目的是使开发组，客户，最终用户对产品具有共同的视角。一旦目的达到了，这份规格说明就起到作用了，也就不用再维护了。

l用户手册式规格说明。用户手册是迟早要写的，而且软件需要跟用户手册保持一致。所以使用用户手册来代替规格说明也是一种方案。

l用户界面原型。一图胜千言，可以节省大量时间。

l情节串联板(storyboard)。

l可视化陈述。

l产品主题。产品主题是相对于视觉而言的，是控制功能的一个好的机制。

使用最小规格说明，需要考虑需求的灵活性。像生产一台波音飞机这样的项目，由于需求非常严格，就不适合使用最小规格说明方法。

最小规格说明的好处

有效使用最小规格说明，可以产生几个关于时间的好处：

l改进士气和动机。最小规格说明方法，使开发者更多的需要自己去规划产品，而当开发者自己规划产品时，更容易保证产品的成功。这点还是要看情况，主要是考虑团队人员的水平。

l机会效率。

l减少人力浪费。

l缩短需求分析阶段。

最小规格说明的风险

l忽略关键需求。

l不清楚或不可能的目标。

l镀金。

l缺乏并行工作支持。

l增加开发人员对特殊功能的依恋。

l因为错误的原因而使用最小规格说明。

最小规格说明成功的关键因素

l仅当需求具有柔性时，使用最小规格说明。

l保持规格说明最小化。最小规格说明默认的是，开发者将对它们进行更进一步的说明，当你开始表示怀疑时，赶紧放弃。

l获取重要的需求。

l采用柔性的开发方法。

l关键用户参与。

l关注图形化文件。

2.需求筛选

早期从产品中删除一个功能是缩短软件进度最有效的方法。因为每删除一个功能，与之相关的需求，设计，开发，测试，文档等一系列工作都能删除。需求筛选比最小规格的风险要小。

l排除完全不必要的需求。

l简化比实际需求复杂的需求。

l使用更容易的操作，代替原来的操作。

使用需求筛选，一定要注意一个现象：早期你将100条需求，筛选到70条，那么你只需要70%的工作量即可完成工作。但是后期，70条需求又变成了100条，那么这个项目将要付出比原来更多的工作量。

3.版本开发

另一种删除需求的方案，是从当前版本中删除。

2.项目中期：功能蔓延的控制

当你制定了一个规格说明书后，你可能认为该产品功能已经在你控制之下，其实不然。在开发过程中，还有将近25%的需求变更。

1.变化的根源

最终用户，会因为需要额外功能，或需要不同于设计的功能，或在系统建设过程中获得对系统的进一步了解，而希望变更需求。

市场人员，会因为他们以功能驱动去观察市场，而要求需求变更。

开发人员，会因为他们对系统存在着感情和智力上的投资，而要求需求变更。例如他们正在开发第二版，他们就会希望对第一版中存在的不足，提出变更。

各种人员会因各自的原因希望变更。以下是一些造成需求变化的原因：

l迷人程序综合症。公司A准备研发一款商业封装软件，就在完成研发的前几周，B公司的产品进入市场了，并且包含A公司的产品没有考虑到的功能或特性，这时A公司决定延长进度，参考B公司的产品功能。就在快要完成的时候，C公司的产品也进入市场了。结果A公司下一轮的需求变更开始了。

l不清楚或不可能的目标。如果目标不清楚，那么不同开发者对同一目标将会有差距非常大的实现方式。

2.变更的影响

3.完全停止变更的行为

当你借口不允许或不希望变更，而不允许必要的变更时，也是需求失控的一种形式。

4.变更的控制方法

任何变更管理计划都要瞄准以下几个目标：

l在适当的时间里，允许有助于产品生产的变更。不允许其他变更。

l允许受到变更影响的当事人，对变更的进度计划，资源和产品的效果进行评价。

l向每一个计划变更的干系人通报对它的影响的评价，以及是否接受变更。

l提供与项目内容有关的审查结果。

面向用户的需求实践

面向用户的需求采集是获得真正需求的较好的工作方法。

变更分析

对变更说不的最好方法是，提供有关变更对费用，进度的影响。

版本２

在未来的版本中考虑变更，也是可行的方案。但一定需要记录成资料。

短的发布周期

之所以版本２的方式能够得到客户的认同，关键因素是因为他们得到了他们希望的内容将在产品中出现的承诺，尽管不是在当前实现。所以短的发布周期，将建立客户信心，让他们相信他们关心的内容最终将会加入到产品中。

变更控制委员会（CCB）

变更控制委员会已经被证明能够有效地组织大项目中的需求蔓延，并且对小项目也有效。

1)结构。典型的CCB由在产品中具有利害关系的每一小组的代表组成。如开发，质保，测试，客户，市场和管理等等。

2)变更分析。CCB的功能是对每一变更进行分析。典型的分析就是从多重约束的各个端开始：产品范围，进度，成本，质量。

3)鉴别分类。CCB有权对每一变更进行接收和拒绝。

4)打包。CCB也能够集合小的变更，一边开发者能够打包处理它们。因为一连串变更，如果不经整理就传到开发，将付出比较大的代价。

5)官僚机构问题。CCB在人们印象里被描绘成为了过度官僚的机构。是因为CCB在对变更说不时，更多地是在说明他们的许可权，而不是在强调他们的分析结果，已经他们能够给出的方案。

3.项目后期：功能裁剪

即便你在前期和中期的功能限制都做得比较好，由于一些原因，项目还是落在了计划的后面。

当你到了这种地步，利用功能裁剪，去除一些低优先级的功能是最有效的方法。

这个方法的缺陷在于：当你到了项目后期，其实你已经花费了被剪切功能的设计，文档和部分实现工作。甚至还要剥离一部分已经完成的代码。

为了避免这些缺点，你可以提前做好计划，选择支持晚期功能裁剪的生命期模型。