老师推荐了这本书人月神话，刚开始以为是一本小说，后来阅读之后才发现自己想错了，人月是指在估计和进度安排中使用的工作量单位。
作者在书中介绍了焦油坑的概念，提出在过去几十年的大型系统开发就犹如一个焦油坑。各种团队，大型的、小型的，庞杂的和精干的，一个接一个淹没在焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累计在一起的时候，团队的行动就会变得越来越慢。
作者从编程系统产品、职业的乐趣和职业的苦恼方面让我们认识了软件开发这个职业以及充满在这个职业中的乐趣与 苦恼。简单的程序已经不能称作系统，编程系统和编程产品称为编程系统产品。它的成本高达九倍。只有编程系统产品才是真正有用的产品，是大多数系统开发的目标。乐趣是任何职业都不能缺少的，只有有了乐趣才会有动力，才会有创造力。虽然现在我们对于软件开发没有很清楚的概念，但是我们也应该充满一种好奇心和一种乐趣，体会其中魔术般的力量。苦恼是必不可少的，我们应正确看待这些烦恼。
作为一名软件工程的学生，我们虽然编的软件不多，但是也有一些自己的理解，我们享受编程的乐趣，享受成功的喜悦，但同时也有苦恼，查不出bug,想不到方法，都是我们的苦恼。
Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。
进度问题是项目管理最为关注的问题。项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要的原因。文章分析了几个原因。乐观主义：所有的编程人员都是乐观主义。人月：用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。系统测试：在早期进度策划时，允许充分的系统测试时间是非常重要的。空泛的估算。重复产生的灾难。
通过此部分，我看到了在软件开发中会出现的一系列问题。这些问题发现了，我们就应该时刻注意，及时解决。而不应该拖拖拉拉。
在软件开发过程中，小组之间要有明确的分工。由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。小组成员之间要进行及时的沟通。
作者认为概念完整性应该是最重要的考虑因素。概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。不能与系统基本概念进行整合的良好想法和特色，最好放到一边，不予考虑。在外部说明完成之前，设计实现人员有很多事情可以做。只要有一些最终将并入外部说明的系统功能雏形，他就可以开始了。文中简要说明了设计实现人员的工作流程，给我们以后学习工作提供了一个向导。
开发第二个系统所引起的后果。项目经理必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现，以避免画蛇添足。
假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保每个人听从、理解并实现结构师的决策？对于一个由1000人开发的系统，一个10个结构师的小组如何保持系统概念上的完整性？要有文档化的规格说明—手册，形式化定义，直接整合，会议和大会，多重实现，电话日志，产品测试，这些内容在《软件工程概论》中也有相关的介绍。
交流的至关重要。团队之间要通过所有可能的途径进行相互之间的交流沟通。交流和交流的结果—组织，是成功的关键。交流和组织的技能需呀管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？作者对几个数据进行了分析，我们应从数据中学习，在实践中总结，做到胸有成竹，这样才会提高效率和生产力。
作为成本的程序空间：由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法。规模控制。空间技能。数据的表现形式是编程的根本。在软件开发中，我们要尽量减小规模，减少成本，扩大空间。
文档是很好的工具。书面计划是精确和可以沟通的。平时学习中，我们并不重视文档的书写，看完这张，意识到了文档的重要性，以后要加强文档的规范化。
文档。虽然太多的书籍都强调文档的重要性，但是在实际操作中它又发挥了多大的作用呢！书中提到流程图，流程图的使用本来应该在开发前画，但是很多流程图都是在开发结束后需要文档才画上的。这样做也许会对维护人员有帮助，但是维护人员真的会看吗？我觉得有少部分关键文档的确非常重要，大部分文档只是为写文档而写。
人月神话为什么能畅销30年。的确如书中所说，其实他只是以某个项目为起点来展开软件工程的实际开发中的原理。大学的教科书：软件工程，计算机原理，编译原理等书籍都至少采用了10年，而其他的java语言等只是这2年才开课的。计算机技术的确变化很快，某些原理却并没有发生大的变化。
总之，一句话，这本书让我对软件工程有了全新的认识。