典型错误

4月份的一个阳光明媚的上午，Giga医保的技术主管Mike正在办公室吃着午餐，看着窗外的美景。

“Mike，恭喜你！你已经获得了Giga-Quote计划的资金了！”Bill（Mike所在Giga医保公司的老板）兴奋地说，“执行委员会很欣赏我们关于医疗保险自动报价的设想，也欣赏每天晚上将当天报价数据上传到总部以便我们可以时刻在线获得最新的销售线索的想法。现在，我还有个会，过一会儿我们再细谈，你的项目建议书真是太棒了！”

Mike几个月前就为Giga-Quote计划写了一份项目提案，但他的项目提案只是单机版软件，不具备与总部通信的能力。哦，也好，这倒给了他在现代GUI环境下领导开发客户／服务器项目的机会，这是他向往已久的事。按他的计划建议书，他几乎有一年的时间来做这个项目，应该有足够的时间加入一些新功能。Mike拿起电话，拨了他妻子的电话号码：“亲爱的，我们今晚到外面共进晚餐庆祝……”

第二天早上，Mike约见Bill讨论这个项目：“OK，Bill，什么时候开始？这个项目似乎并不像以前我写的项目提案那样。”

Bill显得有些不自在。Mike没有参加项目提案的修改，但那是因为没有时间让他参与，执行委员会一听Giga-Quote计划就决定接受这个建议。“执行委员会欣赏构建医保自动报价系统这个设想，但他们想将地区报价数据自动传到主机系统中。而且，他们想在明年1月份新费率生效前，系统就能准备就绪。他们将软件完成日期从明年5月1日提前到了今年11月1日，将项目工期压缩到了6个月。”

Mike估计这项工作将需要12个月，他认为没有多大可能在6个月内完成。他告诉Bill：“让我们直说吧，真像你所说的那样，执行委员会加入了一块很大的通信需求，却将计划时间从12个月砍到6个月了吗？”

Bill耸耸肩：“我知道这是一个挑战，但你是具有创造能力的，我认为你能够实现。他们批准了你提出的预算，加入数据通信功能也并不是那么难。你要求36个人月，没有问题。在这个项目上，你可以聘请任何你想要的人，也可以扩大项目组的人员规模。”Bill让Mike去找一些开发人员谈一谈，找出一个可以按时交付软件的方法。

Mike找到了另一个技术主管Carl，他们寻找缩短计划的方法。Carl问：“你为什么不用C++和面向对象的设计方法？它可以比C有更高的效率，这样可以将项目计划缩短1～2个月。”Mike认为有道理。Carl也知道一种报表生成工具，据悉可以削减一半的开发时间。这个项目有许多报表，所以，这二项改变可以将项目计划缩短到9个月。由于他们拥有更新、更快的硬件设备，这样可以再削减3周时间。如果真能聘请到顶尖的开发人员，他们可以将项目计划缩短到大约7个月时间，这已经足够接近了。Mike给Bill带回了他的发现。

“看起来，”Bill说，“将计划压缩到7个月是不错，但还不足以满足项目要求，执行委员会要求6个月是最后的期限。他们不给我们选择的余地。我可以给你最新的硬件设备，但你和你的项目组必须找到一些方法或者加班加点拼命工作，将项目计划压缩到6个月内。”

考虑到起初的估计仅仅是粗略的预测，Mike认为，在6个月内完成项目是可能实现的。“OK，Bill，我将在这个项目中聘请3个合同制的顶尖高手，也许我们能够找到具有将数据从PC上传到主机上的有经验的人。”

到了5月1日，Mike已经组建了项目组，Jill、Sue和Thomas是公司内部固定的开发成员，但他们无法完成一些特定任务。Mike找了两个合同工Keiko和Chip，Keiko有开发主机和PC之间通信接口的经验，Chip是Jill和Thomas面试的，建议不宜聘请，但Mike急于用人，而Chip有通信开发经验并能够迅速到岗，所以Mike还是聘请了他。

在项目组的第一次会议上，Bill向项目组阐明了Giga-Quote项目对Giga Safe公司的战略意义：“公司的顶级人物时刻关注着我们，如果项目取得成功，我们会获得丰厚的奖赏。”他保证说他将信守承诺。

