人月神话-读后感3

第五章 画蛇添足

普遍倾向: 过分设计第二个系统,向系统添加很多修饰功能和想法, 如:OS 360。

但开发第二个系统与纯粹的功能修饰和增强明显不同,也就是说存在对某些技术进行细化、精炼的趋势。由于基本系统设想发生了变化,这些技术已经显得落后。

结构师如何避免画蛇添足——开发第二个系统所引起的后果? 他无法跳过二次系统,但他可以有意识关注那些系统的特殊危险,运用特别的自我约束准则,来避免那些功能上的修饰;根据系统基本理念及目的变更,舍弃一些功能。

项目经理如何避免画蛇添足(second-system effect)?他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时,保持对特殊诱惑的警觉,他可以不断提出正确的问题,确保原则上的概念和目标在详细设计中得到完整的体现。

第六章 贯彻执行

  • 文档化的规格说明——手册
  • 形式化定义
  • 直接整合
  • 会议和大会
  • 多重实现
  • 电话日志
  • 产品测试

第七章 为什么巴比伦塔会失败

失败原因: 两个方面——交流,以及交流的结果——组织。

团队之间如何进行相互之间的交流沟通呢?

  • 非正式途径      电话
  • 会议
  • 工作手册

项目工作手册

  1. 是什么?   项目工作手册不是独立的一篇文档,它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分。
  2. 为什么?
    • 技术说明是必不可少的。
    • 控制信息发布。 确保信息能到达所有需要它的人的手中。

大型编程项目的组织架构

团队组织的目的是减少不必要交流和合作的数量,因此良好的团队组织是解决上述交流问题的关键措施。

减少交流的方法:  人力划分和限定职责范围  ——树状管理结构

每棵子树所必须具备的基本要素:

产品负责人与技术主管之间的关系:

  1. 产品负责人和技术主管是同一个人    很小型的队伍(三个或六个开发人员)
  2. 产品负责人作为总指挥,技术主管充当其左右手   前者必须支持后者的技术决定,注意体现技术主管的威信(很少被应用)
  3. 技术主管作为总指挥,产品负责人充当其左右手  (对小型的团队是最好的安排,而对于真正大型项目的一些开发队伍,笔者认为产品负责人作为管理者是更合适的安排。)

第九章 削足适履

规模是软件系统产品用户成本中很大的一个组成部分,开发人员必须设置规模的目标,控制规模,考虑减小规模的方法。同任何开销一样,规模本身不是坏事,但不必要的规模是不可取的。

规模控制

OS/360 给我们的道理 :

  1. 和制定驻留空间预算一样,应该制定总体规模的预算;和制定规模预算一样,应该制定后台存储访问的预算。
  2. 在指明模块有多大的同时,确切定义模块的功能(防止程序员在规模上遇到问题就把其中的一部分扔给别人,影响系统的稳定和安全性)
  3. 项目规模本身很大,缺乏管理和沟通,此时系统结构师必须保持持续的警觉,确保连贯的系统完整性。同时,培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员的最重要的职能。

空间技能

用功能交换尺寸

空间——时间的折衷:(项目经理)

1. 确保他们在编程技能上得到培训,而不仅仅是依赖他们自己掌握的知识和先前的经验

  1. 认识到编程需要技术积累,需要开发很多公告单元构件。

数据的表现形式是编程的根本。缺乏空间时,不妨从代码中挣脱出来,回顾、分析实际情况,仔细考虑程序的数据。

第十章 提纲挈领

计算机产品的文档: 目标,技术说明,进度、时间表,预算,组织机构图,工作空间的分配,报价、预测、价格

大学科系的文档:目标,课程描述,学位要求,研究报告,课程表和课程的安排,预算,教师分配,教师和研究生助手的分配

通过对比,我们可以得出,任何管理任务的关注焦点都是时间、地点、人物、做什么、资金

软件项目的文档:

  • 时间:进度表
  • 地点:工作空间分配
  • 人物:组织图
  • 做什么: 目标;产品技术说明书
  • 资金:预算

