人月神话-云图

封面

简介

我自己的结论体现在下面的文字中,送给职业程序员、职业经理、特别是程序员的职业经理。
虽然写出来的是分离的章节, 还是有一个中心的论点, 特别包含在第 2-7 章。 简言之,我相信由于人员的分工,编程项目碰到的管理问题和小项目区别很大; 我相信关键需要是维持产品自身的概念完整性。 这些章节探讨了其中的困难和解决的方法。 后续的章节探讨软件工程管理的其他方面。

云图

原文地址:https://www.cnblogs.com/LearnFromNow/p/9348400.html

时间: 2024-10-18 17:54:46

人月神话-云图的相关文章

读<<人月神话>>

这本书在软件领域知名度很高,每次看到年度推荐的文章里面都有这本书且强烈推荐.出版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个实习生.我们是一个全新人的团队,我担当的项目负责人和技术决策人两个