Bill鼓气激励之后，Mike与项目组成员坐下，布置项目计划。执行委员会或多或少已经提出了一些项目功能要求，其余的功能说明应在接下来的2周内完成，然后，他们花6周时间进行设计，余下的4个月进行构建与测试。粗略估计整个产品大约会有3万行C++代码。周围的每个人都点头称是。他们雄心勃勃，但在他们为此项目签约时，才意识到问题。

第2周，Mike约见了测试负责人Stacy，她说他们应该不晚于9月1日提交测试版本，并于10月1日交付功能完备并通过测试的版本。Mike同意了她的计划。

项目组很快完成了需求分析报告并进入了设计阶段。他们采用了一种似乎能很好地发挥C++功能优势的设计。

6月15日，项目组提前完成设计工作，开始了疯狂的编码，以满足9月1日发布第一个测试版本的要求。项目进展并非一帆风顺，Jill和Thomas都不喜欢Chip，Sue也抱怨Chip不让任何人靠近他的代码。Mike将这些归结于由于人们长时间工作所导致的个性冲突。然而到了8月初，他们报告说只完成了85%～90%的工作。

8月中旬，保险核算部门发布了下一年度的费率，项目组发现他们的系统必须进行调整才能完全适用于新的费率结构。新的费率方法要求有提出问题的功能，如提出像锻炼习惯、饮食习惯、吸烟习惯、娱乐活动及其他一些以前不包括在费率计算公式之内的因素这样的问题。他们认为C++的特性可以让他们不受这些变化的影响，他们已经把在费用表中插入一些新数据这样的问题提前考虑进去了。但是，他们必须改变输入对话框、数据库设计以及数据存取对象和通信对象，以适应新的结构。由于项目组处于设计修改的混乱之中，Mike告诉Stacy他们可能比预计推迟几天交付第1个测试版本。

9月1日项目组没有准备好测试版本，Mike向Stacy保证再有1～2天就可以交付了。

转眼间数周过去了，预计10月1日交付测试通过的完全版的期限也来了又过去了，而项目组还是没能提交第1个测试版。Stacy和Bill召开了一个讨论项目计划的会议。“我们还没有从开发组拿到测试版本。”她说，“原计划我们9月1日拿到第1个测试版本，而到现在我们还没有拿到，因此他们至少已经落后于计划整整1个月了。我想他们一定遇到麻烦了。”

“他们确实遇到麻烦了。”Bill说，“让我与项目组谈谈。我已经承诺，11月1日让600个代理点都能拿到软件。我们必须在新费率执行前及时拿出最后版本。”

Bill召开了项目组会议。“这是一个富于朝气的团队，你们应该兑现你们的承诺。”他说，“我不知道什么地方出了问题，但我希望每个人能够努力工作，并按时交付产品。你们还可以得到奖金，但你们必须为之努力工作。从现在起到软件完成，我要求你们每周工作6天、每天工作10小时。”在那次会议后，Jill和Thomas抱怨Mike不必像对待孩子一样对待他们，但他们同意按Bill要求的时间工作。

项目组将计划推迟了2周，承诺11月15日交付功能完整的版本。这样在明年1月1日新费率生效前，还能有6周的测试时间。

4周后，项目组于11月1日发布了第1个测试版本，然后开会讨论遗留的问题。

Thomas负责报表生成，他碰到了一个问题。“报价汇总表包括一张简单的柱状图，我使用报表生成器生成一张柱状图时，它只能单独地放在一页上，而销售部门的要求是将文字和柱状图放在同一页。我已经解决了这个问题。我可以把柱状图和报表放在同一页，我的做法是把报表文本作为柱状图对象的图例。这肯定不是最佳方案，但我会在第1次发布之后再回过头来重新做一遍。”

Mike回答：“我看不到所谓‘以后’是什么时候。Bill已经清楚地提出了要求，我们必须拿出产品，没有时间使代码尽善尽美。现在没有任何推延的可能，做出最佳方案来！”

Chip报告说他的通信编码已经完成了95%，还在继续进行，但他还有许多需要测试的东西。Mike觉察到了Jill和Thomas鄙夷的眼神，但他决定不予理睬。

直到11月15日，项目组仍在努力工作，14日和15日几乎工作得通宵达旦，但他们还是没能完成11月15日应当交付的版本。到了16日上午，项目组已经筋疲力尽了。最感丧气的是Bill，Stacy已经告诉了他11月15之前开发组没能交付功能完整的测试版本。就在上周，另一个项目经理Claire了解到项目的进展后说，他们将不会按时交付测试版本。Bill认为Claire极端保守，他不喜欢她。他向执行委员会汇报说项目在正常进行，他保证项目组正按计划推进最后的版本。

