搜索
人月神话小组成员：人物简介：•美国工程院院士•“IBM360系统之父”，曾担任360系统的项目经理，及该项目设计阶段的经理。凭借在此项目中的杰出贡献，在1985年获得美国国家技术奖。•1999年荣获美国计算机领域最具声望的图灵奖（A.M.TURINGAWARD）桂冠。弗雷德里克·布鲁克斯FrederickP.Brooks,Jr.人月神话•2000年新年伊始，国际计算机协会（ACM）在纽约宣布1999年图灵奖得住为时年为69岁的FrederickP.Brooks,Jr.。评选委员会主席在致辞中提到，“今天我们所看到的计算机体系结构、软件工程及三维计算机图形，均受益于Brooks的开创性工作，是他改变了这些领域的面貌。”Brooks确实是一位在计算机科学各方面均作出杰出贡献的奠基者。•然而，他最广为认知的功绩则是在软件领域的重要经典著作——《人月神话》，可以说正是此书让软件工程学进入了人们的视野。弗雷德里克·布鲁克斯的经典著作——《人月神话》弗雷德里克·布鲁克斯的经典著作——《人月神话》•《人月神话》20周年纪念版•《人月神话》32周年纪念版软件领域的神话——一本畅销不衰的著作•在计算机这个日新月异的领域中，长盛不衰的书籍几乎是凤毛麟角的。为什么《人月神话》的魅力能不因技术的更替而黯淡，反而能在这多变的时代中证明自己的价值，乃至有了20年，32年的纪念版出现呢？•技术并非《人月神话》的着眼点，它更关注的是软件的创造过程、需求的变化无常和管理的永恒困境。•《人月神话》的中心思想已经超越了具体的时代和技术。名家谈人月神话•这是一本经典著作，与软件开发有关的每一个人都应该不只一遍地读这本书。——PhilippeKruchtenRational统一过程首席架构师•它仍然是计算机书籍中呗引用次数最多的书籍，而且即便本书最初出版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说一句“对极了！”是很难受的。——SteeMcConnell,Construx公司首席软件工程师•我唯一一本读过一遍以上的书，是FredBrooks的《人月神话》，实际上我每过一两年就会重读一遍。部分原因是这本书文笔很好，另外就是书中的忠告很有价值，即使是25年以后。我非常推崇这本书，这是我唯一能想起来的能从中体会到乐趣和思想的计算机学科书籍。——BrianKernighan,著名《C程序设计语言》的合著者之一。《人月神话》的由来•IBM的System/360是第一个特大型软件项目，它催生了《人月神话》《人月神话》的由来•System/360的开发过程被视为计算机发展史上最大的一次豪赌，为了研发System/360这台大型机，IBM决定征召六万多名新员工，创建五座新工厂，而当时出货的时间不断的顺延。•当时的专案经理FrederickP.Brooks,Jr.事后根据这项计划的开发经验，写作《人月神话：软件项目管理之道》（TheMythicalMan-Month:EssaysonSoftwareEngineering）记述人类工程史上一项里程碑式的大型复杂软件系统开发经验。•在《人月神话》中，Brooks博士为人们管理复杂的项目提供了最具洞察力的见解，既有很多引人深思的观点，又有大量软件工程的实践。人月神话•人月：软件开发过程中衡量工作量的常用度量单位。•而在实际情况中，增加“人”并不能缩短“月”的量•为什么说人月是神话？（1）许多任务是无法拆解的（2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加以(n-1)*n/2的规模递增•如：20人*5个月50人*2个月《人月神话》目录•第1章焦油坑•第2章人月神话•第3章外科手术队伍•第4章贵族专制、民主政治和系统设计•第5章画蛇添足•第6章贯彻执行•第7章为什么巴比伦塔会失败•第8章胸有成竹•第9章削足适履•第10章提纲挈领•第11章未雨绸缪•第12章干将莫邪•第13章整体部分•第14章祸起萧墙•第15章另外一面•第16章没有银弹-软件工程中的根本和次要问题•第17章再论“没有银弹”•第18章《人月神话》的观点：是与非•第19章20年后的《人月神话》人月神话——焦油坑•图为洛杉矶自然历史博物馆GeorgeC.Page馆内布拉雷亚焦油坑的中生代情形想象图原图焦油坑史前今天吞噬围困大型软件项目成千上万的巨兽无数庞大的开发团体人月神话——人月神话•图为早年新奥尔良的安东尼奥法式餐厅的菜单•精美的烹饪需要时间•软件开发项目常以人月来衡量工作，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话。•Brooks法则：向滞后的软件项目追加人手会使得进度更迟缓。人月神话——外科手术队伍•图为合众社发布的帧外科手术新闻照片•建立一个外科手术团队那样分工明细、合作有序的开发团队，是高效率软件开发的重要保障之一。人月神话——贵族专制、民主政治和系统设计•图为Reims大教堂内景，位于巴黎的Reims是建筑史上最富盛名的哥特式教堂建筑之一。•自从设计师Jeand’Ordais制订蓝图以后，继任的8位建筑师都理解并遵从这一初始设计的原则，保持了概念的完整性，最终Reims成为无与伦比的艺术精品。•概念完整性是系统设计中最重要的因素，尤其对大型软件系统来说，概念完整性是项目顺利完成的必要保障。人月神话——画蛇添足•图为1882年画家A.rOBIDA发表于比利时《二十一世纪报》上的插画：一个想象中极尽复杂的活动空中楼阁•设计者往往不肯放弃任何一个细枝末节的创意，从而堆砌出不胜繁复的设计，看似完美，并现实无可行性，往往会成为头重脚轻的空中楼阁。•软件项目的规划必须进行严谨理性的估算才能为项目的顺利进展打下牢固的根基，避免不必要的复杂化风险。人月神话——贯彻执行•图为14世纪宗教湿壁画Wells启示录中的七天使号手•号角声在七位天使间依次传递，前一位吹响后，后一位将照样吹响下一声，有条不絮，号角传递得十分精准。•团队间沟通顺畅有序，只有这样，概念完整性才能被正确贯彻到各处人月神话——为什么巴比伦塔会失败•图为维也纳Kunsthistorisches博物馆馆藏的16世纪奥地利兄弟画家中大Breughel所绘“巴别塔的建造”。•在基督教传说中，人类打算建筑一座通往天堂的巴别塔，上帝使人类各族语言不通，才阻止了这项工程。•在软件开发中，也许现有的技术已经可以所向披靡，但如果整个团队不能进行良好有效地沟通，项目就有可能功败垂成。人月神话——胸有成竹•图为美国历史上最伟大的职业棒球运动员贝比.鲁斯（BabeRuth）在球场上发号施令。•有效的管理和决策是致胜的关键。人月神话——削足适履•图为维多利亚时期英国画家HeywoodHardy的作品。•在大洪水到来之前，飞禽走兽们进入诺亚方舟。•在有限的空间中装载整个世界，这需要精巧的策划，绝不可轻易耗费资源。•最大化资源利用率，减少不必要的资源占用，合理规划，巧妙的数据结构往往大幅度地俭省资源耗费，提高系统运行的性能。人月神话——提纲挈领•图为1897年美国老国会图书馆内景。•作者以汗牛充栋的图书馆形象地比如软件项目中海量的文档令人目不暇接。•明智地把握好关键的几类文档，才能不在浩瀚的信息中迷失，才能迅速了解项目，进而准确地规划下一步工作。人月神话——未雨绸缪•图为纽约湾的Tacoma桥由于空气动力学上的错误设计而坍塌的新闻照片•在做项目设计和规划时，一定要考虑到各种不确定的变化因素，灵活适应多变的环境，否则很可能酿成悲剧后果。人月神话——干将莫邪•图为佛罗伦萨著名的圣母百花大教堂钟楼上的装饰浮雕——A.Pisano于1335年制作的“雕刻者”。•“工欲善其事，必先利其器”•适合的开发工具、评测技术能有事半功倍的效果，切合实用的工具和技术是项目团队的重要财富。人月神话——整体部分•图为迪士尼公司著名的米老鼠魔术师形象。•作者认为某些泛泛号称自己能完成庞大软件项目的业界人士，与旧时以夸张吹嘘来吸引观众注意的魔术师一样，其表演的东西经不起实质追究。•良好的软件项目管理，应该准确把握全局，严谨审核细节。人月神话——另外一面•图为位于英格兰东南部的巨石阵的想象复原图。•巨石阵是世界上最大的没有文档说明的“计算机器”。古人没留下任何说明，至今考古学家对古人建巨石阵的目的莫衷一是。•提供给用户的使用说明等文档是软件呈现给用户的另一面，它也能直接影响用户对软件的满意度和可用性评价。人月神话——祸起萧墙•图为1802年A.Canova所作雕塑：英雄海格力斯（Herculues）摔死带来死亡之袍的信使力卡斯（Lycas）。•海格力斯是希腊神话中最伟大的半人半神英雄，一生业绩辉煌，却因微小的家庭变故摔死不知情的力卡斯而走向了英雄末路。•潜藏的小祸患看似微不足道，有朝一日却可能葬送原本看起来坚不可摧的事物。•项目进度的滞后经常源自不易擦觉的点滴延误的积累。应尽量明确量化阶段性目标，定期验收、调整。人月神话——没有银弹-软件工程中的根本和次要问题•图为1685年德国线刻板画的人狼故事•是否存在消灭人狼的法宝——银弹？•由于软件的复杂性、一致性、变化性和不可见性，解决软件危机的银弹并不存在•没有任何一种单独的软件工程可以让软件开发的效率提高一个数量级。银弹人狼“焦油坑”危机软件项目消灭攻克银弹之争•无风不起浪：一篇《没有银弹》在学术界掀起了一场不大不小的风浪，从而引发了再论“没有银弹”。人月神话——再论“没有银弹”•图为儿童在搭建组合构造玩具。利用成型的配件，搭建大型的架构。•完美的东西其实就是过去不曾出现、现在不存在、将来也不可能出现的东西：不要指望《没有银弹》是完美的。•《没有银弹》中提到的观点是以10年为限的。•本章结合软件工程领域的最新发展，包括面向对象技术和软件复用等回应了争议：人们期待的重大突破不可能在近期内到来。是否存在终极利器？--银弹之争•人狼、银弹与软件项目–人狼：满月时会由人形变成狼形的怪兽。–银弹：唯一可以杀死人狼的武器。–软件项目：类似于人狼，常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。是否存在终极利器？--银弹之争•没有银弹（“NoSilverBullet”）–没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。--brooks,1986–原因：由软件工程的内在特性所决定的：复杂度，一致性，可变性和不可见性。•存在银弹（ThereIsaSilverBullet）–在信息化社会里，市场对信息的巨大需求将成为经济诱因，促使银弹的出现。--Cox,1990没有银弹！--Brooks•软件工程的内在特性–复杂度：不同于建筑、汽车等产品，软件实体可能比任何由人类创造的其它实体都要复杂，因为没有任何两个软件部分是相同的（至少是在语句的级别上）。•无规则性：不同于数学、物理等学科，软件工程所控制的很多复杂度是随心所欲、毫无规则可言的，来自于若干必须遵循的人为惯例和系统。–可变性：由于软件是纯粹的思维产物，易于修改，用户经常会提出改进要求。–不可见性：软件是无法可视化的，不仅限制了个人的设计过程，也阻碍了设计人员之间的交流。•由于软件工程的内在特性限制了银弹的出现！银弹就在这里！--Cox•Cox眼中的银弹：类似硬件晶片般的软件组件–通过使用结构化的方法，将软件组件内的复杂结构包装得完美，使得组件简单易用，由这些组件整合而成大型软件，自然简单易用，软件危机于是被化解了。–他指出重用和交互的构建开发是解决根本困难的一种方法。•为何现在没有出现银弹？–一般的工业产品每卖出一件就消耗一份组件，然而软件无论卖出多少件都只需要消耗一份组件。这样使软件组件提供商没有动力去生产出完美的组件。子弹的本质——形势没有发生改变•实际上，Cox在两点上误解了《没有银弹》：–一：他理解该文断定软件困难来自“编程人员缺乏构建当今软件的技术”。而根本困难是固有的概念复杂性。–二：他认为《没有银弹》所宣称的是没有希望。实际上每一种困难产生的麻烦都是可以改善的。•基本问题——复杂性是我们主要的限制–软件开发是一件棘手的事情，前方