人月神话读后感

人月神话读后感

 中国科学技术大学软件杨旋原创

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

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

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

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

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

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

一．非正式途径

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

二．会议

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

三．工作手册

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

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

文档

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

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

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

 

整体部分(部分如何高质量的集成为一个整体)  

转载http://blog.sina.com.cn/s/blog_493a84550100bh0b.html

根据英文内容这里最好应该翻译为整体和部分。为了得到整体的可运行和高质量的软件，我们需要在哪些方面进行改进和下功夫。这章主要从消除Bug的设计，构件单元测试和系统集成调试三个方面来谈。
    之所以谈消除Bug的设计，就让我们更加意识到质量是设计出来的，而不是测试出来的。V.A.Vyssotsky提出许许多多的失败完全源于那些产品未精确定义的地方。这要求我们在需求和设计阶段要保持高质量，减少缺陷泄漏。对于需求要有详细的需求规格说明书，对于设计我们提倡的是从顶向下逐步求精的设计，而这里面最重要的就是结构化的设计方法和思路，不论是面向结构和面向对象其实都要遵守结构化的设计方法。在需求规格说明书完成后要尽快提交给测试小组编写测试用例，测试小组需要Review需求以确认需求完整，无歧义和可测试。
    在构件单元测试中讲的很多内容暂时无法和我们现在实际软件开发所对应，但是现在的敏捷开发方法论仍然强调测试驱动，先编写单元测试用例再开发代码，足见单元测试在敏捷软件开发中的重要地位，它不仅仅起到了测试的作用，更重要的是通过测试用例的编写喜欢需求和完善设计思路。
    对于大型软件系统，产品集成和集成测试具有重要的地位，为了系统的有计划的降低系统集成调试的困难性我们需要采取多种方法和措施。其中包括了首先对于单个构建必须经过充分的单元测试，否则单元测试的问题将遗留到集成测试阶段导致问题复杂化；其次是搭建充分的测试平台，测试平台往往需要编写测试代码，特别是还可能开发各种伪构件来验证数据集成的正确性。最后是在集成期间要严格控制变更，最好是阶段化的定期变更。

祸起萧墙(进度管理和监控的方法)
慢性的进度偏离是士气杀手，这里核心思想就是要意识到进度滞后往往如温水煮青蛙一样让我们难以应付，最重要的就是要防微杜渐。重大灾害是比较容易处理的，它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。 但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。
    进取对于杰出的软件开发团队，同优秀的棒球队伍一样，是不可缺少的必要品德。 为了加强我们对进度的监控，里程碑的定义就至关重要了。里程碑的选择只有一个原则，那就是，里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。以下是一些反面的例子，例如编码，在代码编写时间达到一半的时候就已经“90％完成”了；调试在大多时候都是“99％完成”的；“计划完毕”是任何人只要愿意，就可以声明的事件。
    里程碑有明显边界和没有歧义，比它容易被老板核实更为重要。如果里程碑定义得非常明确，以致于无法自欺欺人时，很少有人会就里程碑的进展弄虚作假。但是如果里程碑很模糊，老板就常常会得到一份与实际情况不符的报告。毕竟，没有人愿意承受坏消息。这种做法只是为了起到缓和的作用，并没有任何蓄意的欺骗。
    在进度跟踪和管理上，必须要在整个团队中树立这种观念，就是要尽可能早的完成相关的任务，而不是拖到了最后在来做。类似于关键链进度管理中始终强调的一个重点内容就是要压缩前面的开发周期而在项目后期预留缓冲。
    当进度出现偏差后，项目经理往往把问题掩盖起来，而且经常主观的认为可以通过各种赶进度的手段来挽回进度损失，但是往往情况并不是这么简单。因为很多时候 引起进度的偏差往往存在一些问题的根源，而这些根源往往是需要老板提前介入并采取一些行动，因此老板必须仔细区分状态报告、毫无惊慌地接收报告、决不越 俎代庖，将能鼓励诚实的汇报。

没有银弹：没有任何技术或管理上的进展， 能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。现代软件系统中这些无法规避的内在特性：复杂度、一致性、可变性和不可见性。那么软件开发总是非常困难的。天生就没有银弹。没有神话般的解决方案， 以及将来也不会有。

