标签：
《人月神话》读后感
还没读这本书时怎么也不能把这名字与软件工程联系到一起，总感觉人月神话更像一部神话故事或者还联想到一些关于航天的东西，终于在假期开始了对这本书的研读，也慢慢被书本的内容所折服。在读这本书的期间通过读《软件工程——理论、方法与实践》才知道人月是软件开发中的单位。没读前就听说它是软件开发人员必读书，是软件界的神话，读完后让我深有感受，虽然我还没有真正的从事到软件开发的行业当中，作为一个学生我对书中的主要思想可能不会理解的十分全面，书中主要阐述的是软件开发项目上项目进度和增加人员不能互换，书中的好些观点给了我很大的帮助。
人月神话这本书在软件危机中的很多问题中探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面，提出了许多很实用的观点，本书中既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见。
书的开始就形象的把软件危机比作焦油坑，形象的表达了软件开发过程中的诸多困难，也写出了这些困难解决起来是多么的艰难。随着书的进行每一章都阐述了十分实用的观点，人月神话这部分讲述人力和时间并不体现线性关系。指出以大量人员和较短的时间，并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产，且会制造麻烦，产生出更差的软件。向进度落后的项目追加人力，只会使进度更加落后。因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。书其中有内容提到：外科手术团队。在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。两人团队，其中一人当领导者，这通常是最佳的用人方式。以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示，使用一堆人蛮干的方式最耗成本、最慢、最没有效率，做出来的系统在概念上也最不完整。《人月神话》的第二系统效应就一个人所做过的设计而言，第二个系统是最危险的系统，一般来说，都倾向于过度设计。 当他做第三或之后的系统时，之前的经验会互相印证，以确认出这类系统的一般性特色，而系统彼此之间的不同处，也会帮助他辨别出属于特殊和非通用的部份。除了做些功能上的修饰之外，第二系统效应还有另外一项特征，那就是倾向于将之前已熟悉的技术发挥到淋漓尽致，但却没有留意到，这项技术早就跟目前项目的基本系统假设有冲突而不再适用。
书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容涉及到了团队，人和沟通。对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。
开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于我们大学生，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
书中有太多对我们有很大启发的内容，无论是已经开始工作还是正在上学，书中的观点对我们这些与软件开发打交道的人们有太多的帮助，它让我们在软件开发过程中少走了太多弯路，它给我们的启发让我们可以在软件开发中更加的有效率。
标签：
原文地址：http://www.cnblogs.com/lingxi/p/4304463.html
