人月神话札记之人月神话

前言:美食的烹饪需要时间,那么稍等片刻,你将享用更多的美味。缺乏合理的进度安排是造成项目滞后的重要原因,因素有以下内容:

- 对估算技术缺乏有效的研究

- 进度和工作量混淆,就是说人员和时间可以转换

- 对自己的估算缺乏信心

- 缺乏信心

- 对进度缺少跟踪和监督,所以站立会和燃尽图至关重要

- 意识到进度偏移时,第一个反应是增加人力,而这时大多数情况如同火上浇油,火越来越大,需要的汽油却越来越多


乐观主义

书中说,编程人员都是乐观主义者,我想,在国内,需求者比编程人员更“乐观”,他们引导设计者和架构师走上极端的左倾主义。我存有一种愿景就是,希望未来需求者能够考虑足够的风险,树立一种观念就是每一项任务不仅仅是花费它“应该”花费的时间。

对于创造者来说,只有在实现的过程中,才能发现构思的不完整性和不一致性。也就是说,我们去做1.0版,意义重大,1.0版能够帮助我们更好的去反思我们的设计。

作为我们程序员来说,“一切都会完美的运行”几乎是不可能的,从我们自身来说,当我们写完代码后,必须要抱着怀疑的态度,去检查我们创造的代码,减少bug。

人月

人员和时间不能在所有场所内进行替换。

  • 对于像割小麦的任务中,人员和时间可以相互转换,增加人手,必定能减少割麦子的时间。
  • 对于像母亲孕育孩子的过程中,必须要经历10月怀胎,这是无法进行分解的。
  • 对于需要沟通可以分解的任务,其人员和时间的关系图,在人员增加到一定程度上时,需要的时间不会再减少
  • 对于关系错综复杂的任务,其人员的增加在一定程度上还会增加时间的投入,这个是最可怕的。

从实际的开发经验中,可以得出,软件开发是错综复杂的过程,那么没有弄清楚效率降低、进度延迟的真正原因时,盲目的追求人员的增加会让事情更糟。

系统测试

系统测试的时间在大多数的软件开发中,系统测试被开发团队忽略,往往很多时候,开发人员做完自己的代码后,就将测试工作丢给测试人员,这种现象我之前有所描述,见小型团队的测试该何去何从这篇文章中,我介绍了这个可怕的现象,而其解决办法竟然是增加人员。

没有合理的规划系统测试时间的话,就会带来可怕的后果,因为系统测试往往是在产品发布之前,这个时候再出现延误,代价太高。

空泛的估算

大多数情况下,产品经理或者项目经理和客户的关系就如同蛋糕师和顾客的关系,蛋糕的烹制过程会受到顾客紧迫程度的影响。假如顾客催促蛋糕师,那么蛋糕师可能做出两种选择,第一个就是继续按照自己的进度,让顾客等待,这样可能失去顾客;第二个是加大火力,这样蛋糕就可能出现问题。

重复产生的进度灾难

当任务没有按照原定计划执行时,就出现延期,假如出现在项目进展的第一个阶段,项目经理发现了进度延缓的问题,那么假如说他盲目的增加人手来试图缩短产品研发时间的话,就必然会重复进入到灾难的陷阱中。

增加人手会带来严重的问题,原来的开发人员需要拿掉开发的时间来培训新的人员,这样同时又将原来的进度延缓,假如再增加人手,就会进入到万劫不复的灾难中

作者有如下结论“Adding manpower to a late sofeware project makes it latter.”

那么我们该如何正确做出改变呢?

  • 重新安排进度,也就是说分配充足的时间,来确保完整的解决项目。
  • 削减任务,如果项目延期导致的二次开发成本非常高,那么这是必要的。
  • 然而增加人手,这个决策是可怕的。

总结:项目的时间依赖于顺序上的限制,而人员的最大数量依赖于独立子任务的数量。如何把握人员数量和进度之间的关系是至关重要的。

时间: 2024-10-05 17:39:26

人月神话札记之人月神话的相关文章

引子:江月何年初照人?

说起中国诗歌中的意象,如果让我们只选取一个最典型的,我们一定会想起头顶上的那一轮明月. 李太白问:"青天有月来几时?我今停杯一问之."他在唐朝停下的这只酒杯,被苏东坡在宋朝遥遥接起,"明月几时有?把酒问青天."一停一接之间,何止两次追问. 我们的古人,对头顶的那轮明月,有着无穷追问,寄托无限情怀. 江天一色无纤尘,皎皎空中孤月轮. 江畔何人初见月?江月何年初照人? 人生代代无穷已,江月年年只相似. 不知江月待何人,但见长江送流水. 张若虚在<春江花月夜>

很少人注意的暴利行业,月赚1万的6个小生意!普通人也很容易做!

