最近阅读这本书，首先在书的标题《人月神话》确实是很美的名字，但是这和编程有什么关系呢，于是就去百度了一下题目的来源：
首先是“人月（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）,也应该保证，整个系统体现的是完整的一套设计理念 ：这是引入概念完整性的含义。概念完整性的受益者包括最终用户、系统开发者、培训员和服务人员。概念完整性保持得好的系统更易用，需要较短的培训时间和学习时间，同时也更易于开发。但是在软件生产的实践中，各级决策者都很容易产生强调功能而忽视概念完整性的倾向。因此我们看到了太多包含大量“功能”，而就整体而言不知所云的系统，也出现过太多次由于一两个附加功能的实现难度而导致整个系统开发推迟甚至难产的事例。