人月神话（注释版）
当前位置:首页 > 计算机网络 > 软件工程/开发项目管理 > 人月神话（注释版）
出版社:人民邮电出版社
出版日期:2007年06月
ISBN:9787115156174
作者:Frederick P. Brooks
页数:322页
内容概要
Frederick P. Brooks, Jr.是1999年美国计算机协会（ACM）图灵奖得主，图灵奖是计算机领域最负盛名的技术奖项。ACM协会特别盛赞了他“在计算机体系结构、操作系统和软件工程领域中里程碑式的贡献”。Brooks博士创立了美国北卡罗莱纳大学的计算机科学系，并在1964~1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。他早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师，被认为是“IBM 360系统之父”
书籍目录
第1章 焦油坑
第2章 人月神话
第3章 外科手术团队
第4章 元老制、民主制和系统设计
第5章 第二个系统效应
第6章 沟通顺畅
第7章 巴别塔为何失败
第8章 掌控之中
第9章 袖里乾坤
第10章 文档先行
第11章 准备抛弃
第12章 良工利器
第13章 整体和局部
第14章 潜伏的祸患
第15章 另一面
第16章 没有银弹——软件工程的必然和偶然
第17章 再议“没有银弹”
第18章 人月神话中的提议：是耶非耶
第19章 人月神话二十年
跋
注解与参考文献
索引
作者简介
在软件项目管理领域中，从来没有一本书能像《人月神话》一样影响深远、弥久不衰。在本书中，Fred Brooks 将软件工程的实践和发人深思的观点融汇一炉，为每个复杂项目的管理者奉上了自己的真知灼见。本书包含的短文来自于他在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理的经验。在本书第一次出版20周年之际，Brooks重新修订了他最初的观点，并为已经熟悉他作品和刚刚接触本书的广大新老读者添加了新的观点和建议。
本书新增的章节包括：
初版中所有观点的精要浓缩，这其中包括Brooks在本书第一版中的核心观点：大型编程项目和小项目在管理上的不同之处在于人员划分的困难；所以在大项目中，产品的概念完整性至关重要；要达到这样的完整性虽然艰难但也并非全无可能。
Brooks在经过了一个时代之后对上述观点的看法。
Brooks在1986年发表的经典论文“没有银弹”。
Brooks现在对于1986年提出的“在十年内是不可能有银弹出现”的断言的反思。
图书封面
发布书评
精彩书评 (总计2条)
-
第一章 焦油坑史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开放这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。【图片评注】图为洛杉矶自然历史博物馆George C Page馆内拉布雷亚焦油坑（La Brea Tar Pits）的中生代情形想象复原图。拉布雷亚地区早在北美殖民时期就以天然焦油沥青矿闻名。在百万年前，南加州的这片土地密布的焦油坑使无数鸟兽遭受没顶之灾，该地区是世界最著名的史前动植物化石集中地区之一。其貌不扬而深不可测的焦油坑吞噬了多少强壮的恐龙和矫捷的飞禽，令它们的同伴惊惧。本章提到的软件项目的焦油坑，也令多少貌似强大的开发团队一筹莫展，这值得整个软件行业深思。，第二章 人月神话软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，布鲁克斯法则：向滞后的软件项目追加人手会使得进度更迟缓。自本书第一版以来，这一法则在软件业广为传诵。【图片评注】图为早年新奥尔良的安东尼奥法式餐厅的菜单，该餐厅创建于1840年，上方白底区域便是本章题词的出处：精美的烹饪需要时间，本章主题即以箴言此引申展开：向软件项目盲目增加人手以求速成，往往是欲速则不达。第三章 外科手术队伍虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。【图片评注】图为合众社发布的一帧外科手术新闻照片。建立一个外科手术团队那样分工明晰，合作有序的开发团队，是高效率软件开发的重要保障之一。第四章 元老制、民主制和系统设计概念完整性是系统设计中最重要的因素，尤其对于大型软件系统，概念完整性是项目顺利完成的必要保障，为获得概念完整性，架构设计由精简的架构设计小组负责，具体实现则围绕核心概念展开，架构设计和具体实现既相分离，又相辅相成。以建筑工程为类比，概念完整性也是软件项目通往成功的保证。【图片评注】图为Reims大教堂内景，位于巴黎的Reims是建筑史上最负盛名的哥特式教堂建筑之一。自从设计师Jean d’Ordais制定蓝图以后，继任的八位建筑师都理解并遵从这一初始设计的原则，保持了整体设计概念的完整性，最终Reims成为无与伦比的艺术精品。第五章 第二个系统效应人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。【图片评注】1882年画家A. Robida发表于比利时《二十世纪报》上的插画：一个想象中的极尽复杂的活动空中楼阁。设计者往往不肯放弃任何一个细枝末节创意，从而堆砌出不胜繁复的设计，这些设计往往成为头重脚轻的空中楼阁，看似完美，并无现实可行性。这种过度设计的错误，往往在设计者在踌躇满志地开始做系统改良设计时出现。软件项目的规划必须进行严谨理性的估算才能为项目的顺利进展打下牢固的根基，避免不必要的复杂化风险。第六章 沟通顺畅架构设计通常由核心设计小组完成，将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。以System 360的开发经验为例，要贯彻概念完整性，需要在团队中保持良好顺畅的沟通和交流，采用形式化定义等技术来确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。【图片评注】图为14世纪宗教湿壁画Wells启示录中七天使号手。号角声在七位天使间依次传递，前一位吹响号角后，后一位将照样吹响下一声，有条不紊，号声传递得十分精准。作者以此图比喻团队间沟通畅通有序，只有这样概念完整性才能被正确贯彻到各处。第七章 巴别塔为何失败如果缺乏良好有效的沟通和协作，成员间难以有效的配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。【图片评注】图为维也纳Kunsthistorisches博物馆馆藏的16世纪奥地利兄弟画家大Breughel所绘“巴别塔的建造”。在基督教传说中，人类发现可用砖和沥青代替天然的石块和灰泥来建筑房屋后，便打算建筑一座通往天堂的巴别塔。图中的巴别塔工程恢宏壮丽，工地欣欣向荣，确有直指云霄之势。上帝使人类各部族语言不通，才阻止了这项工程。在软件开发中，也许现有的技术已经可以所向披靡，但是如果整个团队不能进行良好有效的沟通，项目很可能功败垂成。第八章 掌控之中对大型软件系统产品的开发所需的时间和资源进行准确的估测，能让我们在项目进度和前景胸有成竹。软件代码的开发效率和代码模块之间所需的交互相关。界面交互复杂的程序需要更多的测试和调试时间，单纯地增加人手并不能有助于开发效率的提高。【图片评注】图为美国历史上最伟大的职业棒球运动员贝比·鲁斯（Babe Ruth）在球场上发号施令。鲁斯是1936年首批选入美国棒球名人堂的五人之一。效力于波士顿红袜队和纽约扬基队时大放异彩，促使了1920、30年代美国职业棒球的兴盛。著名的“班比诺的诅咒”（the Curse of the Bambino）更使他的传奇声名至今不衰。他不仅是杰出的击球手，在球场上他也是指挥若定的球队核心。本章以此隐喻有效的管理和决策是致胜的关键。第九章 袖里乾坤最大化资源利用率，减少不必要的资源占用，合理规划，使软件系统在资源有限的情况下依然保证了良好的性能，从而实现良好的可伸缩性和健壮性，这能体现软件开发人员精湛的设计技巧。巧妙的数据结构往往能大幅度地俭省资源耗费，提高系统运行的性能。【图片评注】图为维多利亚时期英国画家Heywood Hardy的作品，在大洪水到来之前，飞鸟走兽们进入诺亚方舟。 上帝许可每种鸟兽至少保留一公一母进入方舟逃避即将到来的灭顶之灾。小小诺亚方舟承担了各种群延续的希望，在有限的空间中装载整个世界，这需要精巧的规划，绝不可轻易耗费资源。第十章 文档先行在软件项目开发过程中，文档是不可或缺的，文档为整个团队规范了概念，以便团队中的沟通协作，以及进度校验。本章阐述了软件系统项目中至关重要的几类文档。这些关键文档应及时地更新，始终作为项目进展的有效指南。【图片评注】图为1897年美国老国会图书馆内景。作者以汗牛充栋的图书形象地比喻软件项目中海量的文档令人目不暇给，明智地把握好关键的几类文档，才能不在浩瀚的信息中迷失，才能够迅速了解项目，进而准确地规划下一步工作。第十一章 准备抛弃变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。【图片评注】图为纽约湾的Tacoma桥由于空气动力学上的错误设计而坍塌的新闻照片。1940年11月7日中午时分，建成仅仅数月的Tacoma桥坍塌，这是桥梁工程史上著名的悲剧。在做项目设计和规划时，一定要考虑到各种不确定的变化因素，灵活适应多变的环境，否则很可能酿成悲剧后果。第十二章 良工利器软件开发项目所选择的技术和工具对保障项目能否令人满意地如期完成至关重要。合适的开发工具、评测技术能有事半功倍之效果，切于项目实用的工具和技术是项目团队的重要财富。本章提供了当年软件开发项目选择技术和工具的重要原则和建议。【图片评注】图为佛罗伦萨著名的圣母百花大教堂钟塔（Campanile di Santa Maria del Fiore）上的装饰浮雕――A.Pisano于1335年制作的“雕刻者”。得心应手的工具，是艺术大师造就初巧夺天工之作的必要条件之一，所谓“工欲善，必先利其器”。第十三章 整体和局部大而无当的笼统见地并不能表现你真正地理解了一个软件系统，应该具体而系统地深入了解各个局部的技术。良好的自顶向下的设计，不仅能保证概念完整性，也能及早消灭许多隐患。及早在软件项目中引入测试， 错误发现得越早，修复错误的代价越小。【图片评注】图为迪斯尼公司著名的米老鼠魔术师形象。作者认为某些泛泛号称自己能完成庞大软件项目的业界人士，和旧时马戏团中以夸张吹嘘来吸引观众注意力的魔术师一样，其表演的东西并不能进行实质追究。良好的软件项目管理，应准确把握全局，严谨审核细节。第十四章 潜伏的祸患项目进度的滞后经常来自不易察觉的点滴延误的累积。软件项目的经理应该尽量建立可以明确量化的阶段性目标，定期进行严谨而规范的项目阶段性验收，了解项目的进展状况，并及时进行计划、资源和人力的调整。关键路径图等技术有助于观察项目的进度。【图片评注】图为1802年A. Canova所作的雕塑：英雄赫拉克勒斯（Hercules）摔死带来死亡之袍的信使利卡斯（Lycas）。半人马涅索斯临终前为了报复赫拉克勒斯，哄骗赫拉克勒斯的妻子说以它的血染过的衣袍能保持丈夫的忠诚。一次战争大捷后，妻子让利卡斯将这件染过毒血的袍子带给赫拉克勒斯，他穿上后即痛苦难忍，在愤怒中摔死了并不知情的利卡斯，这也是英雄赫拉克勒斯在人世的结局。赫拉克勒斯是希腊神话中最伟大的半人半神英雄，一生业绩辉煌，却因为微小的家庭细故而走向英雄末路。本章中作者以此比喻潜藏的小祸患看似微不足道，而有朝一日可能葬送了原本看起来坚不可摧的事物。第十五章 另一面虽然用户直接使用软件系统，但在许多应用领域中，用户不可能仅仅凭借与软件的直接交互就迅速掌握其所有功能。故而提供给用户的使用说明等文档是软件呈现给用户的另外一面，它也能直接影响用户对软件的满意度和可用性评价。文档的用途决定它的形式和内容。【图片评注】 图为英国巨石阵的想象复原图。巨石阵是世界上最大的没有文档说明的“计算机器“。4000－5000年前古人没有留下只言片语说明巨石阵的用途，至今考古学家对古人建筑巨石阵的目的莫衷一是，其中有一种可能是为了天文观测或者计算所用。本章中作者以此比喻文档匮乏会使软件产品难以为用户接受，故而使用文档在软件项目中相当重要。第十六章 没有银弹――软件工程的必然和偶然本文最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》初版发行已有十年，其间计算机技术领域的变化令人振奋，但作者在此提出，由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。作者点评了二十世纪80年代前期为业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。作者预言在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高。【图片评注】图为1685年德国线刻版画的人狼故事。传说中凶残恐怖的人狼只有用银弹才能杀死。本章写于《人月神话》初版后的10年，10年内初版中提到的“焦油坑”危机依然如难以杀死的人狼游荡世间，危害软件项目。本章即谈论是否存在能一劳永逸地消灭人狼的法宝――银弹。第十七章 再议“没有银弹”相比《人月神话》初版而言，1986年发表的“没有银弹”（第十六章）发表后引发了热烈的争论，本章结合20世纪80年代后期到90年代前期之间软件复用、面向对象程序开发等等新技术的发展状况，回应了对《没有银弹》一文各种主要异议，认为由于《没有银弹》一文归纳的软件的几大特性，人们期待中的重大突破不可能在近期内到来。【图片评注】图为儿童在搭建组合式构造玩具。利用成型的配件，能方便地搭建起大型的架构。本章以此讨论软件工程领域的最新发展，包括面向对象技术和软件复用等等，这些便利的新技术是否就是软件业界在寻找的银弹呢？第十八章 人月神话的提议：是耶非耶在撰写《人月神话》的回顾和更新过程中，作者发现初版中断言的观点甚少被软件工程研究和实践所抨击、证实或证伪，因此在本章中作者提炼了初版中十五个章节中的概要，结合近年来软件技术的发展状况，对这些观点进行强调、修正和反思。【图片评注】图为1967年本书作者Brooks在做主题陈述。本章是对前面诸章要点的提炼陈述。第十九章 人月神话二十年在《人月神话》初版发布二十周年后，计算机技术领域已有很大变化，《人月神话》体现出深远的影响力，初版中的许多观点依然经常被人们谈论和引用，其中有些断言至今仍被软件开放人员奉为圭臬。作者结合当前软件工程领域的发展现状重新梳理了初版中的各核心观点，强调了概念完整性，重新评议了第二个系统效应，反省了瀑布模型的局限性，结合初版中的观点，作者评述了图形桌面系统、信息隐藏、面向对象高级语言等技术的发展，以及近年来软件工程领域的重要成果。【图片评注】本章为《人月神话》二十周年纪念版的总结和更新陈述。鱼跃激流飞渡的图片，似在比喻计算机技术领域近二十年来令人兴奋的迅捷发展，借鉴历史，展望未来，在计算机技术这条年轻而遄急的河道上，我们当激流勇进，永不言退。 -
2000年新年伊始，国际计算机协会（ACM）在纽约宣布1999年图灵奖得主为时年69岁的布鲁克斯（Frederick P. Brooks, Jr.）。评选委员会主席在致辞中提到，“今天我们所看到的计算机体系结构、软件工程，以及三维计算机图形，均受惠于布鲁克斯的开创性工作，是他改变了这些领域的面貌。”布鲁克斯确实是一位在计算机科学各方面均作出杰出贡献的奠基者。然而，他最广为人知的功绩则是在软件工程领域的重要经典著作――《人月神话》，可以说正是此书让软件工程学进入人们的视野。大学期间曾主修物理的布鲁克斯，1956年从哈佛大学获得计算机博士学位。毕业后他加入IBM公司，在著名的Stretch和Harvest计算机体系结构设计中建树良多，其中包括著名的中断处理系统。上世纪60年代，他主持了IBM 360系列计算机及其操作系统 OS/360的开发，本书所谈到的经验，很多便来自他的这些项目经历。三十年来计算机技术的发展迅捷无伦，然而《人月神话》一直畅行不衰。自1975年第一版发行以来，直到1995年还保持着稳定的销量，成为软件工程领域引用率最高的著作之一，在普通读者和学术圈内都备受关注。1995年Addison-Wesley出版社推出二十周年纪念版，又是一时洛阳纸贵。在这个计算机这个日新月异的领域中，这样长盛不衰的书籍不能不说是凤毛麟角。《人月神话》的魅力并不因为技术的更新换代而黯淡，相反在纷繁多变的世代中，验证了自己的价值――固然计算机技术的变迁之快令人瞻望无及，然而技术并非《人月神话》的着眼点，它更关注的是软件的创造过程、需求的变化无常和管理的永恒困境，《人月神话》中的思想超越了具体的时代和技术。今天的软件从业人员，或许比三十年前的前辈们，能更深地体味到布鲁克斯在本书中的思虑――三十年来的技术发展，使计算机从高深莫测的象牙塔进入了寻常百姓案头，计算机硬件领域那些曾经的天堑化为通途，然而与此同时，布鲁克斯法则（Brooks’ Law），渐渐成为软件界耳熟能详的术语，大型软件项目的“焦油坑”危机，依然如幽灵般徘徊，布鲁克斯在三十年前写下的这些随笔，怎能不让我们深省？在写作风格上，《人月神话》也足以垂范后世。图灵奖评选委员会曾经特意提到，布鲁克斯不仅为计算机技术做出了杰出的贡献，他也是一位修养全面的学者。《人月神话》并非一份枯燥的技术文献，而是一系列文采斐然的随笔――布鲁克斯对文学和艺术涉猎颇广，他敏锐的思维和渊博的学识，使他在表述软件工程思想时，能从人文和其他工程领域信手拈来旁证博引，深得触类旁通之妙。从英语写作的角度上说，《人月神话》具备随笔体睿智而典雅的风貌，行云流水间文思严谨。读者不必象阅读常见的技术手册一样正襟危坐在工作台前研读，倒是可以在旅途之中，工作之暇轻松地开卷有益，领略精纯的文笔、睿智的思索。没有译者敢于声明自己的译文保留了《人月神话》的全貌，能象原著一样，让技术和人文炉火纯青地交相辉映。在保持技术准确的同时兼备原文流畅典雅的神韵，并非易事。美国文艺评论家苏珊.桑格塔曾说过，“翻译等于一次死亡”。《人月神话》在装帧排版上也颇具匠心，这些特色使《人月神话》在诸多计算机专业书籍中具备了卓尔不群的优雅风范，甚至于后来软件工程领域的随笔集，颇有不少效颦于《人月神话》者。基于这些原因，力所能及的读者，应以阅读原版为佳。只有这样不致于因为不完美的译文而错失精华。《人月神话》毕竟是三十年前出版的作品，文中谈到的许多技术，固然在历史上赫赫有名，但在今天的读者看来未免陌生，注释者拣选其中的一些术语加以说明。另外，布鲁克斯引用的人文著作和艺术隐喻，虽然在美国读者中耳熟能详，颇有趣味和启示意义，然而中国读者可能未必熟悉，我们也加以注释。更重要的是，正如布鲁克斯在《人月神话》中所倡导的“唯一不变的是变化本身”，人们只有在变化中才能体味永恒。作者在本书出版后不断根据技术的变化对本书中的观点进行审视和修订。如今距《人月神话二十周年纪念版》发行也已过去10年，在这10年中互联网技术的奇迹发展，使计算机越来越深入地渗透到普通人的日常应用中，软件工程领域的研究也非常活跃。我们在注释中有意识地提到这10年来技术的沿革以及最新的进展。以期读者能将目光延伸到当前乃至未来――相信这也是《人月神话》的本意。为这样的英文经典之作提供注释版本，无论对注释者来说还是一种尝试。注释者力图提供更丰富的背景知识和旁敲侧击的解说，以便读者在一睹原文全貌的同时，能在更开放的上下文中体味原文的精粹。布鲁克斯在书中谈到，计算机从业人员多是乐观主义者，这固然是由于这个行业朝气蓬勃令人振奋，更常见的缘故是我们常把目光局限在自己的所知领域内，一厢情愿地认为万事具备。布鲁克斯常在一片盲目乐观的欢快气氛中，通过周全的调查，冷静的思考，提出自己的怀疑，匡正可能出现的危机。正如他自称的“怀疑并不等同于悲观主义”，也正如他在《人月二十周年纪念版》最后一章末尾引用的圣经箴言：“上帝阻挡骄傲的人，赐恩给谦卑的人。”《人月神话》的宗旨并非提供确定的断言，而是提出省问和启发，在这个充满活力的技术领域中，引导人们思考。故而读者在阅读本书时，也当结合时代和自己的经验，博学审问，慎思明辨。1975年本书初版，之前不久，计算机工程师还在用紫色电线标出错误线路，程序员还在为获得几个小时的终端使用权而欣喜若狂，如今想来恍若隔世，对于《人月神话》谈到的过去的技术窘迫，读者不应傲慢嘲笑，书中记述的前辈们在解决这些窘迫所体现的才智和热情，则是永远值得后人借鉴的，也将启迪我们开拓未来之路。海德格尔曾说，“人类探索之路错综纷杂，只有向后之路才能指引我们向前。”谨以此向布鲁克斯致敬。2006年10月30日于北京
精彩短评 (总计24条)
-
就是这个加急比普通还慢，没有达到当当自己的承诺，还多收了一个加急费。 -
软件工程里程碑之作
-
硬皮的 封面不好。。还没看就坏了 -
印刷效果还不错，就是感觉这么精装没必要。装订的太宽了，成了方的了，抱在手里看起来感觉不爽。 -
ithinkitisgreat!allofwordsareenglish,ifyoucaninsisttostudy,youcanimprovefaster! -
很有感觉，受益匪浅 -
书不错，只是贵了些~~~~ -
很不错的书当然前提是英语需要够好对英语与软件都有帮助 -
读的稀里糊涂的。。。 -
Brooks软件工程开山之作 -
非常不错，BROOKS预测了未来还是限制了未来？值得我们思考 -
1.没必要搞成硬皮，增加了成本，也不好携带。2.影印字体不清晰，和复印的差不多。3.部分页面有破损，应该是装订问题。4.注释一般，深度不够。如果影印版不缺货，绝对不会买这本。 -
怎么看怎么象是为了多卖点纸张的烂注释，英文不好的人照样难以读http://comm.dangdang.com/reviewDetailImages/face_nofeel.gif[没感觉]懂原文～～～ -
学习项目管理的同时练了自己的英语阅读
-
很不错的书经典 -
真的很棒的……资历很浅，从来没有想到软件工程的文章可以这样的写……刚刚度过三章，虽说是英文，但的确很有感觉的……和曾经的一些经历联系起来感到收获是相当大的。 -
兵书 -
扫盲刻不容缓 -
经典…软件工程必读 -
不错，可以解决很多软件工程师的困扰。 -
这本书应该是在大学里,学习软件工程时,顺带阅读的书籍.这本书带有注释,能够让人顺带理解书中名词的含义 -
未来的程序员或是管理程序员为生的人必看的一本书，尤其适合每过一年重读一遍 -
呵呵呵呵呵呵呵呵…… -
但是理解需要时间