不要认为月入过万很难!其实你如果认识的有老板的话,就只知道日入过万都很简单!但是对普通人来说成本都很大.今天给大家介绍几个普通人可以快速做的小生意! 第一是:开锁工!白手起家上海买房!小陈是个开锁匠.在这个行业工作了5年,技术很好.开锁上海收费都是100到400元!复杂的还要贵点!我过年的时间收快递,风一下子把门关了!叫了个开门的要350元,来了没有5分钟就开了!一天开个十个就是3000多啊!听他说在上海买房买车了啊! 很少人注意的暴利行业,月赚1万的6个小生意!普通人也很容易做!第二个是,卖煎

人月神话札记之巴比伦塔失败

前言:在最初的世界,人们只有一种语言,所以大家沟通好说去建立一个通天塔,可以通往天堂的巴比伦塔,然而上帝出现了,他交给人们不同的语言,让大伙最终无法进行交流,最终队伍遣散,巴比伦塔就此失败,那么本章作者想要告诉我们的就是"沟通"对于成功的项目很重要. 编程项目中的交流 书中主要针对的是大型项目的交流,然而同样适合我当前所处的团队: 非正式交流:以前在日企和日方沟通主要是电话会议,那么小型团队的非正式交流就是协作的人员互相凑一起说话就可以了. 会议:站立会,分析讨论会,项目评估会等任何有

人月神话札记之专制、民主和系统设计

前言:大教堂的整体设计在基本元素构成上都是一致的.有的教堂偏重于设计师的个人创意,有的教堂舍取设计师的创意而保证设计的纯粹性,在书中提出的观点中,对于计算机系统来说,保持概念的一致性是至关重要的,省略不规则的特性和改进,而反映一系列连贯的设计思路. 获得概念的完整性 一个产品如果其花费在学习使用的时间价值超出了其带给人们的使用价值时,就会难以普及和推广,我觉得产品的易用性是特别重要的.就比如说CSDN推出的Markdown和xheditor相比较,我觉得Markdown并没有征服我,主要是其用起

人月神话札记之外科手术队伍

前言:研究表明,效率高和效率低的实施者之间个体差异非常大,能够达到数量级的水平.类似我这样年龄段的产品经理来说,我认为我只需要有5个精干的成员组成团队,然而我这样的想法就面对着一个很难回避的问题-这样的小型团队很难在有计划的进度安排时间内创造大型的系统! 问题 大家知道,优秀的程序员和较差的程序员的效率存在巨大差异,书中也指出来最好和最差的效率上平均为10:1,编程速度和空间上具有5:1的惊人差异. 需要协作沟通的人员数量影响开发成本,这就意味着人员数量少的情况下,沟通就会减少.然而这不适合于大

人月神话札记:未雨绸缪

前言:软件在设计阶段如果能够多考虑一些后续的维护工作,显然是非常棒的.然而对于现阶段的我,或者很多程序员来说,未雨绸缪有很大难度,我们往往即使已经下雨了,也依然无法把窗户关紧,那么如果你想得到一些指导的话,请随我来,看看我能否品出一些味道来. 没有什么是永恒的,除了变化. 普遍的做法是,选择一个方案,试试看:如果失败了,没关系,再试试别的.不管怎么样,重要的是去尝试. 我觉得书中提供的这两个观点非常的棒,首先,任何事都不可能一成不变,敏捷宣言也提倡我们要拥抱变化.其次,在解决问题的时候,就是要不

人月神话札记:提纲挈领

前言:所谓提纲挈领,从字面上讲就是抓住渔网的总绳,提起衣服的领子,其含义(度娘说要用含义而不推荐用涵义)就是告诉我们做事情要能够抓住要领.那么本篇告诉我们什么是要领呢,就是书面文档,从一开始就要意识到其重要性,那么就不会对文档产生厌烦.因为作为技术人员来说,包括我,普遍对文档没有好感,尤其是看完了长篇大论后,发现无非就是要表达一两句话,那时候,就会气急败坏. 计算机产品的文档 对于该小节,我读了三遍,发现并没有很好的理解,所谓预测->报价->价格之间相互制约的关系,没有弄出来个所以然.希望在以

人月神话札记:干将莫邪

前言:A good workman is known by his tools.外国谚语如此,我们也有这样的古话,"工欲善其事,必先利其器".好的开发团队自然有自己一套比较完好的工具,用来提高生产力以及生产效率. 在学习编程的某一段岁月,我喜欢尝试用各种Java的开发工具,editplus.eclipse.jcreator.myeclipse.netbeans等等,最后,我决定使用eclipse.这一段探索的岁月,也证明了brooks的观点,在工作环境中,如果开发人员的工具不够统一的话

传iWatch 将在7月投入生产,10月出货,支持无线充电、触控、测量脉搏

今天又有关于 iWatch 的传言传出.据路透社的线人消息称,台湾的广达电脑(Quanta Computer Inc.)将于 7 月开始生产 iWatch,10 月出货,预计推出后首年的出货量为 5000 万支. 配置方面,iWatch 的屏幕框架偏矩形,对角线距离 2.5 英寸,镜面稍稍凸起:支持触控及无线充电,此外,iWatch 还搭载了可测用户脉搏的传感器. 合作厂商方面,广达将负责至少七成设备的最后组装工作,LG Display Co Ltd 独家供应首批成品的屏幕,新加坡的一家名为 H