第二部分快速开发

第六章快速开发中的核心问题

一个标准是否可以适应所有情况

你需要怎样的开发方法

*进度计划有严格限制的产品

对于确实需要全力以赴提高开发速度，而不注重成本，可预测性的产品来说，它与典型产品有着不同的时间价值曲线：

*表面上的快速开发

某些项目中，客户，用户，上级或者产品提出“快速开发”的需求，有时还希望低费用，低风险。他们其实也不知道这样的要求是否过分，或者是否真的过分。

在你得到消息要在限定的时间内“快速开发”时，应该充分挖掘你所面对的真实需求。各种表面上号称需要“快速开发”的项目，实际上是还有其他需求。

1防止失控状态

如果一个软件组织有失控，拖延工期，或者超出预算的历史，如果一个客户有被其签约商拖延工期，超出预算的历史，都会造成客户要求“快速开发”。但是在这种情况下，客户真正的需求是能在规定的进度和预算下完成。

在这种情况下，你真正需要的是较好的风险管理，预算管理和进度控制来保证项目顺利进行。

2可预测性

在很多情况下，客户需要将软件产品与市场，发布会，公司计划等其他项目协调在一起。这时你需要较好的风险管理。

3最低费用

对于软件开发项目，客户希望费用最低的情况并不罕见。在这种情况下，他们口里说着快速开发，其实是需要降低费用。

但是在实际上，最短的开发周期跟最低的费用并不是同义词。

4渴望加班

在一些情况下，客户或者上级利用他们对进度的关心，来掩饰他们希望开发者提供免费加班。

这种情况是很容易区分的，在这种情况下，客户强烈关心进度，但是无法提供与之对应的费用或资源。如果客户对项目进度的关心让你感到压力，那么它的重要性足以让客户增加对项目的支持。

*你真正需要的是全力以赴的开发

现实中的项目，客户希望你在低费用，短时间里，提供质量最好的产品。往往你只能三选二。在短时间里，提供低质量的产品往往是最错误的做法。因为如果你准时发布了低质量的产品，客户不认为你准时发布了产品，而是你发布了低质量的产品。对应到我们项目组，也就是一直存在的细节问题。认为项目很急，所以在细节问题的处理上太粗心。

按时完成的可能性

我们感觉开发速度缓慢，一部分原因是有些工作确实缓慢，另一部分原因是没有达到预期的速度，所以显得缓慢。对于第二种情况，我们的对策是维护两套进度，一套用来真实的控制项目，另外一套给上海和客户，用来降低客户预期。

软件项目包含太多可变因素，通常不能100%精确地设定开发进度。

上面的图表达了几个假定：

l完成一个项目，都有一个最快完成速度的极限值。

l完成一个项目，没有一个最慢完成速度的极限值。

l完成几率曲线的前一段和后一段形状不同。

很多项目最初瞄准了不可能开发的区域，最终落在了缓慢开发的区域。

建议安排好项目进度，使按时完成的可能性达到50%是比较合理的做法。

感知与现实

即使按时完成任务，要知道开发速度慢的感觉与事实上的速度慢一样能影响你的项目成果。即使我们一直不停的在做，也没有理由期望客户缄默的等待几个月，直到项目结束。应该意识到让客户定期知道项目的进度情况是我们工作的一部分。

不切实际的用户期望

如果项目进度制定在一个不可能的区域内，但在有效区域完成，人们还是认为这是一个失败的项目。尽管它是在给定资源条件下，以有效的进度完成。

有时候，客服开发速度慢的感觉，需要确保合理的用户期望，并提供稳定的项目进展报告。

克服慢速开发的感觉

两种方法克服慢速开发的问题：

l将事实上的慢速开发重新定位。

将实际进度缩短，将进度移动到有效开发区域。

l将感觉上的慢速开发重新定位。

拜托痴心妄想，延长计划进度时间，缩小计划于实际的差距。

时间都去哪里了

*典型的观点

许多项目开始于需求定义之前，如果这一阶段没有经过良好的定义和管理，可能会延续很长一段时间。

*软性问题

1返工

