人月神话读后有感3

最好的团队组成应该是类似外科手术队伍结构,这样我们能够获得减少沟通,提交生产效率等等诸多好处,而且最重要的是我们将获得概念的完整性。

将设计交由一个人或者非常少数忽悠默契的人来完成才能保证概念的完整性,而将体系结构,设计实现和物理实现相分离则是获得概念完整性的强有力方法,这一点契合了我们现在已经作为常识的“关注点分离”理念。

在本话题的相关章节中最让笔者印象深刻的是作者在第四章开篇序言中就以建筑业举例——建筑大师需要

  1. 首尾融会贯通其前辈建筑师的成果
  2. 同时完全掌握他们那个时代的建筑技术
  3. 最后还要能够恰如其分地运用这些技术,避免轻浮地炫耀,并绝不花哨。

以上三点,笔者觉得不仅仅适用于建筑行业,在任何行业的有志之人都需要谨记这三条法则,才能创造出杰出之作。那些喊着创新,革命的,借用郭德纲的一句话——"拿着痰桶炒菜,你打算自己享用吗?"

作者将巴比伦塔失败的原因之一归结于缺乏交流,缺乏组织。而我们能从中的来的教训之一在大型软件开发,要无比重视交流的重要性。本书初版之后四十余年的现在,人们所发明的很多技术和规范很大程度上都是为了加强“交流”,减少不必要的交流,增加交流的效率——团队组织的目的是减少所需的交流和合作的数量。制定规范也是。

正如作者直接在文中以文字形式表达的“交流和交流的结果——组织,是成功的关键”。但我们要谨记交流和组织的技能需要锻炼,相关经验的积累和能力的提高通软件技术本身一样重要,不要因为一时的失败而放弃,也不要因为成绩而固步自封。

对于交流,文档这一工具起着非常大的作用,例如项目经理的基本职责是使每个人都向着相同的方法前进,所以其主要职责是沟通,而不是做决定。因此他需要大量的文档来极大减轻他的负担 。

人们总是希望一切的事情都尽在掌握之中,所以总是试图在制定完美计划之后一路顺风顺水地执行下去。但是软件维护是一个提高混乱度(增加熵)的过程,所以出现前进两步,后退一步;甚至前进一步,后退一步都是很正常的。而且随着维护的深入,会发现用在修复原有设计上瑕疵的工作量越来越少,而早期维护活动本身所引起的漏洞的修复工作越来越多。正如大思想家斯宾塞·约翰逊曾经说过“唯一不变的是变化本身”,我们要为变更设计系统,为变更计划组织架构。

作者:夫礼者
链接:https://www.jianshu.com/p/cf5a4c50a0a6
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

原文地址:https://www.cnblogs.com/wangzhaojun1670/p/12287848.html

时间: 2024-10-12 14:35:53

人月神话读后有感3的相关文章

人月神话读后略有感想

<人月神话>是软件工程方面的一本经典著作,作者布鲁克斯(Frederick P. Brooks)被誉为“IBM System/360之父”,他曾是这一系统的项目经理,后来在设计期任360操作系统的项目经理.由于这一工作,他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖.Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师.1999年,他还荣获美国计算机领域最高奖图灵奖. 1.增量式开发.书中特别建议这种开发模式,这种开发模式最大的

人月神话-读

编程系统产品: 它是在功能上能相互协作的程序集合,具有规范的格式,可以进行交互,并可以用来组装和搭建整个系统. 要成为系统构件,程序必须按照一定的要求编制,使输入和输出在语法和语义上与精确定义的接口一致. 只有它才是真正有用的产品,是大多数系统开发的目标. 编程非常有趣,在于它不仅满足了我们内心深处进行创造的渴望,而且还愉悦了每个 人内在的情感. 原文地址:https://www.cnblogs.com/amelie-/p/10964891.html

读《人月神话》有感

<人月神话>是IBM360系统之父布鲁克斯所著的经典,它为人们管理复杂项目提供了颇具洞察力的见解,既有很多发人深省的观点,也有大量的软件工程实践,读后受益匪浅,倍受启发. 本书分为15节,其中焦油坑,人月神话,外科手术队伍,贵族专制,民主政治和系统设计以及没有银弹是我最喜欢的几章,以下是我从这几个章节所获得的知识和见解:从(焦油坑)一节中,我认识到了 编程系统产品开发的工作量是供个人使用的.独立开发的构件程序的九倍:编程行业也存在一些苦恼:(1) 将做事方式调整到追求完美,是学习编程的最困难部

