《人月神话》的原文摘录
-
乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误” 人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。 (查看原文) —— 引自章节：chapter 2 人月神话 -
系统开发的时间安排 1／3 计划 1／6 编码 1／4 构件测试和早期系统测试 1／4 系统测试，所有构件已完成 需要特别指出的是，不为系统测试安排足够的时间简直就是一场灾难 (查看原文) —— 引自章节：chapter 2 人月神话 -
简化Brooks的法则：向进度落后的团队增加人手，只会让进度更加落后。 (查看原文) —— 引自章节：chapter 2 人月神话 -
所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人；也可能是成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人；还可能仅仅因为计算机还很年轻，程序员更加年轻，而年轻人总是些乐观主义者棗无论是什么样的程序，结果是勿庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。” 所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。 ... 正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bug。也就是说，我们的乐观主义并不应该是理所应当的。 在单个的任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。 (查看原文) —— 引自章节：人月神话 (The Mythical Man-Month) -
成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能。 (查看原文) —— 引自章节：人月神话 (The Mythical Man-Month) -
因为软件开发本质上是一项系统工作棗错综复杂关系下的一种实践棗沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。 (查看原文) —— 引自章节：人月神话 (The Mythical Man-Month) -
简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致的折衷机制。在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的相似性。因此，易用性实际上需要设计的一致性和概念的完整性。 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。 而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节讨论的、一种崭新的组件编程开发团队的方法。 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。 让我们考虑一下树状编程队伍，以及要使它行之有效。每棵子树必须具备的基本要素，它们是： 1、任务 2、产品负责人 3、技术主管和结构师 4、进度 5、人力的划分 6、各部门之间的接口定义 (查看原文) —— 引自章节：团队的性质 -
它们挣扎得越猛烈，焦油就纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去了解问题。 (查看原文) —— 引自第4页 -
首先，苦恼来自追求完美。 其次，苦恼来自他人来设定目标、供给资源和提供信息。 最后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。 (查看原文) —— 引自第8页 -
在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会仔细谨慎地工作。 一种普遍倾向是过分的设计第二个系统，向系统添加很多的修饰功能和想法，他们曾在第一个系统中被小心翼翼地放在次要位置。 (查看原文) —— 引自章节：Chapter 5 画蛇添足 -
他们还缺乏两个方面﹣交流，以及交流的结果﹣组织。 (查看原文) —— 引自章节：Chapter 7 为什么巴比伦塔会失败 -
非正式途径：电话… 会议：常规项目会议 工作手册：在项目的开始阶段应该准备正式的项目工作手册。 (查看原文) —— 引自章节：Chapter 7 为什么巴比伦塔会失败 -
它是对项目必须产出的一系列文档进行组织结构的一部分 (查看原文) —— 引自章节：Chapter 7 为什么巴比伦塔会失败 -
让我们考虑一下树状编程队伍，以及要使他们有效，每棵子树所必须具备的基本要素： 1、任务（a mission） 2、产品负责人（a producer） 3、技术主管或结构师（a technical director or architect） 4、进度（a schedule） 5、人力的划分（a division of labor） 6、各部分之间的接口协议（interface definitions among parts） (查看原文) —— 引自章节：Chapter 7 为什么巴比伦塔会失败 -
1、技术主管和产品经理是同一个人。适用于6人左右的团队，通常这两种技术兼具的人相当少。 2、产品负责人指挥，技术主管充当左右手。这种情况相当难，很难在技术主管不参与任何管理工作的同时，建立起其在技术上的权威。 3、技术主管作为总指挥，产品经理作为其左右手。还是适用于小型团队。 (查看原文) —— 引自章节：Chapter 7 为什么巴比伦塔会失败 -
•为什么要有正式的文档 首先，书面记录决策是很有必要的。只有记录下来，分歧才会明朗，矛盾才会突出。 第二，文档能够作为同其他人的沟通渠道。 最后，项目经理的文档还可以作为数据基础和检查列表。 (查看原文) —— 引自章节：Chapter 10 提纲挈领 -
•试验性工厂和增大规模 对于大多数项目，第一个开发的系统并不合用。现在的问题是“是否构建一个实验性的系统，然后抛弃它” 为舍弃而计划，你一定要这样做 (查看原文) —— 引自章节：Chapter 11 未雨绸缪 -
抛弃原型的概念本身就是对事实的接受﹣随着学习的过程而改进 (查看原文) —— 引自章节：Chapter 11 未雨绸缪 -
∙为变更计划系统 变更的阶段化是一种必要技术。每个产品都应该有相应的数字版本号。 (查看原文) —— 引自章节：Chapter 11 未雨绸缪 -
•为变更计划组织架构 为变更组建团对比为变更进行设计更加困难。当系统发生变化时，管理结构需要进行相应的调整。 老板必须对他们的能力培养给予极大的关注，使管理人员和技术人员具有可换性。 (查看原文) —— 引自章节：Chapter 11 未雨绸缪
作者: 弗雷德里克.布鲁克斯
副标题: 32周年中文纪念版
isbn: 7302155674
书名: 人月神话
页数: 315
译者: UMLChina翻译组, 汪颖
定价: 48.00元
出版社: 清华大学出版社
装帧: 平装
出版年: 2007-9