计算机科学

首页 > 计算机科学

人月神话

2018-07-27 10:52:46     所属分类:软件工程
人月神话:软件项目管理之道
Mythical man-month (book cover).jpg
作者 佛瑞德·布鲁克斯
原名 The Mythical Man-Month: Essays on Software Engineering
译者 钱一一[1]
语言 繁体中文
题材 软件工程、项目管理
出版商 经济新潮社
出版日期 1975, 1995
中文版出版日期 2004年4月4日
页数 424页
ISBN 9867889185
OCLC 1201368
杜威分类法 001.6/425
LC分类法 QA76.6 .B75
上一部作品 没有银弹

人月神话:软件项目管理之道》(英语:The Mythical Man-Month: Essays on Software Engineering)是由IBM System/360系统之父佛瑞德·布鲁克斯所著经典文集,全书讲解软件工程、项目管理相关课题,被誉为软件领域的圣经,内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验[2]。该书于1975年首次发行(ISBN 978-0-201-00650-6),并于1995年重新发行纪念版(ISBN 978-0-201-83595-3)[3],其中新增了对〈没有银弹〉一文的评论和回应,与4个额外的新章节。

目录

  • 1 内容简介
    • 1.1 焦油坑
    • 1.2 人月神话
      • 1.2.1 人月
      • 1.2.2 Brooks法则
    • 1.3 外科手术团队
    • 1.4 专制、民主与系统设计
    • 1.5 第二系统效应
    • 1.6 意念的传达
    • 1.7 巴别塔为什么失败?
      • 1.7.1 沟通
      • 1.7.2 项目工作手册
      • 1.7.3 组织
    • 1.8 软件需求
  • 2 书目
    • 2.1 二十周年纪念版
  • 3 数据源
    • 3.1 引用文献
    • 3.2 脚注
  • 4 参见
  • 5 外部来源

内容简介

焦油坑

跟只为私人使用而单独写出来的组件程序相比,做出软件系统产品(programming systems product)所要付出的代价将是九倍以上。估计产品化(productizing)的代价是三倍,若要对组件从事设计、集成、测试,进而凝聚成为一个系统,则代价也是三倍,而且这方面的成本计算基本是独立的。[2]

软件开发的另一个难题,是从单一程序到软件系统过程中,所造成复杂度的快速上升,期间并需要包含不同的活动与技能,使得软件开发必须面对多样性的挑战。布鲁克斯最早认识到设计程序、开发软件的差别,他以程序与系统、产品的差异,解释两者之间的不同,并以3×3的复杂度加以说明。[5]

人月神话

人月神话英语:The mythical man-month):这部分讲述人力和时间并不呈现线性关系。指出以大量人员和较短的时间,并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产,且会制造麻烦,产生出更差的软件。向进度落后的项目追加人力,只会使进度更加落后。因为新进的人员需要时间了解整个项目,而增加额外的沟通消耗。当有N个人必须在这群人之中进行沟通时(无阶级关系),当N增加,其输出M将抵消其效益,甚至倒退(最后几天所完成的进度,远不如刚开始几天所完成的进度。像是发现了许多错误)。

  • 团队交流公式:
  • 示例:50个开发人员,就要个沟通管道

用“人月”来衡量工作规模的大小是危险的,也是一个容易遭到误解的迷思,使用人月的前提必须是在人力和工时可以互换的情况之下:当一份工作因具有连续性的限制而不可切分时,就算投入再多的人力,也不会对时程有所影响,生小孩就是需要九个月,你叫多少个妈一起生都一样,软件工程就是像这样的工作,因为它必须除错,而除错本身就具有连续性的本质。[2]

人月

人月英语:man-month)指的是“一个人要花几个月”才能完成软件开发的单位,通常用来评估一件软件项目的大小。[6]以成本会计(cost accounting)为基础的时程预估技术,使我们误把工作量和项目进度混为一谈,人月是个危险并很容易就遭到误解的迷思(myth),因为它假设人力和工时可以互换[2]

Brooks法则

在一个时程已经落后的软件项目中增加人手,只会让它更加落后。[7]根据Brooks法则,增加人员到一个已经延误的项目里,等于是火上加油。除非你可以把工作区分,让新进人员可在不影响他人工作的状况下有所贡献。

把工作切分给更多人做将造成额外的沟通(communication)代价——训练和相互的交流(intercommunication)。欲增加软件项目的人手,总共必须付出的代价可分为三方面:工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流。[2]

外科手术团队

在接受相同的训练、同样都是两年资历的情况下,优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。两人团队,其中一人当领导者,这通常是最佳的用人方式。以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示,使用一堆人蛮干的方式最耗成本、最慢、最没有效率,做出来的系统在概念上也最不完整。

以一位首席程序员为主、类似于外科手术团队的组织提供了一个良方,既可因少数人的决策而兼顾到产品的整体性,又可因多数人的合作与大幅沟通减少而得到全部人的生产力。[2]