读“人月神话”有感

在软件工程这门课中我们学到,一个软件的开发过程不是简单的一个选择编程语言编码实现的过程,而是一个要经过可行性研究分析.需求分析.形式化说明.总体设计.详细设计再到编码实现的过程,后期还需要对软件进行维护,整个软件的开发过程需要开发成员之间的密切而有效的合作. 这个学期,经同学的推荐,我读了一下<人月神话>这本书,一开始并不知道这是一本关于软件工程的书,毕竟这书名迷惑性太大,一般的人都会理解为是人跟月亮的神话,完全不会像软件工程的方向靠近.不过当你读了这本书之后会发现,整本书都是在以一种非常幽默

读《人月神话》一书有感

<人月神话>是一本不可多得的软件工程方面的经典著作.作者是被誉为IBM 360之父的Frederick P. Brooks,他在此项目中担任项目经理.他也因此获得美国国家技术奖和计算机领域的“诺贝尔奖”-图灵奖. 我觉得本书语言风趣幽默又不失严肃严谨.尤其是在The Mythical Man-Month和Calling the Shot两章,诙谐的语句间穿插图表和数据,发人深思. 书中给我印象最深的是Brooks提出这样一条定律.“所有的程序员都是乐观主义者,他们倾向于认为事情会如他们想象的那

成功需要一个好基石 ——读《人月神话》有感

历经了前面的种种困难,才懂得"成功"两字的分量是多么的重,不仅仅是来之不易,更是无法复制的.使得一个项目成功需要很多的因素,俗话说:"好的开始是成功的一半",读了<人月神话>也就明白了怎样让一个项目有一个好的开始.为了呼应主题,我将好的开始称作"基石". 效率高和效率低的 实施者之间具体差距非常大,经常达到了数量级的水平,这也就产生了一个最基本的问题:如何分工?这个问题看似简单,实则包含了人员数量,工作种类.管理结构.任务分配等,每一

读人月神话有感

人月神话书如其名一样震撼人心,它引起了许多别的领域的读者对此进行评价. 律师,医生,社会学家,心里学家,和软件人员一样对此书提出评论和建议.人们经常通过比较计算机软件开发生产率和硬件制造生产率来支持这个观点,后者在 20 年内至少翻了 1000 倍.正像第 16 章所解释的,反常的并不是软件发展得太慢,而是计算机硬件技术以一种与人类历史不相配的方式爆发出来.很多年后作者还是会被道“你现在认为哪些在当时就 是错误的?哪些是现在才过时的?哪些是软件工程领域中新近出现的?”很多年来人们对软件生产率和影

人月神话有感2

关于本书,即使很多没读过的人也能说出其中知名度最高的关于人月神话的观点.之前还在知乎上看过有人举了一个例子:一个人生孩子需要十个月,两个人去生孩子同样需要十个月.这一比喻虽不完全恰当,却也大致说出点内容.事实上,作者在书中这样来描述人月神话:软件开发项目常以人月来衡量工作量,这种度量暗示着人手和时间是可以互换的.这种"人多力量大"的想法是一种一厢情愿的虚妄神话,布鲁克斯法则:向滞后的软件项目追加人手会使得进度更迟缓(Adding manpower to a late software

人月神话有感3

人月神话-这个色彩斑斓的名字,勾起了童年对神话故事热情的回忆,它像一个巧克力甜品一样吸引着人们去品尝.翻开书目,却大吃一惊,它并非是潘多拉的盒子,也不是达摩克利斯之剑.细细品读,人月神话,这个时间和人力的博弈,描绘了工程项目的美丽神话.我想,这个名字也许是作者对于工程化处理我们面临工程项目的渴望. 在读这本书时,我们不妨站在一个项目经理的角度,我们手上有大大小小的项目要完成,我们有大量工程人员或者我们只有几个员工,我们也没有无限的时间和资金设备,面对那些大大小小的项目,面对这些诸多的人力,金钱,