对具有缺陷的需求，设计，代码进行返工，普遍需要花费整体开发费用的40%。在早期对缺陷进行修正是最廉价的。因而避免返工是一个缩短项目执行时间的有利机会。

2功能蔓延

典型的项目经验告诉我们，25%的需求会发生变化，有些时候更多。对本质的需求变化不加以限制是开发效率的首要错误。所以避免功能蔓延，需求镀金对项目进度是很有好处的。

3需求定义

一般情况下，需求定义要花费项目全部时间的10%到30%。而且由于需求收集是一种无所限制的工作，也就可能会花费大量不必要的时间。在需求定义阶段适当的督促，对项目进度很有帮助。在需求定义期间，包括联合应用开发，渐进原型，阶段交付和不同的风险管理方法，将在其他章节中介绍。

4模糊的项目前期

开发速度的权衡

最初的资源股价和进度往往不能被接受，这不是因为项目经理或程序设计者的工作有差错，而是由于用户通常希望得到的比他们提供的资源要多。如果工作不能与可行的进度和资源想适应，那么他们要么就得到的更少，要么就是导致时间和资源增加。

*进度，费用和产品的平衡

*质量的权衡

对软件产品的质量要求分为两种：

第一种是要求软件有较低的缺陷率。由于低缺陷率与短的开发周期分身就是匹配的，在这种情况下没有更好的办法为了进度来权衡质量。

第二种是要求产品包括高质量产品应有的特性，可用性，健壮性，有效性等。对之中质量要求的关注会延长开发时间，因此也就使我们需要相对于进度去平衡这种质量要求。

*个人效率的权衡

在尝试达到个人最大生产力和最求进度最快之间存在冲突。达到每个人最大生产力的最简单办法就是保持小规模团队，而最求进度最快最简单的方法就是扩大团队人数。因此意味着快速开发并不总是生产力最高的。

典型的进度改进模式

如上图，典型开发过程中，计划虽然好看，但是很少有机会完成。从典型开发到有效开发要完成的最大部分工作是从痴心妄想转变到有意义的项目计划。如下图：

如上图，有效开发的项目中，进度的分布范围是较狭窄的。有两个原因：一是人们学会了怎样实际地设置目标，二是人们学会了如何较快的开发软件。

向快速开发前进

后续章节中将描述实现快速开发的方法：

l生命期计划

l估算

l进度计划

l面向客户开发

l激励

l团队合作

l团队结构

l生产力工具

l项目矫正

以上的部分内容我们在前面曾经讲过，之所以我们在下面还要讨论，是因为以上内容是获得最快开发速度的关键方法。

第七章生命期计划

任何软件开发都要经历一个“生命期”，包括从1.0版本在某个人脑中闪现到6.74b版本在最后一个用户的机器上最后一次使用之间的所有活动。

生命期模型的主要功能是为开发活动确定一种次序，一种标准。

人们最熟悉的模型是瀑布生命期模型，但是它的弱点也同样著名。作为一个项目骨架，你选择的生命期模型对项目的成功和任何其他计划一样重要，并帮助你一步一步接近目标。如果你选择了合适的生命期模型，就可以提高开发速度，提高质量，加强项目跟踪控制，减少成本，降低风险或改善用户关系。选择了错误的生命期模型，也必定会导致工作拖沓，劳动重复，无谓的浪费和挫折。

纯瀑布模型

1说明

尽管存在许多问题，纯瀑布模型是其他模型的基础，是一个比较有效的生命期模型。

在瀑布模型中，项目始终按照一定顺序的步骤从初始概念进展到系统测试。项目确保在每个阶段结束时进行检查，判定是否可以开始下一个阶段的工作。

文档驱动。意味着主要工作成果是通过文档传递。在瀑布模型中，各阶段不连续也不交叠。

降低计划管理费用。因为你可以预先完成所有计划，文档产生并提供了贯穿生命期过程的充分说明。

2适合情境

当你有一个稳定的产品定义和很容易被理解的技术解决方案时，瀑布模型特别合适。在这种情况下，瀑布模型可以帮助你及早发现问题，提供稳定的需求。