为什么要有正式的文档?

  1. 书面记录决策是必要的
  2. 文档能够作为同其他人的沟通渠道
  3. 项目经理的文档可以作为数据基础和检查列表

第十一章 未雨绸缪

实验性的系统必须被构建和丢弃,变化是与生俱来的,具有变更思想的重新设计是不可避免的。因此,我们需要为变更而设计系统,其中最重要的措施是使用高级语言和自文档技术,以减少变更引起的错误。同时,变更的阶段化是一种必要的技术,每个产品都应该有数字版本号,每个版本都应该有自己的日程表和冻结日期,在此之后的变更属于下一个版本的范畴。除此之外,我们还需要为变更计划组织架构。

第十三章 整体部分

我们可以通过编写测试规格说明和进行自顶向下的设计,结构化编程等方式来减少bug的数量。

构建单元调试的四个步骤:本机调试,内存转储,快照和交互式调试。

进行了单元调试后,我们再对系统进行集成测试。集成测试的内容包含:使用经过调试后的构建单元,搭建充分的测试平台,控制变更,一次添加一个构件,阶段(量子)化、定期变更

原文地址:https://www.cnblogs.com/123456www/p/10989098.html

时间: 2024-10-03 22:55:19

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

【最后的总结】人月神话读后感

人月神话读后感 这本300多页(中文新版)的神书,在经过了20多年的历史之后,仍然畅销不衰,究竟是什么让它有如此的魅力?过去的一个月,一点一滴的阅读之中算是初步的了解到了它的一部分吧. 人月神话的核心观点:概念完整性和架构师 Brooks认为,一个整洁.优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了应用,实现应用的方法以及用来指明操作和各种参数的用户界面使用策略.概念的完整性是易用性中最重要的因素.而架构师,则是负责保证产品所有方面的概念完整性的,架构师设计的是能够让

人月神话读后感

书中应用焦油坑表示过去几十年的大型系统开发,很多大型和强壮的动物在其中剧烈挣扎.让我感觉到,软件开发过程中所遇到困难是多么的多,开发多么艰难.但是这本书同时告诉了我们软件的开发有苦也有乐,我们可以在编程过程中体会那份快乐.<人月神话>是为软件开发经验的天马行空总结.比<Beautiful code>更为有远见,把我从充实代码的清晰简介升华,拓展到软件开发的高层度, 一个周密,准确,明朗的开发需求分析,可行性研究,软件实现是软件开发的完美递进. 人与神话中讲述人力和时间并不体现线性关

人月神话读后感2

<人月神话>是为软件开发经验的天马行空总结.比<Beautiful code>更为有远见,把我从充实代码的清晰简介升华,拓展到软件开发的高层度, 一个周密,准确,明朗的开发需求分析,可行性研究,软件实现是软件开发的完美递进. 人与神话中讲述人力和时间并不体现线性关系.指出以大量人员和较短的时间,并不能缩短软件的开发进度.一窝蜂的作业方式无助于软件生产,且会制造麻烦,产生出更差的软件.向进度落后的项目追加人力,只会使进度更加落后.所有的编程人员都应该是乐观主义.人数和时间的呼唤仅仅适

人月神话读后感(三)

作为软件工程的经典著作,<人月神话>的主要贡献是对软件开发过程的几个重要关键点,提出了独到的见解. 其中内容就是: (1)提倡外科手术式的团队组织: 在软件开发组织上的过份民主,往往带来的是没有效率和责任,参与其中的人想法太多,层面参差不齐.所以,软件开发的组织,应该借鉴外科手术式的团队方式,有一个主要的负责人,其他人都是分工协作的副手,这样效率最好,结果最好.(2)软件项目的核心概念要由很少的人来完成,以保证 概念的完整性: 少就是多,项目的定位需要和功能多少的权衡.太多的想法,使项目没有焦

人月神话读后感三

