标签：
初见这本书是在大一，不过自己却没在那时候看下去，真正完成这本书的阅读是在这个寒假。尽管整本书读下来我不能算十分理解，只可谓一知半解，以后尽可能再多读几次，好书不怕费时间。
印象最深刻的是人月神话、外科手术还有为什么巴比伦塔会失败这三个部分。
把那些大型系统开发比作一个“焦油坑”，很多人在里面挣扎。你可能开发出来了可运行的系统，但是不一定能满足项目的目标、时间进度和预算的要求。
“人月神话”阐述了在软件开发过程中不合理的时间进度安排而带来的项目滞后这个灾难的原因。1.编程人员的乐观主义，他们总是在假设每个任务都会在规定的时间内完成，一切都会按照计划完美的运行成功。2.第二个错误的思考方式是在估计和进度安排中使用的工作量单位：人月，在这部分我还没弄懂它到底是怎样个分配的。3.在系统测试部分，对于系统测试的进度安排，作者在这方面使用了多年的经验法则是：1/3计划、1/6编码、1/4构件测试和早期系统测试、1/4系统测试，所有的构件已完成。分配给计划的时间是最多的，可是即便是如此也可能不能产生详细和稳定的计划规格说明。不为系统调试分配足够多的调试时间是一个非常大的错误，将会带来相当高的商业代价。4.空乏的估算5.重复产生的进度灾难人力，增加更多的人力，却会导致结果越一发不可收拾，向进度落后的项目增加人手，只会使进度更加落后。
将一个软件开发过程类比于一场外科手术，一个人来进行问题的分解，其他人给予他所需要的支持，提高效率和生产力。对于一个外科医生，他是首席程序员，将定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。副手是外科医生的后备，能完成任何工作，主要作用是设计的思考者、讨论者和评估人员。管理者充当与组织中其他管理机构的接口，为外科医生在财务、人员等方面做事。编辑根据外科医生的手稿或草稿，进行分析和重新组织加工，维护和监督文档的生成。两个秘书，服务于管理员和编辑。程序职员负责维护编程产品库中所有团队的技术记录。除这些之外，还要有工具维护人员、测试人员、语言专家。
巴别塔项目失败的原因是缺乏交流和组织。书中说缺乏交流的问题可以通过电话交流、定期的项目会议和项目工作手册解决。项目工作手册是对项目必须产出的一系列文档进行组织的一种结构，项目所有的文档都必须是该结构的一部分，这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中。工作手册必须是最新的，所以要及时更新，还要确保每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式，它是可行的，但并不一定是最有效的，因为有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。管理经理负责组织团队、分配工作、创建日程表等。很多时候，他建立内部交流和报告的模式，但是很多时候负责团队之外的交流。技术经理构造设计，确定模块，保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少，实干家也很少，有思想家特质的实干家是最少的。只有在3至6人的小项目中，管理经理和技术经理才可以是一个人。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。交流和组织是成功的关键，交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
标签：
原文地址：http://www.cnblogs.com/hongyedeboke/p/4301355.html
