鉴于本书的每一章都是一篇相对独立的散文，下面对它的每一章进行总结，即“一句话读后感”。

Chap1. 焦油坑

编程系统产品的成本数倍于编程本身；编程这样一个行业给人以创造、动手与控制的乐趣，但是，对沟通的依赖、对完美的追求也是编程所令人苦恼的一面。

Chap.2 人月神话

“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本；Brook法则：向进度落后的项目中添加人手，只会使进度更加落后。 Chap.3 外科手术队伍

程序员在生产率上甚至可以达到数量级的差异；专业的、分工良好的小规模团队的生产率更高，在这种架构下，决策的集中性也保证了概念的一致性。

Chap.4 贵族专制、民主政治和系统设计

概念的完整性最应该被重视，它带来产品的简洁和易懂；因此，系统的体系结构设计应由少数人来完成，即系统设计师专制；但系统设计师应该严守底线，避免干涉外部特征之外的实现细节。 Chap.5 画蛇添足

在第一版设计中，设计师往往能保证精炼简洁；但在第二版设计时，画蛇添足是常见的问题，设计师容易被诱惑着开发过多的功能，这是应该被避免的。

Chap.6 贯彻执行

对产品的文档化规格说明是必要的，它应该用清楚的形式化定义表达；开发人员之间应该定期有不同层次（大会、组例会、电话）的交流，并对交流进行记录、整理和思考；开发人员应坚守手册，尤其在有多重实现时；大型项目中的测试小组对确保用户体验十分重要。 Chap.7 为什么巴别塔会失败

巴别塔有着清晰的目标、充足的人力、材料、技术和时间，但是巴别塔的建造人员缺乏沟通；大型软件工程应有不同层次的沟通，并用项目工作手册规定定义接口与划分以减少交流所需的工作量；软件工程的组织结构应采取树形结构，以保证有效的沟通。

Chap.8 胸有成竹

本章将对生产率的估计，工作量 = 常数×指令数目1.5，本章还总结了一些软件工程中一些对生产率进行估计的技术。

Chap.9 削足适履

程序空间也是与时间一样的成本，程序规模应该为预算所控制；空间与时间可以进行一定的折中，但好的数据处理方式是可以在两方面同时进行优化的。

Chap.10 提纲挈领

软件项目经理应该编写一系列关键的文档，它们反映了对目标、技术特征、进度、预算和组织结构的管理；它们不仅仅是检查列表和控制手段，它也是沟通渠道和汇报材料。

Chap.11 未雨绸缪

第一次开发的系统应该准备好要抛弃，因为变化不可避免，要对此计划好系统与组织架构的变化；缺陷修复会引入新的BUG，而且到了最后必然会不能再进行改进。

Chap.12 干将莫邪

工具的安排：软件将最终在之上运行的目标机和开发辅助机，目标机应该被规划使用，辅助机上应该运行可靠的仿真器、解释器和程序库文档。

Chap.13 整体部分

概念完整性与产品精确定义是关键的；结构化编程是必要的；构件应该进行单独的测试，之后再进行集成测试；修改时应控制变更规模。

Chap.14 祸起萧墙

里程碑应该明确定义以防止产生隐瞒；使用PERT图指示对进取的需要；老板不应与一线经理产生角色冲突，而应使用能了解状态真相的评审机制，计划和控制小组在这一过程中很有价值。 Chap.15 另外一面

用户需要文档来帮助他们使用（目的、环境、IO范围、功能算法、指令、选项、运行时间和精度检验）、验证和修改程序；流程图的使用与维护都很麻烦，已经过时；自文档化技术是一种非常有效的解决方案。

Chap.16 没有银弹

软件开发所不可规避的困难在于复杂度、一致性、可变性和不可见性；尽管高级语言、分时系统、IDE在编码过程中帮了程序员的大忙，但他们无助于解决内在困难；高级编程语言、面向对象技术、人工智能、专家系统、自动编程、图形化编程和更快的工作站都无助于问题的根本部分；有希望缓解根本问题的是：购买软件、快速原型技术、增量开发和卓越的设计人员。

第二篇：人月神话读后感20xx字

读《人与神话》有感

翻开《人月神话》这本书的第一感受，感觉看这本书不像是在看一本和我们学的相关的书，书中用了很多的形象的比喻，来阐述项目管理中的一些问题，让人以很轻松愉悦心态去阅读。书开始就形象有有趣的把软件危机比作：焦油坑。史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎...让我感觉到，软件开发过的过程中，会有很多困难，很多的挑战。

看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书 已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有 很多发人深省的观点，也有大量的软件工程实践。大型编程项目深受由于人力划 分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。 《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。

的在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。全书的第二章说的就是人月神话的关系。“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。在我们实际进行软件开发的时候，各个成员之间要做好沟通协调，一个人开发软件虽然完整性会很好，但是效率太低；相反，团队开发虽然效率很高速度很快，但是如果各个成员之前没有很好地团结协作，各自为战，那么最后的结果也一定不会尽如人意。

书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容

涉及到了团队，人和沟通。对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。

开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。

一个软件的好坏不是说是由一个程序员决定的，往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。一个小小的bug，也许就需要好几个部门的分工协作。原著中说，软件系统也是人类创造的错综复杂的事物。所以只有在一个团队的沟通了解，通力协作和努力之下，才能做出更加完善的软件作品！