对于那些容易理解但很复杂的项目，采用瀑布模型很合适。

3缺点

缺乏灵活性。必须在项目开始阶段就说明全部需求。

编码修正模型

1说明

编码修正模型是一种不太有用的模型，但是比较常见。如果你没有明确的选择其他生命期模型，也许你就不自觉的在用编码修正模型。编码修改也被称为鲁莽编码。

当你使用编码修正模型的时候，你是从一个大致想法开始，可能有一个正式规范，可能没有，然后你结合设计，编码，调式和测试方法，完成开发。如下图：

2适合情境/优点

编码修正模型有两个优点：第一，不需要什么成本。你不需要在编码工作之外付出成本，比如项目规划，文档编制，质量保证等。第二，只需要极少的专业知识。任何有编码技能的人都能使用它。

对于一些非常小的，用完就丢的软件，原型，验证程序等，这种模型还是很合适的。

3缺点

对于其他项目来说，这种模型是非常危险的。因为它不提供项目进展，质量评估，风险识别等。

螺旋模型！

1说明

螺旋模型是一种以风险为导向的生命期模型。它把项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有主要风险都被确认。“风险”的概念在这里有所外延，它可以是需求或者是框架没有被理解清楚，潜在的性能问题，根本的技术问题，等等。

它的基本思路是，从一个小范围的关键中心开始寻找风险，制定风险计划，并交付给下一步骤。如此迭代，每次迭代都把项目扩展到更大的规模。每次迭代都包括一下六个步骤：

（1）确定目标，方案和约束条件。

（2）识别并解决风向。

（3）评价备选方案。

（4）开发本次迭代可供交付的内容，并检查它们的正确性。

（5）规划下一个迭代过程。

（6）交付给下一步骤，开始新的迭代过程。

2适合情境/优点

可以采用不同的方法把螺旋模型和其他生命期模型结合在一起使用。比如使用螺旋模型将项目分解，将风险降低到可以接受的水平后，再采用瀑布模型或其他模型来执行项目。

通常都是在螺旋模型中，把其他生命期模型引入作为迭代过程。

螺旋模型最重要的优势就是，随着成本的增加，风险程度随之降低。时间和资金花得越多，风险越小。

螺旋模型至少提供和瀑布模型一样多的管理控制。在每个迭代结束前都设置了检查点。

螺旋模型能使你对任何无法逾越的风险都提前预知。

3缺点

螺旋模型唯一的缺陷就是比较复杂。需要责任心，专注和管理方面的知识。通过目标和里程碑，来决定项目是否已经准备好进行下一轮迭代。

如果项目的目标明确，风险适度，你就没有必要采用螺旋模型。

生鱼片模型

1说明

纯瀑布模型最大的弱点不是这些活动本身，而是模型把活动看作是不连续的，有顺序的阶段来处理。因此，可以针对这个弱点，来调正模型，进化成各种修改后的瀑布模型，生鱼片模型就是其中一个。

传统瀑布模型允许在阶段之间，存在最低限度的重叠。而生鱼片模型建议的是一种大幅度的重叠。

2适合情境/优点

对比纯瀑布模型，生鱼片可以充分减少文档需求。

如果你在一个小的，定义得很好的项目，那么这种模型可以用到最有效的模型。

3缺点

因为阶段是重叠的，所以将会导致里程碑非常不明确，很难精确进行过程跟踪。

具有子项目的瀑布模型

1.说明

纯瀑布模型的另一个问题是，必须在上阶段全部完成后，才进入下一个阶段。但在实际工作中，系统某些部分可能比较简单，有些地方比较复杂，而由于复杂的问题，导致简单的部分也无法开始。因此，我们可以把系统分成几个相对独立的子项目，每个子项目都按自己的节奏进行，这就形成了一个具有子项目的瀑布模型。

2.适合情境/优点

这种模型比较适合于系统包含多个相对独立的项目。

3.缺点

具有子项目的瀑布模型，主要的风险在于子项目之间的相关性无法预料。为了解决这个风险，你可以等到架构设计完成，排查相关性之后，再拆分子项目。

