人月神话6

第1章 焦油坑
      焦油坑的意思说明了即使你足够强大,也无法摆脱束搏而沉到坑底。IT项目也是这样,不论是开发大型软件系统还是小型项目,都会遇到诸多复杂的问题和影响因素,项目本身就是一个足够复杂的动态系统,没有最优,只有满意。项目四要素,人员,组织环境,干系人,外部依赖和约束,风险和假设,团队,人等诸多问题都是你必须要考虑的问题,任何一个要素出现大的差错都可能导致项目失败,只有所有要素能够平衡好,团队能够协调一致才能够保证项目成功

第2章 人月神话
      进度问题是IT项目管理最为关注的问题之一,到了第二章人月神话开始讲进度问题。进度的可保证性和可控制性来源于项目计划的科学性,项目计划对进度预测的准确性又来源于估算的准确性,估算是否准确又涉及到项目规模,根据规模可以得到工作量,根据工作量和人力资源的投入和任务依赖约束可以得到最终的进度。当软件产品的规模增加的时候,复杂度成倍增长,从而导致这些要素之间不是单纯的线性关系,这是人月神话的启示之一;同时由于软件项目本身的生命周期模型和工序任务限制,导致对于一定规模的软件产品研发,无论投入多少的资源,都有一个最短工期的限制,在这个最短工期下投入再多的资源也没有用。

第3章 外科手术队伍

  小型敏捷的中小型团队可以保持最高的效率,但对于大型软件系统却不得不投入更多的人力资源来换取进度的提前。对于一个软件产品,在激励的竞争下对进度要求是非常严厉的,往往推迟半年推出都有可能失去竞争和市场,更不用说10年。对于信息化软件产品我们更强调的是迭代和多版本开发概念,每个迭代周期在1-2月左右,每个迭代周期都是真正可以向用户提供完整的可交付的功能。

第4章 贵族专制、民主政治和系统设计
      在这个章里面一个最重要的关键词就是概念完整性,不论你软件项目规模的大小都,不论你采取的软件生命周期方法论,我们都不要忽视了总体架构设计这个过程,而总体设计的一个重点就是概念完整性。概念完整性是系统设计首要考虑的内容,为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。

第5章 画蛇添足
      画蛇添足就过分设计,而书中很明确的指出了过分设计往往出现在设计和开发第二个系统的时候,对于第一个系统他们小心谨慎,倾向于精炼和简洁,但是到了第二个系统他们太想去追求完美,又加上盲目的自信,再加上没有太多的成本和进度等意识,导致了画蛇添足和过分设计。

个人感想:

  对于就决问题,先要理解问题,这一观点我非常赞同,对于我们来说,不了解一个问题又何谈去解决这个问题,所以我们只有了解了这个问题,我们才能更好地去解决问题。对于我们来说团队合作是一个比较尖锐的话题,我们并不知道怎样来进行团队成员之间的合作,而外科手术队伍则给了我们一个学习的目标,让我们知道怎样去进行团队成员之间的合作。对于我们来说,做软件的时候切记不要盲目自信,这会导致我们对于自己做的软件没有正确的预期,对于自己没有一个明确的定位,这对于我们的团队来说是一个致命的问题。

原文地址:https://www.cnblogs.com/x-m-/p/8304239.html

时间: 2024-10-17 21:45:01

人月神话6的相关文章

读<<人月神话>>

这本书在软件领域知名度很高,每次看到年度推荐的文章里面都有这本书且强烈推荐.出版30年了,可谓经典. 但我在读的过程中并没有那么深的体会.书中很多章节都是基于大型项目或者大型系统的经验总结,至今为止我还没有参与大于30人的项目.只能说自己的境界还不够. 第一章,焦油坑 再也找不到一个词比焦油坑更能形容,软件开发的过程了.我们都在挣扎.计划,计划,不断计划,但还是拖延,拖延,拖延.... 职业的乐趣: 创造性,贡献助人为乐,过程的魅力或者解决问题的成就感或写代码的快感,持续学习新事物,驾驭感. 职

《人月神话》读后感

这个学期选择软件冲程这门课我受益匪浅.在这段学习的过程中读完了一本人月神话则是我认为最有价值的经理. 在软件领域中,很少能有像<人月神话>一样具有深远影响力和畅销不衰的著作.作者布鲁克斯被誉为“IBM System/360之父”,他曾是这一系统的项目经理,后来在设计期任360操作系统的项目经理.由于这一工作,他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖.Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师.1999年,他还荣获

