《人月神话》和个人的一些想法

用了5,6个小时把这本提升逼格的书看完了,收获还是挺大的...

重要名词和主要观点解释

1.焦油坑:形容软件开发的困难和挣扎。软件项目也是这样,不论是开发大型软件系统还是小型项目,都会遇到诸多复杂的问题和影响因素,一个一个淹没在焦油坑中。

2.人月神话:人力和时间不是平衡的线性关系,用人力作为生存率的衡量标准是一个神话。缺乏合理的进度安排是造成项目滞后的最主要原因

3.没有银弹:10年内没有任何编程技巧能给软件生存率带来数量级的提高。

软件开发中困难的部分是规格说明、设计和测试这些概念上的结构,而不是对概念进行表述和对实现逼真程度进行验证

4.软件行业的复杂性导致焦油坑和没有银弹

5.保证概念的完整性和拥有结构师,需要一种无须任何歉意的贵族专制统治

6.规范化的文档,清晰的结构

7.对项目的成功,项目人员的素质,人员的组织和管理比使用的工具和采用的技术更重要。

8.瀑布模式是错误的,采用增量模式。瀑布流假设项目只经历一次过程,而且体系出色易用,设计合理可靠,错误发生在编码实现阶段。

个人目前项目思考

1.比较认同项目需要一个人员来保证系统概念的完整性和架构师,一个系统就需要有自己的规则。不需要每个人都那么有创造力,虽然对个人有好处,但是对项目没有太大的好处。

2.不需要每个人都是全能的,什么都做只会导致项目比较混乱

3.写正规的文档是很有必要的,但是很难实现和贯彻实施。需求真的要澄清,原型设计还是很重要的,不要直接开干。

4.把任务细化,安排好,不要一个人同时启动多个任务,一个任务周期不能拖太长,不然后期很难交付。

希望大家可以把自己在开发过程中的想法描述一下,帮助我们后面更好的完成工作!

时间: 2024-11-05 21:39:37

《人月神话》和个人的一些想法的相关文章

人月神话——我的理解

人月神话中第一章就提到了The Tar Pit ,在焦油坑种挣扎并且体验快乐并苦恼的编程过程,人月神话的开始就在讨论超级项目的合作与分工的矛盾以及内部模块的复杂交织.作者是IBM OS/360项目的项目经理和主要负责人,IBM/360所犯的错误以及给我们的启示成就了这本书,本书的目的是为身处焦油坑里的软件工作人员提供一点帮助和引导.依作者的观点,“人月神话”的出现和工程进度的不合理安排有很大关系,因此合理工程化体系的建立很有必要,盲目的软件生产心理和人员协调中存在的问题导致了软件工业的巨大失败率

《人月神话》有感

<人月神话>内容源于作者Brooks在IBM公司任System计算机系列以及其庞大的软件系统OS项目经理时的实践经验. Brooks最为一名项目经理写下了这本 <人月神话>,我觉得作为以编程为混饭吃的将来的It工种,很有必要去读一读这本书.Brooks详尽的借助了自己工作上的经验来为别人介绍了项目经理在一个项目上应当作的必要的事情:首先,必须要了解客户需要的是什么,要有什么样的功能:然后,还要了解成员之中能做到什么,对代码能够实现的功能必须了如指掌:最后要有详细的进程安排. 项目成

《人月神话》阅读笔记

一开始听到这个书名时,我的第一反应是人月神话?神话故事?嫦娥?吴刚?和玉兔?然后在有了大概的了解之后我有了阅读的兴 趣,而且一开始我看这本书时都是怀着非常崇拜的心情来拜读的,要知道一本1975完成的书,在多年后又开始流行,那必然是有他非 常成功的地方的.  作者布鲁克斯在书中为人们管理复杂项目提供了独到的见解,从自己的管理经验中总结,在网上也看到很多人拜读后的自己的见解 以及感受,可能是我水比较浅,所以我的理解可能不是太正确,但这就是我看完这书之后的感受...也许是最近一直在准备团队项 目所以在

读《人月神话》之感受

中国科学技术大学软件      朱秀秀           原创作品转载请注明出处 自暑假以来,就认识到这本书几乎成了软件行业不可或缺的一碗鸡汤,不过在我刚一看到“神话”两个字,两眼顿时放光,觉得闲暇之余还可以看看神话之类的小说,煞是惬意,可是暑假档期排得实在是不能再满了,于是乎,决定开学之后再看吧. 暑假的课程紧锣密鼓的进行着,一天,两天....只能说从来没有如此充实的度过长达一个月的起早贪黑的学习生活,好在这段难忘的时间终究还是离我而去,几场考试过后,向往已久的研究生生活开始了. 于是在老师

人月神话读后感(三)

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

《人月神话》读书笔记 第1篇

<人月神话>读书笔记 第1篇 第1章:焦油坑 第2章:人月神话 第3章:外科手术队伍 第4章:贵族专制.民主政治和系统设计 第5章:画蛇添足 第6章:贯彻执行 第7章:为什么巴比伦塔会失败 第8章:胸有成竹 继<梦断代码>之后,我又选了一本老师推荐的关于软件工程的书——<人月神话>,这本书读起来相对<梦断代码>就轻松多了,可能是翻译得较为通俗,并且每章前都有个寓言或者名句作为引子.并且举了相似的例子来说明,同样也列出了对立的情况来证实一些道理. 开篇书中提到

人月神话读后感三

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

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

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

《人月神话》读后感----一到三章

<人月神话>这本书是我们老师推荐给我们的,同时老师还推荐给我们另一本书<梦断代码>.由于时间的原因,我只能先选一本书来读. 这本书里面的好多观点,对于今天的软件工程依然适用.如"没有银弹"这个观点,说明了作者对于软件工程独到的见解.身为一名软件工程的学生,我应当仔细读完关于 软件工程的任何一本书.并将观点与想法运用到实际之中. 作者在第一章中说到,过去几十年大型系统的开发就像焦油坑一样,虽然各种各样的团队通过努力开发出可运行的系统,但是只有少数的项目可以开发出满