2008-3-10 19:53
qq757526555
编辑推荐
“又见人月神话 重温软工经典” p3p8s ^w0x
1.软件领域绝无仅有，32年之后依旧畅销不衰的传奇经典！ Wu7H$O5N g4V
l cvS
2.软件开发人员、软件项目经理、系统分析师必读的一本书！*V2U
z3i({d
j-pqs|5RG]!G8`}
内容简介
l9n q N8E/Zc a
在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。
kUe:X7a+?(?
在本书第一次出版32年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使本书成为国内从业者的必读经典之一。'e n:Q8iw7L
本书读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。
4~J;P D'd:eMJB
.PF T b)\`
作者简介
[E4C9eU EK
Freder ick P.Brooks，Jr.曾荣获美国计算机领域最具声望的图灵奖（A.M.TURINGAWARD）桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。 !x?:a ]4m8k]6C
Brooks博士是北卡罗莱纳大学KENAN-FLAGLER商学院的计算机科学教授。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理，以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献，他与BobEvarls和Erich BIocll在1985年荣获了美国国家技术奖（NationalMedal of TecPlnoIogy）。Brooks博士早期曾担任IBM公司stretcPl和Harvest计算机的体系结构设计师。
x)M6X$[
Q(r qj\X
Brooks博士创立了北卡罗莱纳大学的计算机科学系，并在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。Brooks博士目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。{PG9|z$@ O-h
,O!f"U:d ]?b/A
目录
I Hp U)]&\!Y
z
第1章 焦油坑8[4t!pm!}L i
编程系统产品zi8A6n7S
职业的乐趣
7i9c:O0n(O
epFq4f
职业的苦恼
0Iv:R CPVP v9T-J
第2章 人月神话+M e:? A3WQ KXP
乐观主义,t-R0G$gJ b{/\
人月)B R;z].B
系统测试
R6X:`-\ho_
空泛的估算
\ c;t-K
NQ R8X
重复产生的进度灾难
:XL Cu3q1zUO
第3章 外科手术队伍
\2S+i5y _` Z1\3l
问题i \v-M Rh G
Mills的建议
#lXV$q(^D$r
如何运作L"c%_B/F-G{4\J_
团队的扩建%u.s%EL`P,]
第4章 贵族专制、民主政治和系统设计
1\u,Am/V"F
概念的完整性
%Fc o u/g9u@ wT%@
获得概念的完整性&em['V)iD|
贵族专制统治和民主政治
q3Sy3x&IE)r
在等待时，实现人员应该做什么W*k[g1k @
第5章 画蛇添足
s/]4VGQ
结构师的交互准则和机制2?/Gt]T \
QF
自律——开发第二个系统所带来的后果&T#G2E u/B _3j
第6章 贯彻执行 ~U~)}
H9D S9b*@4W
文档化的规格说明——手册!~ k$A"|&c QU |
形式化定义Z Jc2a?,x
直接整合
Y*jN&hh
会议和大会 o~/nfmZ
多重实现M~ g @ca k zP
电话日志
l2F+yy-Zk(n
产品测试
D\CCr"i8C Y0U
第7章 为什么巴比伦塔会失败
;EiT ~-s
巴比伦塔的管理教训 y-Cl:mY N8wM
大型编程项目中的交流
KCgMn
项目工作手册+M+H0O G\
大型编程项目的组织架构1M+U&n*l4A)xn|
第8章 胸有成竹tW q;e
Ol$u
第9章 削足适履
G&uT[7{)N
T#}L
第10章 提纲挈领 a0K%o!K(q-P*o
第11章 未雨绸缪
/\L7?H.`({I0}*M8WW
第12章 干将莫邪A0r{`!|;I
第13章 整体部分
1JR"G0Yx ?!{?
Ez
第14章 祸起萧墙6[ kV5m,bC
Rr
第15章 另外一面:] V8c sE8E;l
第16章 没有银弹9{D%@5y J
第17章 再论“没有银弹”b-`,]j]-U
第18章 《人月神话》的观点：是与非？
1t(W4m D u^5[3L
第19章 20年后的《人月神话》*uyL O*].O I#a
结束语：令人向往、激动人心和充满乐趣的50年
8xaIG/sn T,I x
注解与参考文献
;s/m%PY-K)fR
1P9V `;n[3GM
媒体评论
lh
svu?/t X
各路英豪品评人月实践 8g3y!}Nh#j+K-w*@b
软工经典再启江湖争论
)T _,aw~ ?;p+`
汇集国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得！ r-\:Q~j0?y
Frank Chance
2e%Lqh;n r%h"x
介绍
+W,g8iw;h.Q!`?to]
出版于1975年的《人月神话》是软件开发方面的经典作品。1995年版包括了令人感兴趣的新的几章，但原来的随笔依然是这本书的心脏与灵魂。在这本书中，Brooks解决了如何组织和管理大规模编程项目的问题。这些项目要求成百上千的程序员，产生几百万行代码(想想SAP、Oracle数据库引擎、Windows2000)。这部书由一系列简明的随笔组成。在这篇评论中我将讨论开篇随笔――我的最爱之一。 ,L(^ BlF+}f Nv
焦油坑
@"_hoY*kP
Dx
Brooks将大系统编程作比喻作史前的焦油坑来开始他的第一篇随笔：“记忆中，我们看到恐龙、猛犸象、剑齿虎正在挣脱沥青的魔爪。挣扎得越剧烈，陷入的越深，没有哪只野兽足够强壮或熟练，它们最终都沉没了。大系统编程在过去的十年间就像焦油坑，许多大而强有力的野兽在其中已经惨烈地失败了。大部分已实现并在运行的系统，很少有达到目标、时间表和预算的。大和小、厚重和细实，一个接一个的团队卷入了沥青(陷阱)。没有什么事情似乎会导致这个困难――任何特殊的手掌都能被拉出来。但同时并相互作用的因数的相互聚集导致运动越来越慢。每个人似乎都惊讶于问题的难缠，难于面对它的本质。” 6n'T0ER+e Gfg
记住，这些话写于1975年。今天它们仍然可用吗？考虑一下WindowsNT5.0。第一次计划于1997年发布，随后延迟到1998年早期，1998年末，然后是1999年(为此它被重新命名为Windows2000)。这儿是一些公开的估计： kS"s6E/M d"e
● 5,000程序员。
3L%H-_ D {!|
● 35,000,000行代码。 l1u+J9o`2{D'm?+a
显然，NT5.0是个大系统编程项目。同样显而易见，Brooks的焦油坑在今天同1975年一样普遍！ #mU F!j A
让我们继续NT5.0的例子。假设最糟糕的情况，全部35，000，000 行代码都是新编的。有理由假设开发工作大致在1994年开始。所以我们有： $n A+hm`~`@2A
● 5,000 程序员 X 5 年 = 25，000 程序员年 y-d'FCQ B8Y S~$N
● 35,000,000 行代码/ 25,000 程序员年 = 1,400 行／程序员年。
*{ ak"O kg
如果你是个程序员，或者你只接受过编程课程的教育，这个数字(1,400行每年)似乎令人惊异的低。我们当中的大部分人都能在一两天内堆积出接近一千行的代码。什么使得Microsoft的程序员一整年才产出1,400行代码？
$B1mT q2^;c+e!{y?
两种可能性跃入我们的脑海：
/uI qzV5lN6C8\
● Microsoft 雇用了5，000名不合格的程序员去开发NT 5.0。 *] dw6Y um%bz_$n
或者 &{
iC%|"a6IJ
● 写一个大规模的程序系统产品远难于堆砌出单一的程序。
:CK;j)l'ow+Nj'X
Brooks将讨论认为后一个答案是正确的。他由定义术语开始：
7cI x9I H-B
(1) 程序 r0st%W t(pL5M
一个独立的程序是我们两天编程狂欢的结果。它是准备自己运行于我们编程的那台机器上的。如果我们加上文档、通用化代码、编写测试用例、使得代码可以由其他无关的编程人员来维护，我们就有了：
F]l:i4y k
(2) 程序产品 t.t Nf2G O GV
另外，如果我们接受我们的程序，并且完整地定义了它的接口使得它达到预定义的规范，并且测试了它和大量的其它组件的交互作用，我们就有：
$j4NJ }!wz2X0Yp9zb*Z+p
(3) 程序系统组件 ;X.d#a,xf
ZXu
并且如果我们都做了(加上文档、通用化代码、编写测试用例、使得代码可维护、定义了接口、测试了交互作用)，我们就有： GAb!j|5g |qo
(4) 程序系统产品组件
+]o @b
y V5G:vT
Brooks用手边的三倍规则说明在上述每个步骤中的工作要求：
` tHB@:{iT
(2) ＝3倍(1)的人力 0I fK)}5U2p
(3) ＝3倍(1)的人力 (4)＝9倍(1)的人力
w @^ ~/H8d
或者，换句话说，开发一个独立的程序仅仅要求开发一个程序系统组件的1／9的人力。 'so4}g F |9j/Tt
回到Microsoft的例子，如果我们将这个9倍的因子乘以1，400行每程序员年的生产力测量，我们得到12，600行每程序员年(举例来说，假设我们掌握每一程序员，并且使得他们独立工作，堆砌在单一的程序上)。在一篇独立的随笔中，Brooks引用一个发现这点的经理的话说，平均他的每个程序员仅能将他的一半时间用于开发――其它时间由文书工作、会议和各种其它任务所占据。把这些因素考虑到Microsoft的例子中，我们达到了25，200行每程序员年。那么，Microsoft的程序员开始看来非常可敬。另一个测量自1975年来有了很小的改变，Brooks引用的估计是1，000行每程序员年。如果上面引用的1，400行每程序员年是精确的，那么，它表现了在1975年到1995年20年间，生产力仅仅提升了1.75%每年。这个结果证实了Brooks的另一个假定——程序员的生产力相对是个常量，它不受开发所用的语言的影响。因此，实际的生产力收获来自于迁移到高级语言编程，这些语言每行表达了更多的实际工作。尽管目标是大系统项目，Brooks的解释常常被广泛的应用。例如，这个第一篇随笔用标有“手艺的快乐”和“手艺的悲哀”的小节来结束。在悲哀中，他讨论了荒废的问题：
,R$knmHe*A z
“…这个人们已经工作了很长时间的产品，显然在完成前将被废弃。同事和竞争者已经在热烈地用新的和更好的主意反击。人们的孩童般想法的取代已经不仅仅在构思，而且付诸时间表。这一切总是似乎比它的实际更糟糕。新的和更好的想法通常在完成之前不被应用；它仅仅被谈论。真老虎永远不能和纸老虎相比。” ` G
Y9}0mVy7Pr
小结 $Z0E
D#nT5B i_
Brooks的随笔涉及到了大系统编程所固有的多种挑战，但对任何投身于软件开发的人来说读这本书都是有用的。题名的随笔(《人月神话》)讨论了许多编程任务的不可分割性，和为什么增加人力到软件项目中无法产生效用。我的另一篇最爱是“贵族、民主和系统设计”(概念完整性的讨论)和“计划和投放之路”(在付运前多次交付的明确计划的益处)。一些问题已经因为技术的进步而废弃，例如关于如何在一个大型团队中分发写好的文档。然而，你可能惊讶Brooks面对的许多问题今天如何阻止我们。另外的益处是Brooks简洁、清晰的作品读起来令人愉快。如果你是个程序员，如果你和程序员一起工作，如果你管理程序员，你应该阅读这本书。