OpenVINOTM,给你看得见的未来!>>
电子产品世界 » 论坛首页 » 综合技术 » 人月神话

共2条 1/1 1 跳转至

人月神话

菜鸟
2002-11-20 00:28:00    评分
美酒的酿造需要年头,美食的烹调需要时间;片刻等待,更多美味,更多享受。 - - 新奥尔良Antoine餐厅的菜单 在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有 因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢? 首先,我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并 不真实的假设——一切都将运作良好。 第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混 淆。 第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作 。 第四,对进度缺少跟踪和监督。其他工程领域中,经过验证的跟踪技术和常规监督程序 ,在软件工程中常常被认为是无谓的举动。 第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。这就像使用汽 油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定 会导致灾难的循环。 进度监督是另一篇论文的主题,而本文中我们将对问题的其他方面进行更详细的讨论。 乐观主义 所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人 ;也可能是成百上千琐碎的挫折赶走了大多数人,只剩下了那些习惯上只关注结果的人 ;还可能仅仅因为计算机还很年轻,程序员更加年轻,而年轻人总是些乐观主义者—— 无论是什么样的程序,结果是勿庸置疑的:“这次它肯定会运行。”或者“我刚刚找出 了最后一个错误。” 所以系统编程的进度安排背后的第一个假设是:一切都将运作良好,每一项任务仅花费 它所“应该”花费的时间。 对这种弥漫在编程人员中的乐观主义,理应受到慎重的分析。Dorothy Sayers在她的“ The Mind of the Maker”一书中,将创造性活动分为三个阶段:构思、实现和交流。书 籍、计算机、或者程序的出现,首先是作为一个构思或模型出现在作者的脑海中,它与 时间和空间无关。接着,借助钢笔、墨水和纸,或者电线、硅片和铁氧体,在现实的时 间和空间中实现它们。然后,当某人阅读书本、使用计算机和运行程序的时候,他与作 者的思想相互沟通,从而创作过程得以结束。 以上Sayers的阐述不仅仅可以描绘人类的创造性活动,而且类似于“基督的教义”,能 指导我们的日常工作。对于创造者,只有在实现的过程中,才能发现我们构思的不完整 性和不一致性。因此,对于理论家而言,书写、试验以及“工作实现”是非常基本和必 要的。 在许多创造性活动中,往往很难掌握活动实施的介质,例如木头切割、油漆、电器安装 等。这些介质的物理约束限制了思路的表达,它们同样对实现造成了许多预料之外的困 难。 由于物理介质和思路中隐含的不完善性,实际实现起来需要花费大量的时间和汗水。对 遇到的大部分实现上的困难,我们总是倾向于去责怪那些物理介质,因为它们不顺应“ 我们”设定的思路。其实,这只不过是我们的骄傲使判断带上了主观主义色彩。 然而,计算机编程基于十分容易掌握的介质,编程人员通过非常纯粹的思维活动——概 念以及灵活的表现形式来开发程序。正由于介质的易于驾驭,我们期待在实现过程中不 会碰到困难,因此造成了乐观主义的弥漫。而我们的构思是有缺陷的,因此总会有bug。 也就是说,我们的乐观主义并不应该是理所应当的。 在单个的任务中,“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇 的延迟是一个概率分布曲线,“不会延迟”仅具有有限的概率,所以现实情况可能会像 计划安排的那样顺利。然而大型的编程工作,或多或少包含了很多任务,某些任务间还 具有前后的次序,从而一切正常的概率变得非常小,甚至接近于无。 人月 第二个谬误的思考方式是在估计和进度安排中使用的工作量单位:人月。成本的确随开 发产品的人数和时间的不同,有着很大的变化,进度却不是如此。因此我认为用人月作 为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可 以相互替换的。 人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之间 不需要相互的交流(图2.1)。这在割小麦或收获棉花的工作中是可行的;而在系统编程 中近乎不可能。 图2.1 当任务由于次序上的限制不能分解时,人手的添加对进度没有帮助(图2.2)。无论多少 个母亲,孕育一个生命都需要十个月。由于调试、测试的次序要求,许多软件都具有这 种特性, 图2.2 对于可以分解,但子任务之间需要相互沟通和交流的任务,必须在计划工作中考虑沟通 的工作量。因此,相同人月的前提下,采用增加人手来减少时间得到的最好情况,也比 未调整前要差一些(图2.3)。 图2.3 沟通所增加的负担由两个部分组成,培训和相互的交流。每个成员需要进行技术、项目 目标以及总体策略上的培训。这种培训不能分解,因此这部分增加的工作量随人员的数 量呈线性变化1。 相互之间交流的情况更糟一些。如果任务的每个部分必须分别和其他部分单独协作,则 工作量按照n(n-1)/2递增。一对一交流的情况下,三个人的工作量是两个人的三倍,四 个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的 问题,情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所 产生的作用,此时我们会被带到图2.4的境地。 图2.4 因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的 工作量非常大,它很快会消耗任务分解所节省下来的个人时间。从而,添加更多的人手 ,实际上是延长了,而不是缩短了时间进度。 系统测试 在时间进度中,顺序限制所造成的影响,没有哪个部分比单元调试和系统测试所受到的 牵涉更彻底。而且,要求的时间依赖于所遇到的错误、缺陷数量以及捕捉它们的程度。 理论上,缺陷的数量应该为零。但是,由于我们的乐观主义,通常实际出现的缺陷数量 比预料的要多得多。因此,系统测试进度的安排常常是编程中最不合理的部分。 对于软件任务的进度安排,以下是我使用了很多年的经验法则: 1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试,所有的构件已完成 在许多重要的方面,它与传统的进度安排方法不同: 1. 分配给计划的时间比寻常的多。即便如此,仍不足以产生详细和稳定的计划规格说明 ,也不足以容纳对全新技术的研究和摸索。 2. 对所完成代码的调试和测试,投入近一半的时间,比平常的安排多很多。 3. 容易估计的部分,即编码,仅仅分配了六分之一的时间。 通过对传统项目进度安排的研究,我发现很少项目允许为测试分配一半的时间,但大多 数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目,在系统测试之前 还能保持进度。或者说,除了系统测试,进度基本能保证2。 特别需要指出的是,不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在 项目快完成的时候。直到项目的发布日期,才有人发现进度上的问题。因此,坏消息没 有任何预兆,很晚才出现在客户和项目经理面前。 另外,此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前,项目已 经配置了充足的人员,每天的人力成本也已经达到了最大的限度。更重要的是,当软件 用来支持其他的商业活动(计算机硬件到货,新设备、服务上线等等)时,这些活动延 误出现即将发布前,那么将付出相当高的商业代价。 实际上,上述的二次成本远远高于其他开销。因此,在早期进度策划时,允许充分的系 统测试时间是非常重要的。 空泛的估算 观察一下编程人员,你可能会发现,同厨师一样,某项任务的计划进度,可能受限于顾 客要求的紧迫程度,但紧迫程度无法控制实际的完成情况。就像约好在两分钟内完成一 个煎蛋,看上去可能进行得非常好。但当它无法在两分钟内完成时,顾客只能选择等待 或者生吃煎蛋。软件顾客的情况类似。 厨师还有其他的选择:他可以把火开大,不过结果常常是无法“挽救”的煎蛋——一面 已经焦了,而另一面还是生的。 现在,我并不认为软件经理内在的勇气和坚持不如厨师,或者不如其他工程经理。但为 了满足顾客期望的日期而造成的不合理进度安排,在软件领域中却比其他的任何工程领 域要普遍得多。而且,非阶段化方法的采用,少得可怜的数据支持,加上完全借助软件 经理的直觉,这样的方式很难生产出健壮可靠和规避风险的估计。 显然我们需要两种解决方案。开发并推行生产率图表、缺陷率、估算规则等等,而整个 组织最终会从这些数据的共享上获益。 或者,在基于可靠基础的估算出现之前,项目经理需要挺直腰杆,坚持他们的估计,确 信自己的经验和直觉总比从期望派生出的结果要强得多。 重复产生的进度灾难 当一个软件项目落后于进度时,通常的做法是什么呢?自然是加派人手。如图2.1至2.4 所示,这可能有所帮助,也可能无法解决问题。 我们来考虑一个例子3。设想一个估计需要12个人月的任务,分派给3个成员4个月时间, 在每个月的末尾安排了可测量的里程碑A、B、C、D(图2.5)。 现在假定两个月之后,第一个里程碑没有达到(图2.6)。项目经理面对的选择方案有哪 些呢? 1. 假设任务必须按时完成。假设仅仅是任务的第一个部分估计不得当,即如图2.6所示 ,则剩余了9个人月的工作量,时间还有两个月,即需要4.5个开发人员,所以需要在原 来3个人的基础上增加2个人。 2. 假设任务必须按时完成。假设整个任务的估计偏低,即如图2.7所示,那么还有18个 人月的工作量以及2个月的时间,需要将原来的3个人增至9个人。 3. 重新安排进度。我喜欢P.Fagg,一个具有丰富经验的硬件工程师的忠告:“避免小的 偏差(Take no small slips)”。也就是说,在新的进度安排中分配充分的时间,以确 保工作能仔细、彻底地完成,从而无需重新确定时间进度表。 4. 削减任务。在现实情况中,一旦开发团队观察到进度的偏差,总是倾向于对任务进行 削减。当项目延期所导致的后续成本非常高时,这常常是唯一可行的方法。项目经理的 相应措施是仔细、正式地调整项目,重新安排进度;或者是默默地注视着任务项由于轻 率的设计和不完整的测试而被剪除。 图2.5 图2.6 图2.7 前两种情况中,坚持把不经调整的任务在四个月内完成将是灾难性的。考虑到重复生成 的工作量,以第一种为例(图2.8)——不论在多短的时间内,聘请到多么能干的两位新 员工,他们都需要接受一位有经验的职员的培训。如果培训需要一个月的时间,那么三 个人月将会投入到原有进度安排以外的工作中。另外,原先划分为三个部分的工作,会 重新分解成五个部分;某些已经完成的工作必定会丢失,系统测试必须被延长。因此, 在第三个月的月末,仍然残留着7个人月的工作,但此时只有5个有效的人月。如同图2. 8所示,产品还是会延期,如同没有增加任何人手(图2.6)。 期望四个月内完成项目,仅仅考虑培训的时间,不考虑任务的重新划分和额外的系统测 试,在第二个月末需要增添4个,而不是2个人员。如果考虑任务划分和系统测试的工作 量,则还需要继续增加人手。到那时所拥有的就不是3人的队伍,而是7人以上的团队; 并且小组的组织和任务的划分在类型上都不尽相同,这已经不是程度上的差异问题。 注意在第三个月的结尾时,情况看上去还是很糟。除去管理的工作不谈,3月1日的里程 碑仍未达到。此时,对项目经理而言,仍然存在着很强的诱惑——添加更多人力,结果 往往会是上述循环的重复。这简直就是一种疯狂、愚蠢的做法。 前面的讨论仅仅是第一个里程碑估计不当的情况。如果在3月1日,项目经理做出了比较 保守的假设,即整个估计过于乐观了,如图2.7所示。6个人手需要添加到原先的任务中 。培训、任务的重新分配、系统测试工作量的计算作为练习留给读者。但是毫无疑问, 重现“灾难”所开发出的产品,比没有增加人手,而是重新安排开发进度所产生的产品 更差。 简单、武断地重复一下Brooks法则: 向进度落后的项目中增加人手,只会使进度更加落后。(Adding manpower to a late software project makes it later) 这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制,人员的数量依赖于单 个子任务的数量。从这两个数值可以推算出进度时间表,该表安排的人员较少,花费的 时间较长(唯一的风险是产品可能会过时)。相反,分派较多的人手,计划较短的时间 ,将无法得到可行的进度表。总之,在众多软件项目中,缺乏合理的时间进度是造成项 目滞后的最主要原因,它比其他所有因素加起来的影响还要大。 ------------------------------------------------------------------------------------------------------------ 花 非 花                花非花,雾非雾。 夜半来,天明去。 来如春梦不多时? 去似朝云无觅处。



关键词: 人月     神话     需要     时间     软件     进度     项目     我们         

工程师
2002-11-21 19:30:00    评分
2楼
《人月神话》,Frederick P. Brooks, Jr 著,Adams Wang 译,清华大学出版社,预计2002年6月出版。“ 《人月神话》一书被大量地引用,很少存在异议;相比之下,《没有银弹》却引发了众多的辩论,编辑收到了很多文章和信件,至今还在延续。他们中的大多数攻击其核心论点和我的观点--没有神话般的解决方案,以及将来也不会有。他们大都同意《没有银弹》一文中的多数观点,但接着断定实际存在着杀死软件怪兽的银弹--由他们所发明的银弹。今天,当我重新阅读一些早期的反馈,我不禁发现在1986年~1987年期间,曾被强烈推崇的秘方并没有出现所声称的戏剧性效果。”

共2条 1/1 1 跳转至

回复

匿名不能发帖!请先 [ 登陆 注册 ]