人月神话
《人月神话：软件项目管理之道》（英语：The Mythical Man-Month: Essays on Software Engineering）是由美国软件工程师暨IBM System/360系统之父佛瑞德·布鲁克斯（Fred Brooks）所著文集，全书讲解软件工程、项目管理相关课题，被誉为软件领域的圣经，内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验[1]。该书于1975年首次发行（ISBN 978-0-201-00650-6），并于1995年重新发行纪念版（ISBN 978-0-201-83595-3）[注 2]，其中新增了对《没有银弹》一文的评论和回应，与4个额外的新章节。
| 人月神话：软件项目管理之道 | |
|---|---|
.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 |
内容简介 编辑
焦油坑 编辑
跟只为私人使用而单独写出来的组件程序相比，做出软件系统产品（programming systems product）所要付出的代价将是九倍以上。估计产品化（productizing）的代价是三倍，若要对组件从事设计、集成、测试，进而凝聚成为一个系统，则代价也是三倍，而且这方面的成本计算基本是独立的。[1]
| “ | 史前时期最骇人的景象，莫过于一群巨兽在焦油坑里做垂死前的挣扎。不妨闭上眼睛想像一下，你看到了一群恐龙、长毛象、剑齿虎正在奋力挣脱焦油的束缚，但越挣扎，焦油就缠得越紧，就算他再强壮、再厉害，最后，都难逃灭顶的命运。过去十年间，大型系统的软件开发工作就像是掉进了焦油坑里…… | ” |
| ——佛瑞德·布鲁克斯[2] | ||
软件开发的另一个难题，是从单一程序到软件系统过程中，所造成复杂度的快速上升，期间并需要包含不同的活动与技能，使得软件开发必须面对多样性的挑战。布鲁克斯最早认识到设计程序、开发软件的差别，他以程序与系统、产品的差异，解释两者之间的不同，并以3×3的复杂度加以说明。[3]
人月神话 编辑
人月神话（英语：The mythical man-month）：这部分讲述人力和时间并不呈现线性关系。指出以大量人员和较短的时间，并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产，且会制造麻烦，产生出更差的软件。向进度落后的项目追加人力，只会使进度更加落后。因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。当有N个人必须在这群人之中进行沟通时（无阶级关系），当N增加，其输出M将抵消其效益，甚至倒退（最后几天所完成的进度，远不如刚开始几天所完成的进度。像是发现了许多错误）。
- 团队交流公式：
- 示例：50个开发人员，就要 个沟通管道
用“人月”来衡量工作规模的大小是危险的，也是一个容易遭到误解的迷思，使用人月的前提必须是在人力和工时可以互换的情况之下：当一份工作因具有连续性的限制而不可切分时，就算投入再多的人力，也不会对时程有所影响，生小孩就是需要九个月，你叫多少个妈一起生都一样，软件工程就是像这样的工作，因为它必须调试，而调试本身就具有连续性的本质。[1]
人月 编辑
人月（英语：man-month）指的是“一个人要花几个月”才能完成软件开发的单位，通常用来评估一件软件项目的大小。[4]以成本会计（cost accounting）为基础的时程预估技术，使我们误把工作量和项目进度混为一谈，人月是个危险并很容易就遭到误解的迷思（myth），因为它假设人力和工时可以互换。[1]
Brooks法则 编辑
在一个时程已经落后的软件项目中增加人手，只会让它更加落后[注 3]。根据Brooks法则，增加人员到一个已经延误的项目里，等于是火上加油。除非你可以把工作区分，让新进人员可在不影响他人工作的状况下有所贡献。
把工作切分给更多人做将造成额外的沟通（communication）代价——训练和相互的交流（intercommunication）。欲增加软件项目的人手，总共必须付出的代价可分为三方面：工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流。[1]
外科手术团队 编辑
在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。两人团队，其中一人当领导者，这通常是最佳的用人方式。以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示，使用一堆人蛮干的方式最耗成本、最慢、最没有效率，做出来的系统在概念上也最不完整。
以一位首席程序员为主、类似于外科手术团队的组织提供了一个良方，既可因少数人的决策而兼顾到产品的整体性，又可因多数人的合作与大幅沟通减少而得到全部人的生产力。[1]
专制、民主与系统设计 编辑
- 在系统设计时，保有概念整体性（conceptual integrity）是最重要的原则。[1]
- 功能概念复杂度比（这个比值是为了量测使用便利性，对简单和困难的运用都很有效）才是系统设计的最终测试标准。功能多，不见得是好事。
- 要达成概念整体性，设计必须出自于一个人的想法，或是极少数人的一致决定。
- 对大型软件项目（小项目也一样）来说，将架构设计独立于实现之外是获取概念整体性强而有利的方法。
- 如果系统必须保有概念上的整体性，那么就必须有人来控制这些概念，这就是需要专制的原因，无庸置疑。
- 许多软件架构、实现、实现的工作都是可以同时进行的。（不论硬件或软件设计，都可以同时进行）
第二系统效应 编辑
第二系统效应（英语：The second-system effect）就一个人所做过的设计而言，第二个系统是最危险的系统，一般来说，都倾向于过度设计。[1]
当他做第三或之后的系统时，之前的经验会互相印证，以确认出这类系统的一般性特色，而系统彼此之间的不同处，也会帮助他辨别出属于特殊和非通用的部分。除了做些功能上的修饰之外，第二系统效应还有另外一项特征，那就是倾向于将之前已熟悉的技术发挥到淋漓尽致，但却没有留意到，这项技术早就跟目前项目的基本系统假设有冲突而不再适用，OS/360有好多这样的例子。（Windows NT则似乎是1990年代的示例）
对大部分OS/360的设计人员来说，它也是个第二系统，设计成员分别来自1410-7010磁盘操作系统、Stretch操作系统、Project Mercury即时系统、给7090用的IBSYS操作系统等等，几乎没有人拥有两个上述系统的发展经验，所以OS/360可称得上是一个最佳的第二系统效应示例。
意念的传达 编辑
巴别塔为什么失败? 编辑
沟通 编辑
项目工作手册 编辑
手册或书面规格是不可或缺的工具，虽然光靠它是不够的。手册载明的是产品的外部（external）规格，用来描述并制定出用户从外观上将或看到的所有细节，撰写手册便是架构设计师的主要工作。当用户和实现人员的反应不断地显示出设计上难以使用或实现之处，手册就会堕入重新准备、修改的轮回之中。为了造福实现人员，将修改的程度予以量化（quantize）是很重要的——在时程上应该要有载明日期的版本信息。[1]
组织 编辑
软件需求 编辑
失败的软件项目经常发生在开发者与用户间对需求认知的误解。开发者抱怨用户说不清楚需求，而用户抱怨开发者误解他们的意思。布鲁克斯认为“软件开发最困难的单一项目，是精确地决定要建造什么。”[注 4]
书目 编辑
二十周年纪念版 编辑
增修内容：[1]
参见 编辑
.gif){kind=small}
注释 编辑
参考文献 编辑
引用 编辑
- ^ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 Frederick P. Brooks, Jr. 人月神話：軟體專案管理之道. 由钱一一翻译. 经济新潮社 "year = 2004年. [2011-04-12]. ISBN 9867889185. （原始内容存档于2013-11-08） （中文（台湾））.
- ^ 该书〔导读软件人生之何似〕本书作者Frederick Brooks对于他自己的软件项目经历，所做的描述
- ^ 郑炳强. 軟體工程：從實務出發（Software Engineering: A Perspective from Practices）. 智胜文化事业有限公司. 2008年. ISBN 978-957-729-659-7 （中文（台湾））.
- ^ 该书〔推荐序二〕科技再怎么变，人还是人
- ^ —. The Mythical Man-Month. Addison-Wesley. 1975. ISBN 0-201-00650-2.（英文）
- ^ —. Chap. 17. 'No Silver Bullet' Refired. The Mythical Man Month Anniversary Edition with four new chapters (Addison-Wesley). 1995. ISBN 0-201-83595-9.（英文）
来源 编辑
- 书籍
- Frederick P. Brooks, Jr. 人月神話：軟體專案管理之道. 由钱一一翻译. 经济新潮社. 2004年 [2011-04-12]. ISBN 9867889185. （原始内容存档于2013-11-08） （中文（台湾））.
外部链接 编辑
| 维基语录上的人月神话语录 |
- （繁体中文） 人月神话：软件项目管理之道（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