降低风险的瀑布模型

1.说明

纯瀑布模型的另一个问题是，必须在开始架构设计之前，就完整的定义需求。这在实际工作中非常困难。所以我们可以在瀑布模型中引入螺旋模型，以便确定和降低风险。

2.适合情境/优点

降低风险的瀑布模型比较适合开发一个高风险内核的项目。不止在需求阶段，在项目任何阶段都能引入螺旋模型以降低风险。

3.缺点

降低风险的瀑布模型跟螺旋模型一样，就是比较复杂。

渐进原型！

1.说明

渐进原型通常是从最显著的方面开始，向客户展示完成的部分，然后根据反馈信息继续开发项目，一直重复这一过程，直到用户认为原型已经足够好，然后结束工作，交付作为最终产品的原型。

2.适合情境/优点

在需求变化很快的时候，用户很难提出明确需求的时候，开发人员对于最佳架构没有把握的时候，渐进原型都特别有用。

3.缺点

渐进原型主要的缺点是，你不可能在开始的时候知道产品总时间需要多久。

另一个缺点就是，渐进原型很容易退化成编码修正模型。所以要注意，真正的渐进原型，包含真正的需求分析，设计和可维护的代码。渐进原型每次重复时的实际进展是比较小的。

阶段交付！

1.说明

阶段交付可以持续地在确定的阶段向用户展示软件。和渐进原型不同，在前期你就明确的知道整体分为多少阶段，每个阶段完成哪些内容。

2.适合情境/优点

阶段交付模型，在整个周期内，持续不断的产出阶段性成果，把有用的功能交付到客户手中。

阶段交付能够提供有形的阶段进度产出。这样的进度产出能够使项目进度压力更加可控。

3.缺点

阶段交付的主要缺点是，如果管理层面和技术层面缺乏仔细的规划，工作就无法进行。

使用阶段交付模型需要注意的问题是：

在管理层面上，你需要确信所规划的阶段对用户非常有意义，而且在工作安排上保证员工能及时在阶段最后期限完成。

在技术层面上，你需要确信考虑了不同产品组成部分的技术依赖性。通常会犯的一个错误就是把一个在第二阶段就需要用到的组件，放在了第四个阶段才开发。

面向进度的设计

1.说明

面向进度的设计模型，类似于阶段交付，相同点是都在连续的阶段规划产品。差异是面向进度设计模型，在开始的时候不必知道究竟能达到什么样的预定目标。你可能规划了五个阶段，由于一些限制，仅仅完成了前三个阶段。

2.适合情境/优点

面向进度的设计模型，能确保你在一个确定的日期发布产品。

该模型的关键在于按优先级区分系统特性，规划开发阶段。比如windows系统中包括了一些小程序，比如计算器，写字板，画笔等，可以为这些小程序采用面向进度的设计模型，来保证他们不影响windows的开发和发布。

是否使用本模型，取决于你对自己的工作规划是否有信心。如果你非常有信息，那么面向进度的设计是个低效的模型，如果你不是那么自信，这个模型就很有用了。

3.缺点

面向进度的设计模型，最大的缺点是如果你不明白所有阶段，就会浪费时间去指定，架构和设计你不需要的特性。

渐进交付！

1.说明

渐进交付是一种跨越了渐进原型和阶段交付两种模型的生命期。渐进交付跟渐进原型比较类似，区别是取决于你计划满足用户需求的程度。如果你计划满足用户的绝大部分需求，渐进交付就跟渐进原型差不多。如果你计划满足少量的需求，渐进交付就跟阶段交付差不多。

渐进交付于渐进原型最大的差别不在方法上，而是工作重点上。渐进原型中，你强调系统看得见的样子，然后回来补系统漏洞；在渐进交付中，你在乎的是系统的核心。

增量开发方法

增量开发方法包括螺旋型模型，渐进原型，阶段交付，渐进交付。

面向开发工具的设计

商品软件

当你兴冲冲的准备做一个新系统时，一个常常被忽略的选择就是可以直接购买商品软件。