人月神话阅读笔记03

阅读了<人月神话>第10章 提纲掣领,里面提到的关于软件相关的开发文档的问题,使我受益颇深.以前每每写程序时,老师总会要求我们写一些需求分析,软件流程图,还有各种各样的日志文档,心里总是觉得烦不胜烦.明明程序已经写好了,文档写不写又有什么关系呢?这不是在浪费时间嘛.但是后来在写四则运算的编程题时,我就遇到了一些麻烦.刚开始我自己写又进行“翻新”的时候,我总是忘了自己之前是怎么想的,思路是怎么样的,很多时候不得不花上许多时间去重新阅读上次的代码,或者直接推翻重写.后来进行二人开发时,发现没有文档

人月神话阅读笔记07

第1章 焦油坑      焦油坑的意思说明了即使你足够强大,也无法摆脱束搏而沉到坑底.IT项目也是这样,不论是开发大型软件系统还是小型项目,都会遇到诸多复杂的问题和影响因素,项目本身就是一个足够复杂的动态系统,没有最优,只有满意.项目四要素,人员,组织环境,干系人,外部依赖和约束,风险和假设,团队,人等诸多问题都是你必须要考虑的问题,任何一个要素出现大的差错都可能导致项目失败,只有所有要素能够平衡好,团队能够协调一致才能够保证项目成功 第2章 人月神话      进度问题是IT项目管理最为关注的

人月神话——我的理解

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

《人月神话》阅读笔记02

今天我读了人月神话—外科手术队伍和巴比伦塔的失败.有许多体会. 在开发小组中,最好和最查人员生产率比在10:1,在运行效率和空间上5:1惊人差距.如果一个200人的项目中,有25个最能干和最有开发经验的项目经理,那么开除剩下的175名程序员,让项目经理来编程开发. 对于一个软件项目,适合的项目团队规模在20人左右,这是一个专职的IT项目经理可以管理的最大值.那由于项目进度压力需要增加团队规模到100人的时候,让项目经理来开发实际操作是很困难的方式,在这里推荐的方式是将系统按照高内聚,松耦合分解为

人月神话读后感

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

人月神话03

这两周我把<人月神话>剩下的章节看完了. “整体部分”这章讲了 我们的构思是有缺陷的,因此总会有bug.但我们可以利用一些方法来减少bug的出现,细致的功能定义.详细的规格说明.规范化的功能描述说明以及这些方法的实施,大大减少了系统中必须查找的bug 数量. 构件的单元测试,单元测试这一概念在这学期学习软件工程课时老师经常提到,作者很有先见性,测试对于发影藏的bug起着很大作用. “祸起萧墙”,本章讲了软件开发的不可与预测性.对计划和控制职能进行适度的技术人力投资是非常值得赞赏的.它对项目的贡

《人月神话》读书笔记之开篇

最近半年尝试带一个小团队,开发一款新产品.写了两年多的代码,现在突然转换了一个角色,面临更多的挑战.现在开始搜集产品用户场景,编写用户和系统需求文档,制定工作计划,安排人员工作,制定目标,跟踪项目成员工作进展. 在这个过程中遇到种种问题,如何建设团队,如何评估工作量,安排人员和时间,如何下发工作,如何跟踪进展,如何识别风险,如何推进项目等. 因为是新产品,公司从稳定安全方面考虑,开始只给了两个应届生,后面陆续给了1一个老员工和3个实习生.我们是一个全新人的团队,我担当的项目负责人和技术决策人两个

也说《人月神话》

 温馨提示:文章的内容与引子无关.       时值深秋,校园里的银杏树, 美的醉人, 一片片优雅的飘落,宛如蝴蝶的狂欢! 图书室中,书籍满架,透出大学那种特有的庄重与浪漫. 图书室里的人一如从前一样, 不多不少, 总是有些人走了, 又有一些人来了. 变化的只是管理图书室的阿姨,双鬓添霜. 我走进一个书架, 挑出了一本最旧的书, 虽然页面泛黄,页脚脱落, 仍然不失“王者”般的威严. 因为书名实在迷人---<人月神话> 某爱慕 小恪的漂亮女生: 小恪, 你在看什么? 这是什么书? 24K纯屌丝小