人月神话阅读笔记之三 之前从来没有注重过文档的重要性,想起啥就写啥,从来没有整理过思绪和想法就是想写啥写啥,不会在乎太多的问题. 但是看完这本书以后就明白了很多,这样的做法是很错误的一种行为,作者强调文档的重要性,他曾经很勤奋的向软件工程师们讲述文档的必要性以及优秀文档所具有的特点方面的讲座.但是效果都非常的的不好,他们知道如何来写出优秀的文档,但是他们缺乏热情.所以作者采用向马车搬收银机的方法向他们展示如何来完成这项工作.结果显示这种方法的效果还是挺好的. 以后写程序一定要先写好文档,要不自己

人月神话-读后感2

文章主要讲了在软件开发工程项目中,时间和人员数量上的转化关系.表明了在一个项目中增加人员的数量不一定能够缩短项目完成的时间,很多时候还会起到相反的作用.正如Brooks法则中所说的那样“想进度落后的项目中增加人手,只会使进度更加落后”. 在软件项目中,缺乏合理的时间进度使造成项目滞后的最主要的原因.造成这个结果主要由于以下几个方面,包括我们对工程的乐观的估计,错误的认为人和月(时间)可以无条件的相互替代,软件经理不合理的估算和缺少对进度的跟踪和监督. 在编程人员中弥漫着乐观主义,他们通常会认为一

人月神话 读后感(1)

在软件领域,很少能有像<人月神话>一样具有深远影响力和畅销不衰的著作.这本书可以称得上是软件行业的圣经,因此我怀着好奇的心态翻阅这本书. 一下是我对文章内容的摘抄与一些自己的理解. 第一章焦油坑 讲的是一入软件这个行业好似掉入焦油坑,快乐与烦恼并存.编程行业为什么有趣,因为它不仅满足了我们内心深处进行创造的渴望,而且唤醒了每个人内心的情感,软件的乐趣便在于他独一无二的创造性,在与创造出对其他人有用的产品那种满足感. 当然烦恼是过程很枯燥,遇到bug时寻找和修改的过程充满了枯燥.这就是编程,一个

人月神话读后感03

“四套马车”讲团队配合.书中所讲是常见的小规模的软件开发公司的情况,如何合理的分配各项任务使得开发工作顺利的完成对这些小公司来说确实是问题.但对于目前我所在的公司,暂时不存在这样的问题.毕竟部门的规模还是有的,70人,任务也单一,只是软件测试,除了有时任务较多显得有点忙以外,基本上还是能应付的过来.但是其中提到一些问题和建议还是可以用到的. 比如书中提到使用专业和高级的工具未必就能提高工作效率和质量,这一点对我有很大的惊醒作用.我往常还是很迷信这些一些好的工具和好的制度,以为有了这些,整个流程,

人月神话读后感(一)

感受一,软件编程职业的乐与苦 如文中所说,编程的乐趣在于创造事物,如小孩玩泥巴一样,创造出了自己的东西,这种魔术般的,上帝一般的感觉确实吸引着我,从无到有,从最开始的构思到一步一步的逐渐实现并完善一个项目,最后得出能用的东西,这种成就感是令人满足的,但是任何事物有乐就有苦,编程也是如此,我目前所直接感受到的就是在编码过程中无限的BUG需要去解决,解决-测试,测试-解决,用以完善自己的思路,这种过程是比较乏味,枯燥的,但却是,说心底话,只有多经历这种过程,多去见识那些BUG,并且努力去解决他们,这

人月神话读后感(二)

感受一,一个项目概念的完整性非常重要 概念上统一的系统能更快地开发和测试,为了实现这个目标,设计必须由一个人或者具有共识的小型团队来完成. 一个团队必须保持概念的完整性,才能使团队高效的运作,方向一致. 感受二,交流对项目开发起着至关重要的作用 巴比伦塔项目的失败是因为缺乏交流,以及交流的结果--组织 在本书中,多次提到了要非常多的进行交流,在他开发的System360中,有很多交流的方式,有每周一次的汇报会议,到每月一次的大会,还有不断修订的项目工作手册 ,以及实现人员随时可以像结构设计人员询