Bill告诉Mike召集项目组会议，他照办了。项目组看起来就像打了败仗一样，一个半月每周60小时的工作几乎压跨了他们。当Mike问什么时间能交付测试版本时，他得到的反应是沉默。“你们想告诉我什么？”他说：“我们今天应该有功能完整的版本，不是吗？”

“看一看，Mike，”Thomas说，“今天我的代码可以脱手，可以称之为‘功能完整’，但我可能还需要3周的整理工作。”Mike问Thomas的“整理工作”是什么意思。“我还没有将公司的标志放到每页上，我还没有将代理点的名称和电话号码打印到每页的下边，还有一些其他类似这样的事情。所有重要的事情都已经做完了。我认为已经做完了99%。”

Jill也说：“我也确实没有100%完成。我以前的项目组经常叫我做一些技术支持工作，我大约每天得为他们工作2小时。另外，到现在我才知道要给代理点提供在报表中加入它们名称和电话的功能，而我还没有设计输入这些数据的窗口，同时，我还得做一些处理这些窗口的工作。我本以为在‘完成功能完整’的里程碑标志时间点提供的版本不需要这些功能。”

现在，Mike也感到丧气了。“如果这就是我要听到的，你们告诉我，要具备功能完整的软件还需要3周，对吗？”

“至少需要3周。”Jill说，开发组成员表示赞同。Mike绕着桌子一个一个地问每个人，他们是否可以在3周内完成所承担的工作，每个人都表示，如果努力工作，他们可以完成。

那天，经过长时间、令人不舒服的讨论之后，Mike和Bill同意将项目计划顺延3周到12月5日，同时要求项目组每天工作长达12小时，而不再是10小时。Bill说他需要向老板展现的是他掌握着开发的节奏。计划的修改意味着测试和地区代理点的培训必须同步进行，这是1月1日发布软件的唯一办法。Stacy抱怨没有给QA足够的时间测试软件，但Bill驳回了她的说法。

12月5日中午前，Giga-Quote项目组将功能完整的Giga-Quote程序提交测试。剩下的工作就是需要一个长时间的休息，从9月1日以来，他们几乎一直在工作。

2天后，Stacy发布了第1个问题报告，该死的报告打破了轻松的休息。2天中，测试组在Giga-Quote程序中发现了200多个问题，包括必须处理的一类严重错误23个。“我看不到任何于明年1月1日将软件发给各代理点的希望。”她说，“测试组可能需要较长时间重新编写测试用例，并且，我们每小时都在发现新的错误。”

第二天上午8点，Mike召开了项目组成员会议。开发人员都脾气暴躁，火气十足，他们说虽然存在严重错误，但报告中的许多问题并不是真正的错误，有些纯粹是操作上的误解。Thomas指出，例如第143号错误，“测试报告中的第143号说在报价汇总表中，柱状图要求在页面的右侧而不应放在页面左侧。这很难说是一类严重错误，这是典型的测试问题反应过度。”

Mike分发了测试问题报告，他要求开发人员检查测试中出现的问题，并估算修正每个错误所需要的时间。

当项目组下午再次碰面时，消息不太好。“现实一点。”Sue说，“我估计处理已经发现的问题至少需要3周的时间，加上我还要完成数据库一致性工作，从现在起，我总共需要4周时间。”

Thomas已经将第143号错误发回到测试组，申请将错误级别从一类错误改为三类错误——“修饰性错误”。测试人员回答说，Giga-Quote所提交的汇总报告必须与主机的政策更新程序所产生的类似报告的形式相似，它们也应该与公司使用多年的市场印刷材料相符合。公司600多个代理点已习惯将销售柱状图放在页面的右侧，所以它必须放在右侧。因此，将其归为一类严重错误。

“记得我当初用来在同一页上显示柱状图和报表的临时方案吗？”Thomas问，“要将柱状图放在右侧，我必须从头重写那个报表，那意味着我必须自己编写底层代码才能实现报表要求的图文格式。”Mike小心翼翼地问那样做粗略估计需要多少时间，Thomas说至少得花10天的时间，而确切时间还需要仔细研究一下才能知道。

