初次听闻《人月神话》这本书，我以为它会是一本讲述神话或者浪漫爱情故事的书，但后来在老师的口中才了解到，
这讲述的并不是什么神话、爱情故事，而是一本有关软件工程方面的经典著作。经过老师的推荐，我抱着试一试的想法
阅读了这本书，虽然有很多地方还不太明白，但仍然收获了很多知识。目前我只阅读了前两章，借此来谈一谈自己的收获
以及感受。
书的前两章主要讲述了两个问题——焦油坑和人月神话。在第一章中，作者将软件危机比作了焦油坑，谈到美国20年
前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决
办法。过去几十年的大型系统开发就犹如一个焦油坑，很多大型企业在其中剧 烈地挣扎。他们中大多数开发出了可运行的
系统。不过，其中只有非常少数的项目满足了 目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干
的，都一个接一个 淹没在了焦油坑中，被软件危机所带来的灾难覆盖。表面上看起来好像没有任何一个单独的问题会导致
困难，每个都能被解 决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对于我们而言，如果
我们想解决问题，就必须试图先去理解它，了解什么是编程系统产品，同时也要找到自己职业的乐趣，因为只有发现了乐趣
，工作才会更有积极性。在第二章中，我了解到原来“人月“是我们项目工程中估计和进度安排中使用的工作量单位，用人月
作为 衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互 替换的但仅适用于某个任
务可以分解给参与人员，并且他们之 间不需要相互的交流的情况。因为软件开发本质上是一项系统工作——错综复杂关系下
的一种实践——沟通、交流 的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。当任务由于次序上的限制不能
分解时，人手的添加对进度不会有帮助。
虽然我现在只读了前两章，但同样拓宽了自己的视野，因此我决定继续读下去，继续探索软件工程的奥秘。