复杂性： 软件系统与计算机、建筑或者汽车大不相同，后者往往存在着大量重复的部分。由于软件产品特有的复杂度导致了成员之间的沟通非常困难，带来了软件产品的进度，质量和成本多方面的问题。特别是在软件规模增加的时候复杂度往往成倍上升。同时复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变得困难，从而妨碍了概念上的完整性。(在软件产品开发工厂化的过程中，我们要注意到仍然解决的是次要因素，比如加大公用组件开发，加大平台和框架的建设，而业务功能本身导致的复杂性是无法避免的。)

一致性：在某些情况下，因为是开发最新的软件，所以它必须遵循各种接口。另外一些情况下，软件的开发目标就是兼容性。在上述的所有情况中，很多复杂 性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂的特性。

可变性：系统中的软件包含了很多功能，而功能是最容易感受变更压力的部分。所有成功的软件都会发生变更。现实工作中，经常发生两种情况。当人们发现软件很有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。简言之，软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化。(软件开发的过程必须要考虑如何适应变化，在需求，设计和编码过程中都需要考虑如何快速响应变化，如何提高软件产品的可扩展性。我们在软件开发生命周期模型上强调增量迭代的思路，强调测试驱动的思路其根本目的就是为了快速响应变化，降低变化带来的风险。)
    不可见性：除去软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。(我们推荐快速原型法仍然是为了进来去解决软件不可见性的问题。

对没有银弹的感触转载http://blog.sina.com.cn/s/blog_493a84550100bhp9.html

    1.现在有很多快速开发平台，但是真正能够不写代码就完成业务功能的开发平台基本上没有成功的，特别是在业务场景比较复杂情况下，编程自动化基本是不可能的事情。唯一看到有所突破的是关于统一框架和技术平台等方面的建设，在原有的框架基础上我们来构建一个产品开发平台，将跟业务关系不大的权限模型，工作流引擎等集成进去，将常用的可复用组件集成进去，加快开发速度。
    2.不要在追求自动编程平台上下功夫，可以在加强组件复用和技术平台建设上下功夫。
    3.要多从开发模式的改进上来解决没有银弹所提出的各种实际问题，虽然不能够彻底解决，但是可以通过努力来改进。比如增量迭代的开发模型，快速原型法，测试驱动，高级语言和图形化编程等。

二十年后再续人月神话

    人月神话书如其名一样震撼人心，它引起了许多别的领域的读者对此进行评价。律师，医生，社会学家，心里学家，和软件人员一样对此书提出评论和建议。人们经常通过比较计算机软件开发生产率和硬件制造生产率来支持这个观点，后者在 20 年内至少翻了 1000 倍。正像第 16
章所解释的，反常的并不是软件发展得太慢，而是计算机硬件技术以一种与人类历史不相配的方式爆发出来。很多年后作者还是会被道“你现在认为哪些在当时就是错误的？哪些是现在才过时的？哪些是软件工程领域中新近出现的？”很多年来人们对软件生产率和影响它的因素进行了大量的研究，特别是在项目的人员配备和进度之间的平衡。最充分的一项研究是：Barry Boehm 对 63 个项目 的调查，其中大多数是航空项目和 25个 TRW 公司的项目。他的《软件工程经济学》（Software Engineering Economics）不但包括了很多结果， 而且还有一系列逐步推广的成本模型。 尽管一般商业软件的成本模型和根据政府标准开发的航空软件成本模型中的系数肯定不同， 不过他的模型使用了大量的数据来支撑。我想从现在起，这本书将作为一代经典。他的结果充分地吻合了《人月神话》的结论，即人力（人）和时间（月）之间的平衡远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。

    昨天我又把书翻了一遍，发现大部分内容都是涉及到团队，人和沟通。对于大型软件工程项目 强调人的重要性。在开篇讲开发人员的职业乐趣，后面又通过巴比塔的沟通重要性，在外科手术队伍中的组件和分工。这些都是涉及到团队中人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定开发工作是一种高智力的脑力工作。