染雾人月神话的读后感 篇一
《人月神话》这本书是一本关于软件工程的经典著作，作者是软件工程领域的大师弗雷德里克·布鲁克斯。在阅读完《人月神话》后，我对软件开发的理解有了更深入的认识。
书中作者通过自己多年的实践经验，深入浅出地介绍了软件开发中的各种问题和挑战。其中最为重要的观点就是“人月不可测”。这个观点指出，增加人力资源并不能缩短项目的时间，反而可能导致项目进度的延误。这是因为在软件开发中，人员之间的沟通和协作是非常重要的，而增加人力资源会增加沟通的成本和复杂性，从而影响项目的进度。
在我过去的工作经验中，我也曾遇到过类似的情况。有一次我们项目组为了赶进度，决定增加了一些临时人员。然而，由于这些临时人员对项目的整体架构和设计不了解，导致他们的工作成果无法和我们原有团队的工作进行有效的对接，最终反而拖慢了整个项目的进度。这个经历让我深刻地认识到了布鲁克斯在书中所阐述的观点的正确性。
此外，《人月神话》还介绍了软件开发中的其他重要概念和原则，如模块化、原型开发、软件工程师的个人生产率等等。这些概念和原则对于提高软件开发的效率和质量非常重要。通过这本书，我学到了如何在软件开发中合理地划分模块、如何运用原型开发方法来验证需求、如何提高个人的工作效率等等。这些对我来说是非常宝贵的经验。
总的来说，阅读《人月神话》给我带来了很多启发和思考。它帮助我更好地理解了软件开发的本质和挑战，让我认识到了在软件开发中需要注意的问题和原则。我相信这些知识和经验对于我的职业发展将会起到积极的作用。
人月神话的读后感 篇二
《人月神话》这本书是一本关于软件工程的经典著作，作者是软件工程领域的大师弗雷德里克·布鲁克斯。在阅读完《人月神话》后，我对软件开发的管理和团队协作有了更深入的理解。
书中作者通过自己多年的实践经验，深入浅出地介绍了软件开发中的各种问题和挑战，尤其是在管理和团队协作方面。作者提到了软件工程师的个人生产率和团队协作的重要性。他指出，软件开发是一项复杂的工作，需要工程师们充分发挥个人的能力和创造力，同时也需要他们与团队成员进行良好的协作和沟通。
在我过去的工作经验中，我也曾遇到过管理和团队协作的问题。有一次我们项目组在开发过程中出现了一些分歧，导致团队的合作氛围受到了影响。通过阅读《人月神话》，我明白了这种情况背后的原因，并学到了如何处理和解决类似的问题。作者在书中提到了一些管理和团队协作的技巧和原则，如明确的沟通、清晰的目标设定、有效的决策等等。这些技巧和原则对于提高团队的效率和凝聚力非常重要。
此外，《人月神话》还介绍了软件开发中的其他重要概念和原则，如模块化、原型开发、软件质量保证等等。这些概念和原则对于提高软件开发的效率和质量也起到了重要的作用。通过这本书，我学到了如何合理地划分模块、如何运用原型开发方法来验证需求、如何进行软件质量保证等等。这些知识和经验对于我在软件开发的工作中将会非常有用。
总的来说，阅读《人月神话》给我带来了很多关于软件开发管理和团队协作方面的思考。它帮助我更好地理解了软件开发的管理和团队协作的重要性，让我认识到了在软件开发中需要注意的问题和原则。我相信这些知识和经验对于我的职业发展将会起到积极的作用。
人月神话的读后感 篇三
人月神话的读后感
当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。
把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。
1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。
概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的'Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。
2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。
组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不都难亚。
3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。()
以前，增加人手基本
如果不想加班，不想削减功能，不想推迟发布日期，那么……唯一的方法还是只有…加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。
感触还有很多，以后如果有机会再写。不过，我决定去买本英文版回来，收藏，以后再多看几次。
