人月神话
《人月神话：软件项目管理之道》（英语：The Mythical Man-Month: Essays on Software Engineering）是由IBM System/360系统之父佛瑞德·布鲁克斯所著经典文集，全书讲解软件工程、项目管理相关课题，被誉为软件领域的圣经，内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验。其中的《没有银弹》在软件行业引发了巨大反响。
本文基于清华大学出版社出版的40周年纪念版，译者为UML China翻译组的汪颖，出版日期为2015年4月，ISBN 978-7-302-39264-4。
第1章 焦油坑（The Tar Pit）
编辑- 史前史中，没有别的场景比巨兽们中焦油坑中垂死挣扎的场面更令人震撼。上帝见证者恐龙、猛犸象、剑齿虎在焦油坑中挣扎。它们挣扎得越猛烈，焦油纠缠得就越紧，没有哪种猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
- 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈挣扎。他们中大多数开发出了可运行的系统——不过只有极少数的项目满足了目标、进度和预算的要求。各种团队，大型的或小型的，庞杂的或精干的，一个接一个地埋没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。
第2章 人月神话（The Mythical Man-Month）
编辑- 系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
- 用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
- 对于软件任务的进度安排，以下是我使用了很多年的经验法则：
- 1/3 计划
- 1/6 编码
- 1/4 构建测试和早起系统测试
- 1/4 系统测试，所有的构件已完成
- 向进度落后的项目中增加人手，只会使进度更加落后。
- Adding manpower to a late software project makes it later.
第3章 外科手术队伍（The Surgical Team）
编辑- 需要协作的沟通人员数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良后果（系统调试）。
- 绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、低效的，开发出的是无法在概念上进行集成的产品。
- 对于真正意义上的大型系统，小型精干的队伍太慢了。
- Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而不是一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
第4章 贵族专制、民主政治和系统设计（Aristocracy, Democracy, and System Design）
编辑- 在系统设计中，概念完整性应该是最重要的考虑因素。
- 由于目标是易用性（simplicity），功能与概念的复杂程度的比值才是系统设计的最终测试标准。单是功能本身或者简洁都无法成为一个好的设计评判标准。
- 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
- 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
- 若要得到系统概念上的完整性，必须有人控制这些概念，这实际上是一种无需任何歉意的贵族专制统治。
- 有很多行业和领域中的案例让人相信纪律和规则对行业是有益对。
- 外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
- 整个创造性活动包括了三个独立的阶段：体系结构（architecture）、设计实现（implementation）和物理实现（realization）。在实际情况中，它们往往可以同时开始和并发地进行。
第5章 画蛇添足（The Second-System Effect）
编辑- 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
- 想要成功，结构师必须：
- 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；
- 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；
- 对上述的建议保持低调和不公开；
- 准备放弃坚持所作的改进建议。
- 第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到对此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的地方。
第6章 贯彻执行（Passing the Word）
编辑- 对实现人员而言，修改的阶段化是很重要的——在进度表上应该有带日期的版本信息。
- 规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明必须重复所有的基本要素，所有文字都要互相一致。
- 如果想保持文字和产品之间的一致性，则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。
- 一句古老的格言警告说：“不要携带两个时钟出海，带一个或三个。”同样的原则也适用于形式化和记叙性定义。如果同时具有两种方式，则必须以一种作为标准，另一种作为辅助描述，并照此明确地进行划分。它们都可以作为表达的标准。
- 使用实现作为形式化定义特别容易引起混淆，特别是在程序化的仿真中。另外，当实现充当标准时，还必须防止对实现的任何修改。
- 直接整合[1]是一种强制推行软件的结构性标准的方法。
- 如果起初至少有两种以上的实现，那么（体系结构）定义会更加整洁和规范。
- 对于存有疑问的实现人员，应鼓励他们打电话[2]询问相应的结构师，而不是一边自行猜测一边工作，这是一项很基本的措施。
- 上述问题的答案必须是可以告知每个人的权威性结论。
- 一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。每周，对若干结构师的的日志进行合并，重新整理，并分发给用户和实现人员。
- 项目经理最好的朋友就是他每天要面对的对手——独立的产品测试机构/小组。
- 设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。
第7章 为什么巴比伦塔会失败（Why Did the Tower of Babel fail?）
编辑- 既然他们具备了所有的这些条件[3]，为什么项目（巴比伦塔）还会失败呢？他们还缺乏什么？其缺乏两个方面，其一是交流，其二是交流的结果——组织。
交流
编辑- 因为左手不知道右手在做什么，所以进度缓慢、功能不合理和系统缺陷等问题纷纷出现。
- 团队应该以尽可能多的方式进行相互之间的交流。
项目工作手册
编辑- 项目工作手册不是一篇独立的文档，它是对项目必须产出的一系列文档进行组织的一种结构。
- 项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
- 正确的文档结构非常重要。事先将项目工作手册设计好，能保证文档的结构本身是规范的，而不是杂乱无章的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节中。
- 控制信息发布并不是为了限制信息，而是确保信息能达到所有需要它的人的手中。
- 工作手册的实时更新是非常关键的。工作手册必须是最新的。
- 工作手册的使用者应该将注意力集中在上次阅读后的变更以及关于这些变更重要性的论述上。
- （David Lorge Parnas认为）当编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。
- 这种方法的先决条件是精确、完整地定义所有接口。如果能处理得好，的确是能解决很多“灾难”。一个好的信息系统不但能暴露接口错误，还能有助于改正错误。
团队组织
编辑- 团队组织的目的是减少所需的交流和合作的数量。
- 树状结构几乎不能用来描述交流沟通，因为交流是通过网状结构进行的。
- 存在三种可能的关系，它们都在实践中得到了成功的应用：
- 产品负责人和技术主管是同一个人。
- 产品负责人作为总指挥，技术主管充当其左右手。
- 技术主管作为总指挥，产品负责人充当其左右手。
第8章 胸有成竹（Calling the Shot）
编辑第9章 削足适履（Ten Pounds in a Five-Pound Sack）
编辑第10章 提纲挈领（The Documentary Hypothesis）
编辑第11章 未雨绸缪（Plan to Throw One Away）
编辑第12章 干将莫邪（Sharp Tools）
编辑第13章 整体部分（The Whole and the Parts）
编辑第14章 祸起萧墙（Hatching a Catastrophe）
编辑第15章 另外一面（The Other Face）
编辑第16章 没有银弹——软件工程中的根本和次要问题（No Silver Bullet - Essence and Accident in Software Engineering）
编辑- 在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。为了对付人狼，我们在寻找可以消灭它们的银弹。
- 没有任何技术上或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。
第17章 再论“没有银弹”（"No Silver Bullet" Refired）
编辑注释
编辑外部链接
编辑
