人月神话第一篇阅读笔记

  我先通读了全本书,对整书的大概内容进行了了解。第一遍的阅读中我知道了许多。软件开发的多少人参与和完成时间不成正比的,过多的人参与并不一定能缩短开发时间。如战争,部队多,人多并不是关键,更多需要武器的先进,战术,兵多后方便的补给就得多。如是参与软件开发的人增加,软件的花费将提高,参加这需要时间了解项目,给软件管理带来了不协调。

人月神话的核心法则是:概念完整性和架构师。Brooks认为,一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了实验应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师,则是负责保证产品所有方面的概念完整性的,架构师设计的是能够让用户理解产品概念的模型,这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。

概念完整性将软件开发连成了一条钻石项链,每个部分都不可忽视,不可取代。整体的抽象完整时软件管理的灵魂。正因为如此,可见架构师的要性。因此另一方面把工作切分给更多人做将造成额外的沟通代价——训练和相互的交流。欲增加软件项目的人手,总共必须付出的代价可分为三方面:工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流。

编程过程中不是人多就可以胜任的。而在于精。所以团队中个体的能力就尤为重要。原来我以为只要团队中有大神,软件的开发就可以顺利完成了,其实并非如此,每个人都有自己独特的任务等待去完成。

时间: 2024-12-09 21:24:03

人月神话第一篇阅读笔记的相关文章

第一篇阅读笔记

编写有效用例,首先要清楚用例是什么.用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约,描述了在不同条件下,系统对某一项目相关人员的请求所做出的响应.一个好的用例很容易阅读,但是要写出一个好的用例很不容易.而且用例不是要写的多正式.完整.漂亮,而是尽可能得充分,就足够了.还有在书写用例之前最好弄清楚客户真正需求是什么?是安全,还是使用等,弄清楚客户的真正的需求有助于自己尽可能的写出满足客户并且足够充分的用例,还能增加客户对你的信任感.我一直认为信任感是与他人沟通最重要的.  用例编写的

大道至简第一篇阅读笔记

编程的精义1.顺序.分支和循环.庞大若“愚公移山”这样的工程,都是可以通过这样简单的编程来实现的.这,就是编程的精义了.2.除了先天智障或后天懒惰者,都是可以学会写程序的.3.编程的第一要务是先把事情分析清楚,事件先后的逻辑关系和依赖关系搞清楚,然后再去代码实现.4.记住:积极工作和勤于思考都要占时间.5.只要开发人员将这个程序的算法设计出来了,把结构描述出来了,那么程序就已经定型了.剩下的事,简而言之,就是劳力活.6.通常而言,语言的差别主要表现在适用范围上.是懒人造就了方法7.人的精力终归是

构建之法第一篇阅读笔记

程序=算法+数据结构这句话我估计应该深入每个计算机系学生的心里了,但是就像书中所说的一样除了上数据结构课程我们没有用过任何与数据结构有关的东西,难道老师讲的都是错的吗?构建之法给了我明确的答案,这都是我们就业后所要面临的问题,因此,软件工程概论这门课就显得尤为重要了,它可以帮助我们了解软件工程整体结构,了解其中的各个流程,使我们能够了解到我们今后将会遇到的问题,提前让我们熟悉这个行业,意识到自身所学真正的作用. 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.它包含

人月神话第一章焦油坑

职业的乐趣: 不断学习的乐趣 创建事物的乐趣 开发对他人有用的东西 在易于驾驭的介质上,进行开发 职业的苦恼: 将做事的方式往完美的方向调整. 往小的说:1.依赖其他人的代码 2. 当产品终于出来时,已经过时了. 程序距离编程系统铲平还有很长的一段距离.

《人月神话》有感

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

人月神话感想

人月神话感想 在阅读这本书之前,已经很多次听到关于人月神话这本书以及他的作者Brooks的消息了. 在软件领域, <人月神话>具有深远影响力而且畅销不衰.这一次,正好老师的作业要求我们阅读这本书,我终于使有机会阅读这本经典之作了.在这过去的几个星期里面,一点一滴的阅读这本书,粗略的了解了这本书. 首先,让我印象深刻的是<人月神话>提出的两条著名的法则: 1.人月神话:向一个已经延后的项目中投入更多的人力资源只会让它更延后. 人月神话看上去这么浪漫的名字,原来并不是真的说神话故事,作

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

<人月神话>读书笔记 第3篇 第15章:另一面 第16章:没有银弹 第17章:再论“没有银弹” 第18章:<人月神话>:是与非? 阅读<人月神话>马上就要接近尾声了,发现后面讲的内容越来越专业,但是对于我们正在进行的团队合作启发很大.前几天老师在课堂上给他们看了他统计整理的个人与每个团队第一个冲刺阶段的进度表格,看到有些严格按照要求每天有进度,有些则相反,也可能是完成了但是没有及时汇报进程.那“项目怎么会被延迟了?……延迟的时间是一天一天积累下来的.”目前我们做的都是一

《人月神话》阅读笔记01

我第一次看到<人月神话>时,就觉得这个书名挺有意思,根本想不到这本书和软件工程扯上半毛钱关系.后来,才知道:所谓的人月(man-month)是指软件的工作量.如果一个软件要一个人六个月的工作量,就叫6man-month.书中第一篇张开头是焦油坑(The Tar Pit)岸上的船儿,如同海上的灯塔,无法移动. - 荷兰谚语 Een schip op het strand is een baken in zee. [A ship on the beach is a lighthouse to th

《人月神话》阅读笔记

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