人月神话读后感

Posted 2023-05-29 liyiyang

《人月神话》是一本探讨软件工程管理的经典书籍，它揭示了软件开发中的一些常见的误区和问题，并提出了一些有益的原则和方法。作者从多个角度分析了影响软件开发效率和质量的因素，如项目规模、时间、人员、沟通、设计、测试等，并提出了一些实用的建议和技巧。

我认为这本书对于软件开发者和管理者都有很大的启发和价值。它让我明白了软件开发不仅仅是一个技术问题，更是一个管理问题。软件开发是一种复杂的人类活动，需要高度的智力、创造力和协作能力。因此，管理者应该避免一些错误的假设和做法，如认为人月可以互换，认为增加人手或加班可以提高进度，认为软件开发可以按照固定的计划和流程进行等。这些假设和做法往往会导致项目的延期、超支、质量低下或失败。

我也从这本书中学到了一些软件开发的原则和技巧，比如如何制定合理的项目计划和交付期限，如何有效地沟通和协调，如何避免和解决冲突和问题，如何保持团队的凝聚力和自信心，如何鼓励和支持创新等。这些对于我提升自己的专业水平和团队合作能力都有很大的帮助。

总之，《人月神话》是一本值得反复阅读和思考的书籍，它让我对软件开发有了更深入和全面的理解，也让我对自己有了更高的期望和标准。我希望能够把书中的理念和方法运用到我的实际工作中，成为一个更优秀的软件开发者。

《人月神话》读后感

最近阅读这本书，首先在书的标题《人月神话》确实是很美的名字，但是这和编程有什么关系呢，于是就去百度了一下题目的来源：
首先是“人月（man-month）”。熟悉软件项目管理的各位肯定清楚，人们常常根据人月来估计工作量（并相应收费），比如一个项目五人两月完成，那么总工作量就是10人月。本书以此命名，套用唱片工业的术语，可以说“人月神话”是本“专辑”中主打篇目，而除了以之为标题的第二章之外，并没有太多内容与此有关。
称之为“神话”，个人认为，作者只是委婉地表达了“人月”这种计量方法的有效性吧。书中第二章节的主要内容包括：

1.人/月之间不能换算，简而言之，2个人做5个月，并不等于5个人做两个月就可以完成；
2.（也是最有争议的一点）在项目后期增加人手，只能使工期进一步推迟；
3.项目越大，单位工作需要的人月越多。
归根结缔，作者想要粉碎的是“人月”概念可以线性把握的神话：无论是开发人员的人数上，还是工作量本身上的变化，都可能导致最终完成时间的非线性变化。作者的戏剧性表述是：Adding manpower to a late software project makes it even later. 这个观点事实上没有它看上去那么耸人听闻，而作者在初版以及后记中，都表示这包含了合理的夸张，后记里甚至援引进一步的研究表示，增加人手不一定会使工期进一步推迟，不过肯定会使工程效率进一步降低——而如果一定要增加人手，越早越好。

得出这样的结论，主要的考虑是增加人手带来的隐性花费（人员培训、多人工作时的通信成本等等）以及项目进程中存在的无法逾越的关键路径（crucial path）。对于项目管理人员来说，这应该已经是一个不言而喻的真理。但由于最终决策者的压力，实际项目中却往往会发生与此违背的情况。作者把一份法式餐厅菜单塞进了书中作为插图，我也建议大家学会菜单上的那个句子：Faire de la bonne cuisine demande un certain temps. Si on vous fait attendre, c’est pour mieux vous servir, et vous plaire（做好菜需要一定的时间。如果人家让您多等会儿，那是为了让您最后吃得高兴。） 对于说法语的客户/老板，这会是一个好的搪塞。
由于自己的编程经验并不是很丰富，也就是这学期正在做一个团队项目“随堂小测app”，而且自己还不是负责人，最关键的是，我们的团队本来就是这本书的反面教材，所以团队编程方面的体会并不是很多，为了增加自己对本书的理解，我特意去前辈们的博客园逛了逛，从他们的最简单的描述中获得一些核心的体会：
 如果一定要找到贯穿全书的概念的话，“概念完整性（conceptual integrity）”可能算是一个。宁可少添加一些七七八八的功能（anomalous features）,也应该保证，整个系统体现的是完整的一套设计理念 ：这是引入概念完整性的含义。概念完整性的受益者包括最终用户、系统开发者、培训员和服务人员。概念完整性保持得好的系统更易用，需要较短的培训时间和学习时间，同时也更易于开发。但是在软件生产的实践中，各级决策者都很容易产生强调功能而忽视概念完整性的倾向。因此我们看到了太多包含大量“功能”，而就整体而言不知所云的系统，也出现过太多次由于一两个附加功能的实现难度而导致整个系统开发推迟甚至难产的事例。