那天回家前，Mike告诉Stacy和Bill，项目组整个假期都要工作才能在1月7日处理完已发现的所有错误。Bill说他真的希望这是最后一次了，在开始去年夏天就已经计划的为期1个月的加勒比海休假前，他批准了项目计划顺延4周。

接下的1个月时间里，Mike又把项目组召集在一起。4个多月来，项目组成员玩命工作，他认为已经不能再逼他们了。他们每天要在办公室呆上12小时，但他们会花许多时间看杂志、支付账单、电话聊天，而一旦问起他们处理碰到的错误需要多长时间时，他们就会变得火冒三丈。他们每处理一个错误，测试人员就会发现两个新的错误。一些本来估计花几分钟就可以解决的问题由于牵扯到项目各方，变成需花数天时间才能解决。很快他们意识到他们无法在1月7日前处理完所有错误。

1月7日，Bill休假返回，Mike告诉他开发组还需要4周时间。“糟透了。”Bill说，“我的600多个地区代理已经对你们这些搞计算机的家伙愤怒不已了。执行委员会正在考虑取消这个项目。无论如何，必须在3周内处理完所有的问题。”

Mike召开项目组会议，讨论解决办法。Mike告诉大家Bill的态度，要求他们给出最终可以发布产品的时间，是仅仅1周，还是1个月。大家沉默不语，没人愿意冒险猜测什么时间能够发布最终产品。Mike不知该如何向Bill汇报。

会后，Chip告诉Mike，他已经接受了另外一家公司的合约，合同于2月3日开始。Mike开始感到项目可能会被取消。

Mike找到了负责编写PC-主机通信模块中主机程序的编程员Kip，让他帮助处理本项目中PC的通信代码。经过与Chip所编代码1周的“鏖战”，Kip认识到程序中存在一些深层缺陷，这意味着程序很难正确运行。Kip被迫重新设计，并重新编写PC-主机通信中的PC侧程序。

2月中旬，Bill由于一直忙于开会，因此决定Claire来继续监控Giga-Quote项目的进展。星期五，Claire约见Mike。“这个项目已经失控了。”她说，“我一直没有从Bill处获得有关几个月来可靠的项目估算计划。这是6个月的项目，现在已经拖延了3个月，而且还没有结论。我已经看了问题分析报告，而且，项目组还没有解决这些问题。你们一直长时间工作，但收效甚微。我要求你们周末休息，然后，我要你们做一个详细的、逐步包括所有事情的报告，我所说的所有事情是指项目剩下的事情。我不要求你们强制将项目按人为的计划执行，我想知道是否还需要另外9个月时间。下个星期三给我一份项目结束的报告。报告不需要那么讲究，但必须完整。”

开发组成员很高兴有了周末，并有足够的精力投入到下周准备报告的工作中。星期三，报告准时出现在Claire的桌子上。她与已看过问题分析报告的软件工程顾问Charles一起分析这份报告。Charles建议项目组的重点应放在少数有问题倾向的模块上，对所有已处理的错误迅速开始设计和编码检查，项目组按正常作息时间工作，以确保他们能准确地找到问题，并按要求正确地解决。

3周后，也就是3月的第一周，所有发现的错误第一次全部被剔除。项目组士气高涨，项目进展稳定。到5月15日，顾问建议，软件可以交付进行整体测试和可靠性测试了。由于Giga Safe半年费率增长在7月1日生效，因此Claire确定软件正式发布的日期是6月1日。

结束语

Giga-Quote程序按计划于6月1日发布到各地区代理点。Giga Safe的地区代理点给予了热烈的欢迎，有些地方还举行了接收仪式。

Giga Safe向开发组每位成员颁发了250美元的奖金，以感谢他们辛勤的工作。几周以后，Thomas要求长期休假，Jill也跳槽到另外一家公司去了。

最终Giga-Quote产品花了13个月才得以交付，而不是计划的6个月，时间超过计划100%。开发人员的工作量，包括加班，总计98个人月，超过计划的36人月的170%。

最终的产品不包括空行和注释行大约为4万行C++代码，超出Mike当初的粗略估计量33%。作为分发到600多个地点的应用产品，Giga-Quote是个介于2B和2C之间的混合体，这种类型和规模的产品正常应该在11.5个月使用71个人月完成，这个项目在这两方面均超过了平均值。

相关主题

有关各种规模项目粗略估算表的内容，请参考第8.6节。