专制、民主与系统设计

  • 在系统设计时,保有概念整体性(conceptual integrity)是最重要的原则。[2]
  • 功能概念复杂度比(这个比值是为了量测使用便利性,对简单和困难的运用都很有效)才是系统设计的最终测试标准。功能多,不见得是好事。
  • 要达成概念整体性,设计必须出自于一个人的想法,或是极少数人的一致决定。
  • 对大型软件项目(小项目也一样)来说,将架构设计独立于实现之外是获取概念整体性强而有利的方法。
  • 如果系统必须保有概念上的整体性,那么就必须有人来控制这些概念,这就是需要专制的原因,无庸置疑。
  • 许多软件架构、实现、实现的工作都是可以同时进行的。(不论硬件或软件设计,都可以同时进行)

第二系统效应

第二系统效应(英语:The second-system effect)就一个人所做过的设计而言,第二个系统是最危险的系统,一般来说,都倾向于过度设计。[2]

当他做第三或之后的系统时,之前的经验会互相印证,以确认出这类系统的一般性特色,而系统彼此之间的不同处,也会帮助他辨别出属于特殊和非通用的部分。除了做些功能上的修饰之外,第二系统效应还有另外一项特征,那就是倾向于将之前已熟悉的技术发挥到淋漓尽致,但却没有留意到,这项技术早就跟目前项目的基本系统假设有冲突而不再适用,OS/360有好多这样的例子。(Windows NT则似乎是1990年代的示例)

对大部分OS/360的设计人员来说,它也是个第二系统,设计成员分别来自1410-7010磁盘操作系统、Stretch操作系统、Project Mercury即时系统、给7090用的IBSYS操作系统等等,几乎没有人拥有两个上述系统的发展经验,所以OS/360可称得上是一个最佳的第二系统效应示例。

意念的传达

巴别塔为什么失败?

沟通

项目工作手册

手册或书面规格是不可或缺的工具,虽然光靠它是不够的。手册载明的是产品的外部(external)规格,用来描述并制定出用户从外观上将或看到的所有细节,撰写手册便是架构设计师的主要工作。当用户和实现人员的反应不断地显示出设计上难以使用或实现之处,手册就会堕入重新准备、修改的轮回之中。为了造福实现人员,将修改的程度予以量化(quantize)是很重要的——在时程上应该要有载明日期的版本信息。[2]

组织

软件需求

失败的软件项目经常发生在开发者与用户间对需求认知的误解。开发者抱怨用户说不清楚需求,而用户抱怨开发者误解他们的意思。布鲁克斯认为“软件开发最困难的单一项目,是精确地决定要建造什么。”[8]

书目

  • 初版[9]
  • 20周年纪念版[10]

二十周年纪念版

增修内容:[2]

  1. 将初版中所主张的所有论断整理出一个简洁的摘要,包括了原书的主要理念:就人力配置的比例而言,大型软件项目所面临的是跟小型项目完全不同的管理问题,这引申出产品的概念整体性是其中的关键,而达成概念整体性虽然困难,但却是可能办到的。
  2. 作者佛瑞德·布鲁克斯对他当初所提出的这些论断,在经过一个世代之后所做的观察。
  3. 转载布鲁克斯1986年发表于IEEE《Computer》的经典论文〈没有银弹〉。
  4. 布鲁克斯对于他1986年的论断“十年内不会有任何银弹”所做的回应。

数据源

引用文献

  • Frederick P. Brooks, Jr.; 译者:钱一一. 人月神话:软体专案管理之道. 经济新潮社. 2004年 [2011-04-12]. ISBN 9867889185 (中文(台湾)‎). 

脚注

  1. ^ 钱一一,1968年生,中正理工学院电子工程硕士,目前任职于中山科学研究院,从事大型系统的软件架构设计工作。《人月神话》是他的第一本译作。
  2. ^ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Frederick P. Brooks, Jr.; 译者:钱一一. 人月神话:软体专案管理之道. 经济新潮社. 2004年 [2011-04-12]. ISBN 9867889185 (中文(台湾)‎). 
  3. ^ 繁体中文版系根据1995年的纪念版
  4. ^ 该书〔导读软件人生之何似〕本书作者Frederick Brooks对于他自己的软件项目经历,所做的描述
  5. ^ 郑炳强. 软体工程:从实务出发(Software Engineering: A Perspective from Practices). 智胜文化事业有限公司. 2008年. ISBN 978-957-729-659-7 (中文(台湾)‎). 
  6. ^ 该书〔推荐序二〕科技再怎么变,人还是人
  7. ^ Brooks原文:“Adding manpower to a late software project makes it later.”
  8. ^ Brooks原文:“The hardest single part of building a software system is deciding precisely what to build.”
  9. ^ —. The Mythical Man-Month. Addison-Wesley. 1975. ISBN 0-201-00650-2. (英文)
  10. ^ —. Chap. 17. 'No Silver Bullet' Refired. The Mythical Man Month Anniversary Edition with four new chapters (Addison-Wesley). 1995. ISBN 0-201-83595-9. (英文)

参见

  • 佛瑞德·布鲁克斯
  • System/360
  • 没有银弹
  • 软件危机
  • 软件工程
  • 项目管理

外部来源

  • (繁体中文) 人月神话:软件项目管理之道(20周年纪念版)
  • (简体中文) 人月神话(32周年中文纪念版)
  • (英文) The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
  • (英文) Frederick P. Brooks, Jr.个人主页
  • (英文) Preface to 20th Anniversary Edition, as found on Safari.Informit.com
  • (英文) Organization and Team Patterns

上一篇:PSL/PSA
下一篇:代码审查

猜你喜欢

相关推荐