为项目选址最快的生命期模型！

第一章到第七章 完成

第八章以后见另外一篇

第八章 估算

关于软件估算，首先你需要考虑怎样利用数据做出合理的估算。其次，如果你提出的估算不能被接受，那么估算再准也没有任何意义，所以也要考虑软件工程进度安排中的人际因素。

1.软件估算的故事

软件开发是一个逐进的过程，所以估算也是渐进的过程。

1.软件和建筑

你询问建筑师10万元是否能建一座两室两厅的房子，建筑师会告诉你可以。如果开工之后你才对他说你需要大理石壁炉，镀金家具，意大利瓷砖和良好的地理位置，那么最终你房子的造价可能是最初的好几倍。

2.软件开发是一个渐进的过程

只有详细的了解到每个功能，才有可能做出准确的估算。产品概念到需求说明到概要设计到详细设计到最终编码，而在每个阶段，都可能做出影响最终编码的决策，这种不确定性，也就导致了估算的不确定性。以下是一些常见的问题：

l客户会中途需要X功能吗？

l客户需要的X功能，是要便宜的版本还是昂贵的版本？

lX功能，如果实施了便宜版本，客户以后会不会想要改成昂贵的版本？

lX功能的质量级别是什么？

l把X功能和其他功能结合起来需要多少工作量？

所以，能够提前做出的决策越多，估算的精确度就越高。

3.可能细化的数量

从上表可以看出，对项目的整体估算，在开始是比较笼统的(即使需求说明书完成之后)，随着项目的进行，才逐渐变得精确起来。

从上表中可以看出，估算应该是一个范围，而不是一个定数。以你的估算乘以乐观系数，就得出乐观估算，乘以悲观系数，就得到悲观估算。

如果客户坚持需要得到估算，你也觉得可以给到，是可以提交到客户的。当然大部分情况下，最好是记录在自己手里，而不是公布。

在同时使用工作量系数和进度系数时：

一定要注意区分工作量系数和进度系数(原因后章中会解释)。

一定要先估算工作量，再估算进度。进度是从工作量推出来的。

如果你先粗略的估算了进度，就最好不要使用工作量系数。

4.估算与控制

客户总是希望提供的资源少些，而得到的功能多些。两者总是无法同时满足的，于是最终的结果只有两种，功能趋于与资源匹配，或者资源趋于与功能匹配。如下图：

5.合作

到目前为止，我们讨论的是估算的难度，原因也是情有可原的。但是人们总是希望能够得到准确的估算，而我们也同样有义务给他们提供。

这里的建议是，主动告知客户你能提供的部分，如果你知道什么时间会有更好的估算，也告知他们。不要让他们游离在项目之外，告诉他们关于里程碑的信息。通过对客户描述项目估算的整体设想，帮助他们理解整个项目的战略方针。并告诉他们你将在产品定义，需求说明，概设和详设结束时修订估算。

l估算与实际的交汇点

6.项目估算概要

l准确与精确

准确是指估算与结果相近。

精确是指估算的数位很多。

例子：对于数学常数“派(3.141592658)”来说，3是准确的，但不一定精确，3.3232是精确的，但不是准确的。

通常在软件估算中，精确是准确的敌人。40到70个人月的工作量，是你能做到的准确和精确的估算，如果客户一定要求精确，你将估算做到55个人月，精确度提高了，但实际并不准确。

2.软件估算的步骤

1.估算产品规模

最有效的估算需要从规模开始。通常这是最消耗脑力的一步，也是人们常常跳过这步的原因。这里提到的规模，包含功能集的广度与深度，以及复杂度等。

2.估算工作量

3.估算进度

一旦规模和工作量估算出来之后，进度通常是微不足道的(原因将在后章解释)。但是得到一个多方都认可的进度估算，却是项目中最困难的部分。

4.提供某一范围的估算

随着项目的进行，范围也许将发生变化，所以提供出来的估算是基于项目范围的。当范围变化时，也需要同步修订估算，以提高精确度。

3.估算产品规模

对于产品规模的估算，可以用以下几种方法：

使用规模估算算法

