人月神话感想

人月神话这个名字对我来说很有吸引力，我以为它会是一本讲述计算机历史神话的故事。当我看到第二章我才知道原来这个“人月“是我们项目工程中估计和进度安排中使用的工作量单位：人月。读完这本书我还是没有明白很多东西，因为得项目经验不足，不能站在巨人的肩膀上看懂这本书。但是看完之后还是有一些小小的感悟。

   《人月神话》是一本经典的软件工程的巨作，作者布鲁克斯（FrederickP.Brooks）被誉为“IBM System/360之父“，他曾是这一项目的项目经理，后来在设计期担任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士曾经早期担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。

    所有的编程人员都有乐观主义，总是相信自己的代码是肯定能运行的。所以在安排项目的进度的时候就会是假设在代码能够在正常运行时因该花费的时间。而现实往往不是乐观，在项目的进展过程中会存在各种不可预知的问题。在这个时候项目经理就会为项目增加人员，然而增加人员反而导致项目进度越来越慢。因为新增加的人员还需要培训，需要时间去了解项目的内容和进展情况。在投入了更多的人力的时候，经理发现项目进度反而更慢他就会投入更多的人力，这种恶行循环导致项目的失败。

    虽然0S/360失败了，但是它在开发的过程中解决了很多技术难题。它的开发过程成就了这本“人月神话“。这也让我想明白为什么大家都会觉得在项目实践中我们才可以学到更多。没有项目，你不会去想有什么问题。但是在项目中遇到问题的话，你最好的求助方式是网络和书籍，而且如果在遇到问题的时候能深入研究书籍的话你才会进步的比较快。

    让我印象最深的是巴比伦塔的管理教训里面的一句总结为什么巴比伦塔为什么是一个失败的工程：那为什么项目还会失败呢？他们还缺乏些什么？     两个方面——交流， 以及交流的结果——组织。 他们无法相互交谈， 从而无法合作。 当合作无法进行时， 工作陷入了停顿。在这次高软的工程实践中我就深刻体会到这句话的重要性。我们组的项目所有代码都是我一个人写的，我的队友负责帮我优化UI。我告诉他我需要哪些东西，但是他完全按照他的理解做了一个完全不是我想要的东西。我以为我和他讲的很清楚，可是还是导致我们的项目在这里浪费了一些时间。最后总结，我和他交流有问题，还有就是他本身对于我们的项目是不理解的，所以导致他按照他的想法去做的时候就会和我的想法产生误差。

团队如何进行相互之间的交流沟通呢？通过所有可能的途径。

一．非正式途径

   清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通从而达到对所书写文档的共同理解。

二．会议

   常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。 这种方式非常有用，能澄清成百上千的细小误解。

三．工作手册

在项目的开始阶段，应该准备正式的项目工作手册。

巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果—组织， 是成功的关键。 交流和组织的技能需要管理者仔细考虑， 相关经验的积累和能力的提高同软件技术本身一样重要。

文档

    看完整本书我看到作者一直再强调文档的重要性，他曾经很勤奋的向软件工程师们讲述文档的必要性以及优秀文档所具有的特点方面的讲座。但是效果都非常的的不好，他们知道如何来写出优秀的文档，但是他们缺乏热情。所以作者采用向马车搬收银机的方法向他们展示如何来完成这项工作。结果显示这种方法的效果还是挺好的。那我们在开发的过程中需要什么样的文档呢？

   不同用户需要不同级别的文档。 某些用户仅仅偶尔使用程序， 有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。使用程序。 每个用户都需要一段对程序进行描述的文字。可是大多数文档只提供了很 少的总结性内容，无法达到用户要求，验证程序。 除了程序的使用方法， 还必须附带一些程序正确运行的证明， 即测试用例。修改程序。 调整程序或者修复程序需要更多的信息。显然，这要求了解全部的细节，并且这些细节已经记录在注释良好的列表中。 和一般用户一样， 修改者迫切需要一份清晰明了的概述。

    另外一个让我印象深刻的观点是：要保证一个项目的进度被大幅度推迟，制定进度表很重要。进度表由里程碑和完成时间组成。里程碑必须具体，明确，可界定。某一里程碑要么到达，要么没有到达，不应该是80%到达的。而我的经验是，制定进度表非常重要，而且要求制定者有很强的技术背景，这样才能对碰到的问题和可能花掉的时间做出更准确的估计。