读到现在基本上我把整本书看了一遍，以我目前的经验来说，我只能认识到书中的一部分内容，下面是这几天的阅读收获：
为什么巴比伦塔是一个失败的工程；他们还缺乏些什么？
两个方面——交流， 以及交流的结果——组织。 他们无法相互交谈， 从而无法合作。 当合作无法进行时， 工作陷入了停顿。在这次高软的工程实践中我就深刻体会到这句话的重要性。我们组的项目所有代码都是我一个人写的，我的队友负责帮我优化UI。我告诉他我需要哪些东西，但是他完全按照他的理解做了一个完全不是我想要的东西。我以为我和他讲的很清楚，可是还是导致我们的项目在这里浪费了一些时间。最后总结，我和他交流有问题，还有就是他本身对于我们的项目是不理解的，所以导致他按照他的想法去做的时候就会和我的想法产生误差。
团队如何进行相互之间的交流沟通呢？通过所有可能的途径。
一．非正式途径
清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通从而达到对所书写文档的共同理解。
二．会议
常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。 这种方式非常有用，能澄清成百上千的细小误解。
三．工作手册
在项目的开始阶段，应该准备正式的项目工作手册。
巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果—组织， 是成功的关键。 交流和组织的技能需要管理者仔细考虑， 相关经验的积累和能力的提高同软件技术本身一样重要。
文档的重要性;
看完整本书我看到作者一直再强调文档的重要性，他曾经很勤奋的向软件工程师们讲述文档的必要性以及优秀文档所具有的特点方面的讲座。但是效果都非常的的不好，他们知道如何来写出优秀的文档，但是他们缺乏热情。所以作者采用向马车搬收银机的方法向他们展示如何来完成这项工作。结果显示这种方法的效果还是挺好的。那我们在开发的过程中需要什么样的文档呢？
不同用户需要不同级别的文档。 某些用户仅仅偶尔使用程序， 有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。使用程序。 每个用户都需要一段对程序进行描述的文字。可是大多数文档只提供了很
少的总结性内容，无法达到用户要求，验证程序。 除了程序的使用方法， 还必须附带一些程序正确运行的证明， 即测试用例。修改程序。 调整程序或者修复程序需要更多的信息。显然，这要求了解全部的细节，并且这些细节已经记录在注释良好的列表中。 和一般用户一样， 修改者迫切需要一份清晰明了的概述。
另外一个让我印象深刻的观点是：要保证一个项目的进度被大幅度推迟，制定进度表很重要。进度表由里程碑和完成时间组成。里程碑必须具体，明确，可界定。某一里程碑要么到达，要么没有到达，不应该是80%到达的。而我的经验是，制定进度表非常重要，而且要求制定者有很强的技术背景，这样才能对碰到的问题和可能花掉的时间做出更准确的估计。