使用规模估算软件

类比估算

无论何种估算方法，准确的项目历史记录是长期成功的关键。

1.功能点估算(参数估算)

功能点数量建立在以下各项的数量和复杂度上：

l输入

l输出

l查询

l内部逻辑文件

l外部接口文件

一个中等复杂的输入点，我们可以近似看作两个一般复杂的输入点，于是如果我们建立了一套复杂程度转换系数，就能算出系统全部折算成一般复杂点的量。如下图：

2.估算技巧

l避免没有准备的估算

l留出估算的时间，并做好计划

匆忙的估算不会是准确的估算。对于有些大型项目，估算本身就是一个单独的项目。

l使用以前的项目数据(类似PMP的类比估算)

l使用以开发人员为基础的估算

l走查估算(类似PMP的群体决策)

项目成员分别估算各自的部分，然后开走查会议比较所有的估算，分析讨论估算差别，直到对估算达成一致意见。

l分类法估算

简单地把内容分为容易，中等和难，每一类分配固定的规模，累加各个规模数值得到总的项目规模。

l详细的较低层次的查表估算(类似PMP里的自下而上的估算)

估算建立在详细检查项目活动的基础上，通常检查的越仔细估算越准确。这点类似于PMP里的自下而上的估算。

l不要忽略普通任务

人们通常不会主动忽略任务，但是如果分配给估算的时间不够，就常常忽略一些普通任务，比如：数据转换，定制，安装，测试，版本管理，给客户演示，会议，缺陷修正，缺陷跟踪，集成，评审，休假，节假日，员工请假，公司和部门会议等。

l使用软件估算工具

l使用几种不同的估算技术，并比较结果

l在项目进行中改变估算方法

项目初始阶段，用估算算法或查表估算，

PMP里的估算方法

l专家判断

l类比估算

通过类似的项目来估算。

适合项目早期使用。

成本低，耗时少，准确性低。

如果本质越类似，估算团队越专业，准确性越好。

l参数估算

基于历史数据和项目参数的估算。

例如：曾经4个苹果20元，则20/4=5元/个，那么估算10个苹果，应该是50元。

l三点估算

三角分布：Te = (To + Tm + Tp) / 3

贝塔分布：Te = (To + 4Tm + Tp) / 6

l群体决策技术

l储备分析

应急储备，应对已知-未知风险。

管理储备，应对未知-未知风险，不在进度基准中。

3.估算的表达方式

软件估算包含很大的风险和不确定性，好的估算应该捕捉到这些风险和不确定性。

l加减限定

使用加减限定的估算方式，可以表明估算中的风险和不确定性。即使你被迫在不显示的时间段完成工作，也可以通过加减的方式表达估算结果，让周围的人明白进度风险。

缺点在于，有时候人们只关注估算值，而忽略了加减限定部分。

例子：一个项目，估算6个月，+-2个月。

l范围

为应对加减限定的缺点，可以采用范围估算。

例子：一个项目，估算4到8个月。

l风险量化

风险量化可以将加减估算扩展到解释加减代表的意义。

例子：

在记录下风险项之后，可以向客户提出减少风险的措施。当你用风险量化估算时，一定要准备好回答关于怎样确定风险和怎样利用潜在的可能缩短进度的问题。

l基于情况

风险量化很大程度上就是基于情况的，所以可以用最佳情况，一般情况和最差情况来描述估算。

例子：

计划情况总是趋向于最佳情况，而当前实际情况总是趋向于最差情况。

准备好向客户解释分别发生什么，才会导致最佳情况和最差情况。

l粗略的日期和时间段

如果是粗略的估算，就使用显得粗略的数字，比如3x97或10人年，而不要用误导性的精确的数字，比如2017-03-07，或520人周。

不论怎样粗略的估算，如果估算是3x50左右，最终还是能对应到相应的日期，怎么处理这个日期带来的误导性呢？

l把握性因素

1.估算工作量

尽管对于软件项目来说，工作量估算并不是必须的，但是它对进度估算有着非常重要的作用。

2.估算进度

进度估算公式：

