正如老师在课堂上介绍的一样，第一次听说《人月神话》这本书的时候，感觉可能会是象古希腊的神话故事一类的书，看完之后，才了解了它原来是一本关于软件开发的书籍。早些时候就去图书馆里面借到了这本书，后来一直也没有怎么看，直到老师布置了看书写读后感后，才着急的看了全书，就目前来看，自己对软件工程的理解可以说非常的短浅，所以就只能简单地写一点自己的体会了。

      首先，从课堂上理解了“人月”的概念，意思是说软件开发者一个人一个月的工作量，在软件开发这方面，“人月”可以说是一个很重要的计量单位吧，它可以描述软件开发的工作量的大小，这是自己从软件工程里面学习到的一点知识吧。

      这本书主要讲了软件团队开发OS/360系统的开发经历，向我们介绍了在软件开发过程中遇到的一个又一个技术上的难题，有些克服掉了，有些却成了阻碍这个系统成功的主要的绊脚石，这也印证了软件开发的一句话：行百里者半九十，就是在软件开发的过程中，你可能感觉你已经完成了9成的工作量，而实际上你可能才完成了一半的工作量而已，从这方面来说，软件开发的工作量存在一定的虚拟性，因为随着需求的改动，可能软件开发的工作量会大幅度地的增加，这就是软件开发中经常遇到的问题了。

      本书还强调了文档的重要性，这是我的一个很大的感受，自己感觉按照目前我们自己写的小程序片段来看，文档似乎看起来可有可无，因为小的程序代码毕竟不是工作量浩大的软件开发，当你的工作量很小的时候，你可以不用太注意文档就可以写出成果来，而当软件开发工作量比较大的时候，文档就显得非常的重要了，这也许就是老师平常一直强调的让我们跟着课程的进度来写好对应的文档的原因吧。我自己觉的这就是象是我们在做算术题目，刚开始，我们接触到的加减乘除很简单，比如，2+3=？，这样我们不用列出算术和来计算，因为它的工作量比较的下，这样的情况下就显示不出来列式计算的优势，但是当工作量比较大的时候，比如：58934*6054=？这样的工作量比较大的时候，就会体现出列式计算的优势，列式计算就好比文档吧，所以，对于软件开发相对较大的工作量来说，文档就相当地的重要了。它决定了软件开发的整体的线路，并且也决定了软件开发的可行性，这是很重要的，否则可能就是开发过程中，做了大量的工作后，发现不可行性，如果这是个很关键的问题的话，那么这个软件开发很有可能就会僵持了，这对于软件开发来说是个天大的问题，也是软件开发的工作人员最讨厌的情况。

      本书还强调了团队的合作的重要性，一般来说，软件开发不可能是一个人的事情，肯定是一个团队一起来开发的，所以团队的来发人员一定要沟通好，这也是很重要的，因为每个成员负责自己的模块部分，软件的很大一部分时间就是花费在把每个成员自己写的代码连接起来，这也是非常让人头疼的问题，造成这样问题的原因就是团队没能沟通好，比如我们这次的软件工程的大作业五子棋原本计划用java来实现，C，C++实现起来用调用可视化库，而java的图形界面更加容易一点，但是我们小组的三个成员自己负责写自己的一部分代码，但是我们前期没有把相关的细节讨论清楚，每个人对自己的主要的任务了解但是具体的参数和和返回值等问题没有详细的确定下来，所以当我们基本完成的时候，我自己负责java下棋的部分和另外两位成员的代码没有办法拼接起来，虽然我们尝试了花费时间来拼接，但是感觉要把自己的代码大幅度的变动，不得不决定我们放弃原来的java计划，该哟个了C#来写，由于本人学习的C#不太多，所以就只能做一些简单的代码了，关键部分没有参与，从我们的经历中，感觉前期团队一定要沟通好，把自己负责的部分的要求理解清楚，千万不能马虎，否则就是后期软件的代码拼接上的问题重重。

     其次，本书中还提到了软件开发中的管理问题，一个开发团队，不能养闲散的人，每个人都要有明确的任务，这样的团队效率才会高，如果一些团队有着不做事情的人，他就是一匹害群之马，会拖累整个团队的效率和工作氛围，因为软件开发需要充足的人力，而不是多余的人力，多余的人力就会造成相反的效果了。

     以上是本人初读人月神话的一点感受吧，希望以后可以多读几遍，加深对软件开发整个过程的理解，希望前人走过的错路自己不要再去走，这也许就是站在了巨人的肩膀上了吧。