3(常量)× 人月(工作量)的三分之一次方

例如：

如果工作量预估为65个人月，则总进度计算为：

3乘以65人月的三分之一次方= 12月

所以这个公式还在暗示，你需要65人月/12月= 5到6个开发人员。

这个进度估算公式只是作为参考，我觉得按找PMP里的画甘特图要好一些。

1基于承诺的进度表

有些组织直接从时间需求出发逆推安排进度，而不是从估算出发正推进度。这种做法使团队基于承诺的文化中，要求开发人员做出进度承诺而非进度估算。

这种做法有一些优点：有利于开发者对进度的关注，有利于开发者在接受任务后士气高昂，有利于开发者自愿加班。

当然缺点也比较明显：开发者通常缺乏经验而比较乐观，通常进度将延误30%左右。没有数据可供检查。容易挫伤士气等等。

我们在第一部分的第二章已经讨论过基于承诺的开发，在快速开发中，承诺有一定的作用。但如果基于承诺的计划用正常的方式去做，并不能缩短进度。

承诺应该是现实的，可行的，否则将导致团队不断失败。

不论基于承诺还是其他估算，只有准确的进度表才是项目的保障。

2 Jones的一阶估算

一阶估算基于功能点总数。先获得功能点总数，然后从下表中选取合适的幂次将功能点数升幂。

3.大致的进度估算

1可能的最短进度

l假定

可能的最短进度中，包含着非常多非常乐观的假设。这些假设包括：

1)员工。你假设你的团队都是顶尖员工，每个人都目标明确，每个人都努力工作，和睦相处，且不存在人员调整问题。

2)管理。你假设项目有理想的管理，开发人员不需要分散精力到与技术无关的事情。

3)工具支持。你假设高效工具唾手可得。

4)方法。你假设所有开发和管理方法，都是有效和没有失误的。

5)压缩。你假设所有工作都已经压缩到了最优。

l两个事实

1)存在一个最短时间，而且无法超越它。在某些时候，增加开发人员将会减低开发速度，而不是像想象的那样加快速度。

2)当你把进度缩短到比普通进度更短，费用将迅速上涨。当你的工具和方法到位，可以简单的通过增加开发人员的方式来缩短进度，PMP称为进度压缩。然而不论加多少人，始终都有一个可能的最短进度。

进度压缩因子=期望进度/初始速度

上面是进度压缩因子的公式，用来计算进度压缩的比例。比如你最初预估需要12个月(初始速度)完成，现在必须在10个月(期望速度)内完成，那么进度压缩因子就是12/10=0.83。

压缩进度工作量=初始工作量/进度压缩因子

上面是压缩进度工作量的公式，其含义是进度压缩17%，工作量需要增加21%。比如进度压缩因子是0.83，初始工作量是78人月，那么压缩进度工作量就是78/0.83=94人月。

大量研究表明，即使进度压缩，也是有一个限度的，不可能获得0.75以下的进度压缩因子。

4.估算修正

应该在整个项目过程中，持续进行估算修正。

但是估算修正有一些需要注意到地方。如下：

当你做估算修正时，将100人月增加到135人月后，人们会觉得项目已经陷入麻烦中。这是可笑的，因为100人月的估算是基于当时的情况。作为项目经理如何避免这个情况呢？如下：

可以将估算表达方式改成范围。随着进度的推进，持续修正范围。

1估算再修正！

假定有一个6个月的进度计划，你计划4周内完成第一个里程碑，而实际花了5周才完成，当你错过进度日期时，你有以下几个选择：

1.在后续进度中加快速度，弥补这一周的损失。

2.把这一周的延迟加到整个项目中。

3.按比例延迟整个进度计划。这个例子中就是(5-)4/4=25%，即整体进度全部延迟25%。

人们通常容易选择第一个方案，但是调查表明项目几乎不能弥补损失的时间，而总是倾向于更加拖延。

估算的不准确与倾向性是遍布整个进度计划的，如果第一个里程碑不准确，那么有理由认为所有里程碑都有同样的倾向。所以第二种方案看起来很正常，但是是没有多少道理支撑的。

第三种方案是最符合逻辑和经验的。但也是最困难的。你也可以晚一些做决定，通过监控第二个里程碑来获得更多信息。但是如果你在第二个里程碑延迟之后，仍不愿意整体修正，那今后就几乎不可能进行整体修正了。

当然，错过里程碑之后并非只有估算再修正这种方式。也可以通过调整范围，或者成本来解决。其本质就是借助三重约束(范围-时间-成本)来调控项目。唯一不能做的就是期望项目追赶进度的同时保持进度，产品和成本不变。

第七章进度计划

项目估算和进度计划是我们面对的两大难题，在二者中我认为后者更为迫切。

前面一章中我们着重描述如何制定精确的项目估算，本章则阐述如何使其为他人所接受。

1.过分乐观的进度计划

1过分乐观的进度计划产生的不良后果

l计划的精确性

过分乐观的计划，常常无法完成。

l计划的质量

l坚持执行计划

l功能范围缩小

l项目推进

l客户关系

l仓促收尾

2超负荷的进度压力

当面临无法如期完成的局面时，客户和管理人员第一反应就是想开发人员施压，加班加点追赶进度。而超负荷的进度压力很大程度是由过分乐观的进度计划导致。进度压力将引发多种问题。

l产品质量

l赌博心理

由于过分乐观的进度计划按照规范的开发方法是无法实现的，因此开发人员和管理人员都将抱着赌一把的心态，而不是估算风险值。比如说：“我不确定这款工具能不能提高生产力，但是注定无法如期完成的话，为什么不试试呢？”

l激励效应

紧凑的进度计划可以激发开发人员的挑战天性，但当进度计划变得过分乐观时，将导致开发人员付出了巨大的努力，却仍然被看作是失败者。因此，任何期望过分紧凑的进度计划来产生激烈作用的尝试注定失败。

l创造性思维

l精疲力竭

l中途退出

l长期进行快速开发

l开发人员与管理人员的关系

3底线

对于过分乐观的进度计划，这样的计划不起作用，不但没有缩短，反而还让工期变长了。

2.战胜进度压力

进度压力是软件项目的通病，将导致两个层面的错误：从局部来看，它鼓励走捷径，而实际上这会损害项目本身；从全局来看，它鼓励救火行为。

对于软件进度计划设定方面相关的三个主要因素有：

l主管愿望

l对过于乐观的计划缺乏认识

l缺乏谈判技巧

1有原则的谈判

l将人从困境中解脱

任何谈判都是首先与人有关，其次才是利益与立场。首先要对管理者多加理解，他们可能受限于上司，客户或者投资机构的压力。大多数中层管理人员之所以坚持开发人员按照不可能的进度计划进行执行，并非是由于愚蠢或不通情理，而很可能是由于对技术缺乏认知，或受迫于上司。作为开发人员，应该怎么处理呢？

第一，应该以合作的态度努力改善与管理层的关系，设法让他们理解软件估算的渐进原则和过分乐观的进度计划带来的危害。尽量成为一个建议者，而不是扮演对立的角色。

第二，不要坚持谈判各方都需要达到绝对平衡。最简单的方式是当对方发脾气时，不要争锋相对耐心的等他把话说完，并表示理解，然后重申双方应该探寻一个双赢的方案。

l关注共同利益，不要过分坚持立场

l提出对双方都有利的备选方案

l坚持客观标准

当谈判陷入僵局时，你应该尝试使用客观标准将其打破。只能向客观标准妥协，而不能向压力屈服。

以下是坚持客观标准的一些方针：

1)谈判不要局限于估算本身

你可以就估算的输入条件进行谈判，而不要纠结于估算本身。输入条件就是前面说的可以灵活变通的选项。

2)坚持以专业的组织进行估算

3)坚持科学的估算过程

4)顶住压力

也许每个人承受压力的程度不同，但当客户，管理人员或市场人员不停的要求增加新需求，却又不愿意延长进度时，最好的办法就是礼貌的拒绝这种要求。与其承担后期进度和成本的严重超支，不如在前期就顶住压力。