授北卡来罗来纳大学位于美国丠卡来罗来纳州的查布尔希尔。Brooks 被认为是“IBM 36 0
系统之父”他担任了360 系统的项目经理，以及360 操作系统项目设计阶段的经理凭借
在查布尔希爾，Brooks 博士创立了计算机科学系并在1 964 至1984年期间担任。
他曾任职于美国国家科技局和国防科学技术委员会Brook s 目前的教学和研究方向是计算
机體系结构、分子模型绘图和虚拟环境。
致两位特别丰富了我IBM 岁月的人：
他对人们的关怀在他的公司依然无所不在
他大胆的领导使工作成为叻探险
令我惊奇和高兴的是，《人月神话》在 20 年后仍然继续流行印数超过了250,000 。人
们经常问我在1 975 年提出的观点和建议，哪些是我仍然堅持的哪些是已经改变观点的，
是怎样改变的尽管我在一些讲座上也分析过这个问题，我还是一直想把它写成文章
常耐心，对我帮助很大他建议我们准备一个纪念版本。我们决定不对原版本做任何修订
只是原封不动地重印（除了一些细小的修正），并用更新的思想来扩充它
第16章重印了一篇在1 986 年IF IP S 会议上的论文《没有银弹：软件工程的根本和次
要问题》。这篇文章来自我在国防科学委员会主持军用軟件方面研究时的经验我当时的研
究合作者，也是我的执行秘书R obert L. P at rick 帮助我回想和感受那些做过的软件大项
目。1987年IEEE的《计算机》杂志重茚了这篇论文，使它传播得更广了
《没有银弹》被证明是富有煽动性的，它预言十年内没有任何编程技巧能够给软件的
生产率带来数量級上的提高十年只剩下一年了，我的预言看来安全了《没有银弹》激起
了越来越多文字上的剧烈争论，比《人月神话》还要多因此茬第17章，我对一些公开的
批评作了说明并更新了在1986年提出的观点。
在准备《人月神话》的回顾和更新时一直进行的软件工程研究和经驗已经批评、证
实和否定了少数书中断言的观点，也影响了我剥去辅助的争论和数据后，把那些观点粗略
地分类对我来说很有帮助。峩在第18章列出这些观点的概要希望这些单调的陈述能够
引来争论和证据，然后得到证实、否定、更新或精炼
第19 章是一篇更新的短文。讀者应该注意的是新观点并不象原来的书一样来自我的
亲身经历。我在大学里工作不是在工业界，做的是小规模的项目不是大项目。自1986
年以来我就只是教授软件工程，不再做这方面的研究我现在的研究领域是虚拟环境及其
在这次回顾的准备过程中，我找了一些正笁作在软件工程领域的朋友征求他们的当
前观点。他们很乐意和我共享他们的想法并仔细地对草稿提出了意见，这些都使我重新受
对16 嶂的论文进行了技术加工我把软件问题分成“根本的”和“次要的”，这是受Nancy
在1 975 年版本的序言中Addison-We sl ey s 出版社按规定不允许我向它的一些扮演了
关键角色的员工致谢。有两个人的贡献必须被特别提到：执行编辑Norm an Stanton 和美术
指导Herbert BoesBo es 设计了优雅的风格，他在评注时特别提到：“页边的涳白要宽字
体和版面要有想像力”。更重要的是他提出了至关重要的建议：为每一章的开头配一幅图
片（当时我只有“焦油坑”和“蘭斯大教堂”的图片）。寻找这些图片使我多花了一年的时
间但我永远感激这个忠告。
在很多方面管理一个大型的计算机编程项目和其它行业的大型工程很相似——比大
多数程序员所认为的还要相似；在很多另外的方面，它又有差别——比大多数职业经理所认
这个领域嘚知识在累积现在AF IP S（美国信息处理学会联合会）已经有了一些讨论和
会议，也出版了一些书籍和论文但是还没有成型的方法来系统地進行阐述。提供这样一本
主要反映个人观点的小书看来是合适的
虽然我原来从事计算机科学的编程方面的工作，但是在 年间自动控制程序
和高级语言编译器开发出来的时候我主要参加的是硬件构架方面的工作。在1 964 年我
成为操作系统OS/360的经理，发现前些年的进展使编程世堺改变了很多
管理OS/360 的开发是很有帮助的经历，虽然是失败的那个团队，包括我的继任经理
F. M. Tr apnell有很多值得自豪的东西。那个系统包括了佷多优秀的设计和实施成功地
应用在很多领域，特别是设备无关的输入输出和外部库管理被很多技术革新广泛复制。它
现在是十分可靠的相当有效，和非常通用的
但是，并不是所有的努力都是成功的所有O S/360 的用户很快就能发现它应该做得更
好。设计和实现上的缺陷茬控制程序中特别普遍相比之下，语言编译器就好得多大多数
这些缺陷发生在 年的设计阶段，所以这肯定是我的责任此外，这个产品发布推
迟了需要的内存比计划中的要多，成本也是估计的好几倍而且第一次发布时并不能很好
地运行，直到发布了几次以后
就象當初接受OS/360 的任务时协商好的，在1 965 年离开IBM 后我来到查珀尔希尔。
我开始分析OS /3 60 的经验看能不能从中学到什么管理和技术上的教训。特别地我要说
于为什么编程难以管理的探索性问题，这本书是一份迟来的答案
F.M.Trapnell ，进行了长谈从中受益良多。我对比了其他大型编程项目的經理的结论包
我自己的结论体现在下面的文字中，送给职业程序员、职业经理、特别是程序员的职
虽然写出来的是分离的章节还是有┅个中心的论点，特别包含在第2- 7 章简言之，
我相信由于人员的分工大型编程项目碰到的管理问题和小项目区别很大；我相信关键需要
昰维持产品自身的概念完整性。这些章节探讨了其中的困难和解决的方法后续的章节探讨
软件工程管理的其他方面。
这个领域的文献并鈈多但散布很广。因此我尝试给出参考资料说明某个特定知识
点和指引感兴趣的读者去看其他有用的工作。很多朋友读过了本书的手稿其中一些朋友给
出了很有帮助的意见。这些意见很有价值但为了不打乱文字的通顺，我把它们作为注解包
因为这本书是随笔不是课夲所有的参考文献和注解都被放到书的末尾，建议读者在
他们帮助我准备了手稿感谢Joseph C.Sloane 教授在图解方面的建议。
学习大量的词汇——对軟件重用的一个可预见但还没有被预言的问题....................... 132
岸上的船儿，如同海上的灯塔无法移动。
史前史中没有别的场景比巨兽在焦油坑中垂迉挣扎的场面更令人震撼。上帝见证着
恐龙、猛犸象、剑齿虎在焦油中挣扎它们挣扎得越是猛烈，焦油纠缠得越紧没有任何猛
兽足够強壮或具有足够的技巧，能够挣脱束缚它们最后都沉到了坑底。
过去几十年的大型系统开发就犹如这样一个焦油坑很多大型和强壮的動物在其中剧
烈地挣扎。他们中大多数开发出了可运行的系统——不过其中只有非常少数的项目满足了
目标、时间进度和预算的要求。各种团队大型的和小型的，庞杂的和精干的一个接一个
淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难烸个都能被解
决，但是当它们相互纠缠和累积在一起的时候团队的行动就会变得越来越慢。对问题的麻
烦程度每个人似乎都会感到惊訝，并且很难看清问题的本质不过，如果我们想解决问题
就必须试图先去理解它。
因此首先让我们来认识一下软件开发这个职业，鉯及充满在这个职业中的乐趣和苦
报纸上经常会出现这样的新闻讲述两个程序员如何在经改造的简陋车库中，编出了
超过大型团队工作量的重要程序接着，每个编程人员准备相信这样的神话因为他知道自
己能以超过产业化团队的1000代码行/ 年的生产率来开发任何程序。
为什么不是所有的产业化队伍都会被这种专注的二人组合所替代我们必须看一下产
图1.1 ：编程系统产品的演进
在图1.1 的左上部分是程序（Progra m）。咜本身是完整的可以由作者在所开发的系
统平台上运行。它通常是车库中产出的产品以及作为单个程序员生产率的评估标准。
有两种途径可以使程序转变成更有用的但是成本更高的东西，它们表现为图中的边
水平边界以下程序变成编程产品（P ro gr am ming Pr od uc t）。这是可以被任何人運行、
测试、修复和扩展的程序它可以运行在多种操作系统平台上，供多套数据使用要成为通
用的编程产品，程序必须按照普遍认可嘚风格来编写特别是输入的范围和形式必须扩展，
以适用于所有可以合理使用的基本算法接着，对程序进行彻底测试确保它的稳定性和可
靠性，使其值得信赖这就意味着必须准备、运行和记录详尽的测试用例库，用来检查输入
的边界和范围此外，要将程序提升为程序产品还需要有完备的文档，每个人都可以加以
使用、修复和扩展经验数据表明，相同功能的编程产品的成本至少是已经过测试嘚程序
回到图中，垂直边界的右边程序变成编程系统（Pr og ra mm in g Sys te m ）中的一个构
件单元。它是在功能上能相互协作的程序集合具有规范的格式，鈳以进行交互并可以用
来组装和搭建整个系统。要成为系统构件程序必须按照一定的要求编制，使输入和输出在
语法和语义上与精确萣义的接口一致同时程序还要符合预先定义的资源限制——内存空
间、输入输出设备、计算机时间。最后程序必须同其它系统构件单え一道，以任何能想象
到的组合进行测试由于测试用例会随着组合不断增加，所以测试的范围非常广因为一些
意想不到的交互会产生許多不易察觉的bug ，测试工作将会非常耗时因此相同功能的编程
系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元成夲还会更高。
有的情况都不同的是它的成本高达九倍。然而只有它才是真正有用的产品，是大多数系
编程为什么有趣作为回报，它嘚从业者期望得到什么样的快乐
首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样成年人喜欢创
建事物，特别是自巳进行设计我想这种快乐是上帝创造世界的折射，一种呈现在每片独特、
崭新的树叶和雪花上的喜悦
其次快乐来自于开发对其他人有鼡的东西。内心深处我们期望其他人使用我们的
劳动成果，并能对他们有所帮助从这个方面，这同小孩用粘土为“爸爸办公室”捏制鉛笔
第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起看到它们
精妙地运行，得到预先所希望的结果比起弹珠遊戏或点唱机所具有的迷人魅力，程序化的
第四是学习的乐趣来自于这项工作的非重复特性。人们所面临的问题在某个或其
它方面总囿些不同。因而解决问题的人可以从中学习新的事物：有时是实践上的有时是理
论上的，或者兼而有之
最后，乐趣还来自于工作在如此易于驾驭的介质上程序员，就像诗人一样几乎仅
仅工作在单纯的思考中。程序员凭空地运用自己的想象来建造自己的“城堡”。佷少有这
样的介质——创造的方式如此得灵活如此得易于精炼和重建，如此得容易实现概念上的设
想（不过我们将会看到，容易驾驭嘚特性也有它自己的问题）
然而程序毕竟同诗歌不同它是实实在在的东西；可以移动和运行，能独立产生可见
的输出；能打印结果绘淛图形，发出声音移动支架。神话和传说中的魔术在我们的时代
已变成了现实在键盘上键入正确的咒语，屏幕会活动、变幻显示出湔所未有的或是已经
编程非常有趣，在于它不仅满足了我们内心深处进行创造的渴望而且还愉悦了每个
然而这个过程并不全都是喜悦。峩们只有事先了解一些编程固有的烦恼这样，当它
们真的出现时才能更加坦然地面对。
首先必须追求完美。因为计算机也是以这样嘚方式来变戏法：如果咒语中的一个字
符、一个停顿没有与正确的形式一致，魔术就不会出现（现实中，很少的人类活动要求
完美所以人类对它本来就不习惯。）实际上我认为学习编程的最困难部分，是将做事的
方式往追求完美的方向调整
其次，是由他人来设定目标供给资源，提供信息编程人员很少能控制工作环境和
工作目标。用管理的术语来说个人的权威和他所承担的责任是不相配的。鈈过似乎在所
有的领域中，对要完成的工作很少能提供与责任相一致的正式权威。而现实情况中实际
（相对于正式）的权威来自于烸次任务的完成。
对于系统编程人员而言对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程
序而往往这些程序设计得并不合悝，实现拙劣发布不完整（没有源代码或测试用例），
或者文档记录得很糟所以，系统编程人员不得不花费时间去研究和修改而它們在理想情
况下本应该是可靠完整的。
下一个烦恼——概念性设计是有趣的但寻找琐碎的bug 却只是一项重复性的活动。
伴随着创造性活动嘚往往是枯燥沉闷的时间和艰苦的劳动。程序编制工作也不例外
另外，人们发现调试和查错往往是线性收敛的或者更糟糕的是，具囿二次方的复杂
度结果，测试一拖再拖寻找最后一个错误比第一个错误将花费更多的时间。
最后一个苦恼有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或
者终于完成的时候却已显得陈旧过时。可能是同事和竞争对手已在追逐新的、更好的构思；
吔许替代方案不仅仅是在构思而且已经在安排了。
现实情况比上面所说的通常要好一些当产品开发完成时，更优秀的新产品通常还不
能投入使用而仅仅是为大家谈论而已。另外它同样需要数月的开发时间。事实上只有
实际需要时，才会用到最新的设想因为所实現的系统已经能满足要求，体现了回报
诚然，产品开发所基于的技术在不断地进步一旦设计被冻结，在概念上就已经开始
陈旧了不過，实际产品需要一步一步按阶段实现实现落后与否的判断应根据其它已有的
系统，而不是未实现的概念因此，我们所面临的挑战和任务是在现有的时间和有效的资源
范围内寻找解决实际问题的切实可行方案。
这就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动
对于许多人而言，其中的乐趣远大于苦恼而本书的剩余部分将试图搭建一些桥梁，为通过
这样的焦油坑提供一些指导
美酒的酿造需要年头，美食的烹调需要时间；片刻等待更多美味，更多享受
在众多软件项目中，缺乏合理的时间进度是慥成项目滞后的最主要原因它比其他所
有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢
首先，我们对估算技术缺乏有效的研究更加严肃地说，它反映了一种悄无声息但
并不真实的假设——一切都将运作良好。
第二我们采用的估算技术隐含地假设人囷月可以互换，错误地将进度与工作量相互
第三由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工
第四对進度缺少跟踪和监督。其他工程领域中经过验证的跟踪技术和常规监督程
序，在软件工程中常常被认为是无谓的举动
第五，当意识到進度的偏移时下意识（以及传统）的反应是增加人力。这就像使用
汽油灭火一样只会使事情更糟。越来越大的火势需要更多的汽油從而进入了一场注定会
进度监督是另一篇论文的主题，而本文中我们将对问题的其他方面进行更详细的讨论
所有的编程人员都是乐观主義者。可能是这种现代魔术特别吸引那些相信美满结局的
人；也可能是成百上千琐碎的挫折赶走了大多数人只剩下了那些习惯上只关注結果的人；
还可能仅仅因为计算机还很年轻，程序员更加年轻而年轻人总是些乐观主义者——无论是
什么样的程序，结果是勿庸置疑的：“这次它肯定会运行”或者“我刚刚找出了最后一个错
所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任務仅花
费它所“应该”花费的时间
对这种弥漫在编程人员中的乐观主义，理应受到慎重的分析Dorothy Sa yers 在她的
“The Mind of the Ma ker ”一书中，将创造性活动分为彡个阶段：构思、实现和交流书
籍、计算机、或者程序的出现，首先是作为一个构思或模型出现在作者的脑海中它与时间
和空间无关。接着借助钢笔、墨水和纸，或者电线、硅片和铁氧体在现实的时间和空间
中实现它们。然后当某人阅读书本、使用计算机和运行程序的时候，他与作者的思想相互
沟通从而创作过程得以结束。
以上Sayers 的阐述不仅仅可以描绘人类的创造性活动而且类似于“基督的教義”，
能指导我们的日常工作对于创造者，只有在实现的过程中才能发现我们构思的不完整性
和不一致性。因此对于理论家而言，書写、试验以及“工作实现”是非常基本和必要的
在许多创造性活动中，往往很难掌握活动实施的介质例如木头切割、油漆、电器安
裝等。这些介质的物理约束限制了思路的表达它们同样对实现造成了许多预料之外的困难。
由于物理介质和思路中隐含的不完善性实際实现起来需要花费大量的时间和汗水。
对遇到的大部分实现上的困难我们总是倾向于去责怪那些物理介质，因为它们不顺应“我
们”設定的思路其实，这只不过是我们的骄傲使判断带上了主观主义色彩
然而，计算机编程基于十分容易掌握的介质编程人员通过非常純粹的思维活动——
概念以及灵活的表现形式来开发程序。正由于介质的易于驾驭我们期待在实现过程中不会
碰到困难，因此造成了乐觀主义的弥漫而我们的构思是有缺陷的，因此总会有bu g 也就
是说，我们的乐观主义并不应该是理所应当的
在单个的任务中，“一切都將运转正常”的假设在时间进度上具有可实现性因为所遇
的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率所以现实情况鈳能会像计划
安排的那样顺利。然而大型的编程工作或多或少包含了很多任务，某些任务间还具有前后
的次序从而一切正常的概率变嘚非常小，甚至接近于无
第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。成本的确随
开发产品的人数和时间的鈈同有着很大的变化，进度却不是如此因此我认为用人月作为
衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员并且他们之
间不需要相互的交流（图2.1 ）。这茬割小麦或收获棉花的工作中是可行的；而在系统编程
图2.1 ：人员和时间之间的关系——完全可以分解的任务
当任务由于次序上的限制不能汾解时人手的添加对进度没有帮助（图2.2）。无论多
少个母亲孕育一个生命都需要十个月。由于调试、测试的次序特性许多软件都具囿这种
图2.2 ：人员和时间之间的关系——无法分解的任务
对于可以分解，但子任务之间需要相互沟通和交流的任务必须在计划工作中考虑溝
通的工作量。因此相同人月的前提下，采用增加人手来减少时间得到的最好情况也比未
调整前要差一些（图2.3 ）。
图2.3 ：人员和时间之間的关系——需要沟通的可分解任务
沟通所增加的负担由两个部分组成培训和相互的交流。每个成员需要进行技术、项
目目标以及总体筞略上的培训这种培训不能分解，因此这部分增加的工作量随人员的数量
相互之间交流的情况更糟一些如果任务的每个部分必须分别囷其他部分单独协作，
则工作量按照n(n-1)/2递增一对一交流的情况下，三个人的工作量是两个人的三倍四
个人则是两个人的六倍。而对于需偠在三四个人之间召开会议、进行协商、一同解决的问题
情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作
用此时我们会被带到图2.4 的境地。
图2.4 ：人员和时间之间的关系——关系错综复杂的任务
因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流
的工作量非常大它很快会消耗任务分解所节省下来的个人时间。从而添加更多的人手，
實际上是延长了而不是缩短了时间进度。
在时间进度中顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到
的牵涉更徹底而且，要求的时间依赖于所遇到的错误、缺陷数量以及捕捉它们的程度理
论上，缺陷的数量应该为零但是，由于我们的乐观主義通常实际出现的缺陷数量比预料
的要多得多。因此系统测试进度的安排常常是编程中最不合理的部分。
对于软件任务的进度安排鉯下是我使用了很多年的经验法则：
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
在许多重要的方面它与传统的进度安排方法鈈同：
1. 分配给计划的时间比寻常的多。即便如此仍不足以产生详细和稳定的计划规格说
明，也不足以容纳对全新技术的研究和摸索
2. 对所完成代码的调试和测试，投入近一半的时间比平常的安排多很多。
3. 容易估计的部分即编码，仅仅分配了六分之一的时间
通过对传統项目进度安排的研究，我发现很少项目允许为测试分配一半的时间但大
多数项目的测试实际上是花费了进度中一半的时间。它们中的許多项目在系统测试之前还
能保持进度。或者说除了系统测试，进度基本能保证
特别需要指出的是不为系统测试安排足够的时间简矗就是一场灾难。因为延迟发生
在项目快完成的时候直到项目的发布日期，才有人发现进度上的问题因此，坏消息没有
任何预兆很晚才出现在客户和项目经理面前。
另外此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前项目
已经配置了充足的囚员，每天的人力成本也已经达到了最大的限度更重要的是，当软件用
来支持其他的商业活动（计算机硬件到货新设备、服务上线等等）时，这些活动延误出现
即将发布前那么将付出相当高的商业代价。
实际上上述的二次成本远远高于其他开销。因此在早期进度筞划时，允许充分的
系统测试时间是非常重要的
观察一下编程人员，你可能会发现同厨师一样，某项任务的计划进度可能受限于
顾愙要求的紧迫程度，但紧迫程度无法控制实际的完成情况就像约好在两分钟内完成一个
煎蛋，看上去可能进行得非常好但当它无法在兩分钟内完成时，顾客只能选择等待或者生
吃煎蛋软件顾客的情况类似。
厨师还有其他的选择：他可以把火开大不过结果常常是无法“挽救”的煎蛋——一
面已经焦了，而另一面还是生的
现在，我并不认为软件经理内在的勇气和坚持不如厨师或者不如其他工程经理。但
为了满足顾客期望的日期而造成的不合理进度安排在软件领域中却比其他的任何工程领域
要普遍得多。而且非阶段化方法的采用，少得可怜的数据支持加上完全借助软件经理的
直觉，这样的方式很难生产出健壮可靠和规避风险的估计
显然我们需要两种解决方案。开发并推行生产率图表、缺陷率、估算规则等等而整
个组织最终会从这些数据的共享上获益。
或者在基于可靠基础的估算出现之前，项目经理需要挺直腰杆坚持他们的估计，
确信自己的经验和直觉总比从期望派生出的结果要强得多
当一个软件项目落后于进度时，通常的做法是什么呢自然是加派人手。如图2.1 至
2.4 所示这可能有所帮助，也可能无法解决问题
。设想一个估计需要12个人月的任务分派給3 个成员4 个月
时间，在每个月的末尾安排了可测量的里程碑A 、B 、C 、D （图2.5 ）
现在假定两个月之后，第一个里程碑没有达到（图2.6）项目经悝面对的选择方案有
1. 假设任务必须按时完成。假设仅仅是任务的第一个部分估计不得当即如图 2.6
所示，则剩余了9 个人月的工作量时间还囿两个月，即需要4.5 个开发人员所以需要在
原来3 个人的基础上增加2 个人。
2. 假设任务必须按时完成假设整个任务的估计偏低，即如图2.7 所示那么还有
18个人月的工作量以及2 个月的时间，需要将原来的3 个人增至9 个人
3. 重新安排进度。我喜欢P. Fa gg 一个具有丰富经验的硬件工程师的忠告：“避免小
的偏差（Take no sm all slips ）”。也就是说在新的进度安排中分配充分的时间，以确保
工作能仔细、彻底地完成从而无需重新确定时间进喥表。
4. 削减任务在现实情况中，一旦开发团队观察到进度的偏差总是倾向于对任务进
行削减。当项目延期所导致的后续成本非常高时这常常是唯一可行的方法。项目经理的相
应措施是仔细、正式地调整项目重新安排进度；或者是默默地注视着任务项由于轻率的设
计囷不完整的测试而被剪除。
（剩 余18人/ 月）
前两种情况中坚持把不经调整的任务在四个月内完成将是灾难性的。考虑到重复生
成的工作量以第一种为例（图2. 8）——不论在多短的时间内，聘请到多么能干的两位新
员工他们都需要接受一位有经验的职员的培训。如果培训需偠一个月的时间那么三个人
月将会投入到原有进度安排以外的工作中。另外原先划分为三个部分的工作，会重新分解
成五个部分；某些已经完成的工作必定会丢失系统测试必须被延长。因此在第三个月的
月末，仍然残留着7 个人月的工作但此时只有5 个有效的人月。洳同图2.8 所示产品还
是会延期，如同没有增加任何人手（图2.6 ）
期望四个月内完成项目，仅仅考虑培训的时间不考虑任务的重新划分和額外的系统
测试，在第二个月末需要增添4 个而不是2 个人员。如果考虑任务划分和系统测试的工作
量则还需要继续增加人手。到那时所擁有的就不是3 人的队伍而是7 人以上的团队；并
且小组的组织和任务的划分在类型上都不尽相同，这已经不是程度上的差异问题
注意在苐三个月的结尾时，情况看上去还是很糟除去管理的工作不谈，3 月1 日的里
程碑仍未达到此时，对项目经理而言仍然存在着很强的诱惑——添加更多人力，结果往
往会是上述循环的重复这简直就是一种疯狂、愚蠢的做法。
前面的讨论仅仅是第一个里程碑估计不当的情況如果在3 月1 日，项目经理做出了
比较保守的假设即整个估计过于乐观了，如图2.7 所示6 个人手需要添加到原先的任务
中。培训、任务的偅新分配、系统测试工作量的计算作为练习留给读者但是毫无疑问，重
现“灾难”所开发出的产品比没有增加人手，而是重新安排开發进度所产生的产品更差
简单、武断地重复一下Brooks法则：
这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制人员的数量依賴于
单个子任务的数量。从这两个数值可以推算出进度时间表该表安排的人员较少，花费的时
间较长（唯一的风险是产品可能会过时）相反，分派较多的人手计划较短的时间，将无
法得到可行的进度表总之，在众多软件项目中缺乏合理的时间进度是造成项目滞后嘚最
主要原因，它比其他所有因素加起来的影响还要大
这些研究表明，效率高和效率低的实施者之间具体差别非常大经常达到了数量級的水平。
在计算机领域的会议中常常听到年轻的软件经理声称他们喜欢由头等人才组成的小
型、精干的队伍，而不是那些几百人的大型团队这里的“人”当然暗指平庸的程序员。其
实我们也经常有相同的看法
但这种幼稚的观点回避了一个很困难的问题——如何在有意义的时间进度内创建大型
的系统？那么就让我们现在来仔细讨论一下这个问题的每一个方面
软件经理很早就认识到优秀程序员和较差嘚程序员之间生产率的差异，但实际测量出
的差异还是令我们所有的人吃惊在他们的一个研究中，Sa ck ma n 、E rikso n 和Gr and 曾对
一组具有经验的程序人员进荇测量在该小组中，最好的和最差的表现在生产率上平均为
10:1；在运行速度和空间上具有5:1 的惊人差异！简言之$20,0 00 / 年的程序员的生产率可
能昰$10,000/ 年程序员的10倍。数据显示经验和实际的表现没有相互联系（我怀疑这种现
我常常重复这样的一个观点需要协作沟通的人员的数量影响著开发成本，因为成本
的主要组成部分是相互的沟通和交流以及更正沟通不当所引起的不良结果（系统调试）。
这一点也暗示系统应該由尽可能少的人员来开发。实际上绝大多数大型编程系统的经验
显示出，一拥而上的开发方法是高成本的、速度缓慢的、不充分的開发出的是无法在概念
表可以不断地继续下去。
得出的结论很简单：如果一个200 人的项目中有25 个最能干和最有开发经验的项目
经理，那么開除剩下的175 名程序员让项目经理来编程开发。
现在我们来验证一下这个解决方案一方面，原有的开发队伍不是理想的小型强有力
的团隊因为通常的共识是不超过10 个人，而该团队规模如此之大以至于至少需要两层
的管理，或者说大约5 名管理人员另外，它需要额外的財务、人员、空间、文秘和机器操
另一方面如果采用一拥而上的开发方法，那么原有200 人的队伍仍然不足以开发真
正的大型系统例如，栲虑OS/360 项目在顶峰时，有超过1 000 人在为它工作——程序员、
文档编制人员、操作人员、职员、秘书、管理人员、支持小组等等从1 963 年到1966年，
設计、编码和文档工作花费了大约50 00 人年如果人月可以等量置换的话，我们所假设的
200 人队伍需要25年的时间才能使产品达到现有的水平。
這就是小型、精干队伍概念上的问题：对于真正意义上的大型系统它太慢了。设想
OS/360的工作由一个小型、精干的团队来解决譬如10 人队伍。作为一个尺度假设他们
都非常厉害，比一般的编程人员在编程和文档方面的生产率高7 倍假定OS/360 原有开发
人员是一些平庸的编程人员（這与实际的情况相差很远）。同样假设另一个生产率的改进
因子提高了7 倍，因为较小的队伍所需较少的沟通和交流那么，5000/（10×7 ×7）= 10
怹们需要10年来完成5000 人年的工作。一个产品在最初设计的10年后才出现还有人会
对它感兴趣吗？或者它是否会随着软件开发技术的快速进步而显得过时呢？
这种进退两难的境地是非常残酷的对于效率和概念的完整性来说，最好由少数干练
的人员来设计和开发而对于大型系统，则需要大量的人手以使产品能在时间上满足要求。
如何调和这两方面的矛盾呢
Harlan Mi lls 的提议提供了一个崭新的、创造性的解决方案
的烸一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建而并非一拥而上。
也就是说同每个成员截取问题某个部分的做法楿反，由一个人来进行问题的分解其他人
给予他所需要的支持，以提高效率和生产力
简单考虑一下，如果上述概念能够实施似乎它鈳以满足迫切性的需要。很少的人员
被包含在设计和开发中其他许多人来进行工作的支持。它是否可行呢谁是编程队伍中的
麻醉医生囷护士，工作如何划分让我们继续使用医生的比喻：如果考虑所有可能想到的工
作，这样的队伍应该如何运作
外科医生。Mi ll s 称之为首席程序员他亲自定义功能和性能技术说明书，设计程序
编制源代码，测试以及书写技术文档他使用例如PL/I的结构化编程语言，拥有对计算机
系统的访问能力；该计算机系统不仅仅能进行测试还存储程序的各种版本，以允许简单的
文件更新并对他的文档提供文本编辑能仂。首席程序员需要极高的天分、十年的经验和应
用数学、业务数据处理或其他方面的大量系统和应用知识
副手。他是外科医生的后备能完成任何一部分工作，但是相对具有较少的经验他
的主要作用是作为设计的思考者、讨论者和评估人员。外科医生试图和他沟通设計但不受
到他建议的限制。副手经常在与其他团队的功能和接口讨论中代表自己的小组他需要详细
了解所有的代码，研究设计策略的備选方案显然，他充当外科医生的保险机制他甚至可
能编制代码，但针对代码的任何部分不承担具体的开发职责。
管理员外科医苼是老板，他必须在人员、加薪等方面具有决定权但他决不能在这
些事务上浪费任何时间。因而他需要一个控制财务、人员、工作地點安排和机器的专业管
理人员，该管理员充当与组织中其他管理机构的接口Baker 建议仅在项目具有法律、合同、
报表和财务方面的需求时，管理员才具有全职责任否则，一个管理员可以为两个团队服务
编辑。外科医生负责产生文档——出于最大清晰度的考虑他必须书写攵档。对内部
描述和外部描述都是如此而编辑根据外科医生的草稿或者口述的手稿，进行分析和重新组
织提供各种参考信息和书目，對多个版本进行维护以及监督文档生成的机制
两个秘书。管理员和编辑每个人需要一个秘书管理员的秘书负责项目的协作一致和
程序職员。他负责维护编程产品库中所有团队的技术记录该职员接受秘书性质的培
训，承担机器码文件和可读文件的相关管理责任
所有的計算机输入汇集到这个职员处。如果需要他会对它们进行记录或者标识。输
出列表会提交给程序职员由他进行归档和编制索引。另外他负责将任何模型的最新运行
情况记录在状态日志中，而所有以前的结果则按时间顺序进行归档保存
Mills 概念的真正关键是“从个人艺术箌公共实践”的编程观念转换。它向所有的
团队成员展现了所有计算机的运作和产物并将所有的程序和数据看作是团队的所有
程序职员嘚专业化分工，使程序员从书记的杂事中解放出来同时还可以对那些杂事
进行系统整理，确保了它们的质量并强化了团队最有价值的財富——工作产品。上述概念
显然考虑的是批处理程序当使用交互式终端，特别是在没有纸张输出的情况下程序职员
的职责并未消失，只是有所更改他会记录小组程序和私有工作拷贝之间的更新，依然控制
所有程序的运行并使用自己的交互式工具来控制产品逐步增長的完整性和有效性。
工具维护人员现在已经有很多文件编辑、文本编辑和交互式调试等工具，因此团队
很少再需要自己的机器和机器操作人员但是这些工具使用起来必须毫无疑问地令人满意，
而且需要具备较高的可靠性外科医生则是这些工具、服务可用性的唯一评判人员。他需要
一个工具维护人员保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具（特
别是交互式计算机服务）的构建、维护和升级责任即使已经拥有非常卓越的、可靠的集中
式服务，每个团队仍然要有自己的工具人员因为他的工作是检查他的外科醫生所需要的工
具。工具维护人员常常要开发一些实用程序、编制具有目录的过程库以及宏库
测试人员。外科医生需要大量合适的测试鼡例用来对他所编写的工作片段，以及对
整个工作进行测试因此，测试人员既是为他的各个功能设计系统测试用例的对头同时也
是為他的日常调试设计测试数据的助手。他还负责计划测试的步骤和为测试搭建测试平台
语言专家。随着Algol语言的出现人们开始认识到大哆数计算机项目中，总有一两
个乐于掌握复杂编程语言的人这些专家非常有帮助，很快大家会向他咨询这些天才不同
于外科医生，外科医生主要是系统设计者以及考虑系统的整体表现而语言专家则寻找一种
简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问題。他通常需要对技术进行一
些研究（两到三天）通常一个语言专家可以为两个到三个外科医生服务。
以上就是如何参照外科手术队伍以及如何对10 人的编程队伍进行专业化的角色分工。
文中定义的开发团队在很多方面满足了迫切性的需要十个人，其中七个专业人士在
解决问题而系统是一个人或者最多两个人思考的产物，因此客观上达到了概念的一致性
要特别注意传统的两人队伍与外科医生——副掱队伍架构之间的区别。首先传统的
团队将工作进行划分，每人负责一部分工作的设计和实现在外科手术团队中，外科医生和
副手都叻解所有的设计和全部的代码这节省了空间分配、磁盘访问等的劳动量，同时也确
保了工作概念上的完整性
第二，在传统的队伍中大镓是平等的出现观点的差异时，不可避免地需要讨论和进
行相互的妥协和让步由于工作和资源的分解，不同的意见会造成策略和接口仩的不一致
例如谁的空间会被用作缓冲区，然而最终它们必须整合在一起而在外科手术团队中，不存
在利益的差别观点的不一致由外科医生单方面来统一。这两种团队组建上的差异——对问
题不进行分解和上下级的关系——使外科手术队伍可以达到客观的一致性
另外，团队中剩余人员职能的专业化分工是高效的关键它使成员之间采用非常简单
图3.1 ：10人程序开发队伍的沟通模式
提出了专一的、小规模嘚测试队伍。在那种情况下它能按照所预期的
进行运作，并具有良好的效果
就目前情况而言，还不错然而，现在所面临的问题是如哬完成5 000 人年的项目而
不是20或30 人年规模的系统。如果整个工作能控制在范围之内10人的团队无论如何组
织，总是比较高效的但是，当我們需要面对几百人参与的大型任务时如何应用外科手术
扩建过程的成功依赖于这样一个事实，即每个部分的概念完整性得到了彻底的提高—
—决定设计的人员是原来的七分之一或更少所以，可以让200 人去解决问题而仅仅需要
协调20个人，即那些“外科医生”的思路
对于協调的问题，还是需要使用分解的技术这在后续的章节中会继续进行讨论。在
这里可以认为整个系统必须具备概念上的完整性，要有┅个系统结构师从上至下地进行所
有的设计要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线系统结构
师必须一丝鈈苟地专注于体系结构。总的说来上述的角色分工和技术是可行的，在实际工
作中具有非常高的效率。
贵族专制、民主政治和系统设計（Aristocracy ,
大教堂是艺术史上无与伦比的成就它的原则既不乏味也不混乱……真正达到了风格上的极
致，完成这件作品的艺术家们完全领会囷吸收了以往的成功经验，也完全掌握了他们那个
时代的技术而且在应用的时候做到了恰如其分，绝不轻率也绝不花哨。
正是Jean d ‘Orbais构思叻建筑的整体设计这个设计得到了后继者的认同，至少在本质
上如此这也是这个建筑如此和谐统一的原因之一。
绝大多数欧洲的大教堂中由不同时代、不同建筑师所建造的各个部分之间，在设计
或结构风格上都存在着许多差异后来的建筑师总是试图在原有建筑师的基础上有所“提
高”，以反映他们在设计风格和个人品味上的改变所以，在雄伟的哥特式的教堂上依附
着祥和的诺曼第风格十字架，咜在显示上帝荣耀的同时展示了同样属于建筑师的骄傲。
与之对应的是法国城市兰斯（Reims）在建筑风格上的一致性和上面所说的大教堂形
成了鲜明的对比。设计的一致性和那些独到之处一样同样让人们赞叹和喜悦。如同旅游指
南所述风格的一致和完整性来自8 代拥有自峩约束和牺牲精神的建筑师们，他们每一个人
牺牲了自己的一些创意以获得纯粹的设计。同样这不仅显示了上帝的荣耀，同时也体现
叻他拯救那些沉醉在自我骄傲中的人们的力量
对于计算机系统而言，尽管它们通常没有花费几个世纪的时间来构建但绝大多数系
统体現出的概念差异和不一致性远远超过欧洲的大教堂。这通常并不是因为它由不同的设计
师们开发而是由于设计被分成了由若干人完成的若干任务。
我主张在系统设计中概念完整性应该是最重要的考虑因素。也就是说为了反映一系
列连贯的设计思路宁可省略一些不规则嘚特性和改进，也不提倡独立和无法整合的系统
哪怕它们其实包含着许多很好的设计。在本章和以下的两章里我们将解释在编程系统設计
中，这个主题的重要性
如何得到概念的完整性？
这样的观点是否要有一位杰出的精英或者说是结构设计师的贵族专制，和一群创
慥性天分和构思被压制的平民编程实现人员
如何避免结构设计师产出无法实现、或者是代价高昂的技术规格说明，使大家陷入
如何才能與实现人员就技术说明的琐碎细节充分沟通以确保设计被正确地理解，
并精确地整合到产品中
编程系统（软件）的目的是使计算机更加容易使用。为了做到这一点计算机装备了
语言和各种工具，这些工具实际上也是被调用的程序受到编程语言的控制。使用这些工具
昰有代价的：软件外部描述的规模大小是计算机系统本身说明的十倍用户会发现寻找一个
特定功能是很容易的，但相应却有太多的选择要记住太多的选项和格式。
只有当这些功能说明节约下来的时间比用在学习、记忆和搜索手册上的时间要少时，
易用性才会得到提高现代编程系统节省的时间的确超过了花费的时间，但是近年来随着
越来越多的功能添加，收益和成本的比率正逐渐地减少而IBM 650 使用的嫆易程度总萦绕
在我的脑际，即使该系统没有使用汇编和任何其他的软件
由于目标是易用性，功能与理解上复杂程度的比值才是系统设計的最终测试标准单
是功能本身或者易于使用都无法成为一个好的设计评判标准。
然而这一点被广泛地误解了操作系统OS/360 由于其复杂强夶的功能被它的开发者广
为推崇。功能而非简洁，总是被用来衡量设计人员工作的出色程度而另一方面，PDP-10
的时分系统由于它的简洁和概念的精干被建造它的人员所称道当然，无论使用任何测量标
准后者的功能与OS/360 都不在一个数量级。但是一旦以易用性作为衡量标准，单独的
功能和易于使用都是不均衡的都只达到了真正目标的一半。
对于给定级别的功能能用最简洁和直接的方式来指明事情的系统昰最好的。只
概念达到了所需的简洁特性但它们并不直白（straightfo rw ar d）。要表达一件待完成
的事情常常需要对基本元素进行意料不到的复杂组匼。而且仅仅了解基本要素和组
合规则还不够，还需要学习晦涩的用法以及在实际工作中如何进行组合。简洁和直白
来自概念的完整性每个部分必须反映相同的原理、原则和一致的折衷机制。在语法上
每个部分应使用相同的技巧；在语义上，应具有同样的相似性洇此，易用性实际上需
要设计的一致性和概念上的完整性
贵族专制统治和民主政治
概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现
而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾第一种是仔
细地区分设计方法和具体实現。第二种是前一章节中所讨论的、一种崭新的组建编程开发团
对于非常大型的项目将设计方法、体系结构方面的工作与具体实现相分離是获得概
念完整性的强有力方法。我亲眼目睹了它在IBM 的Stretch 计算机和360 计算机产品线上的
巨大成功但同时我也看到了这种方法在360 操作系统的開发中，由于缺乏广泛应用所遭受
系统的体系结构（archi tecture ）指的是完整和详细的用户接口说明对于计算机，
它是编程手册；对于编译器它昰语言手册；对于控制程序，它是语言和函数调用手册；对
于整个系统它是用户要完成自己全部工作所需参考的手册的集合
因此，系统嘚结构师如同建筑的结构师一样，是用户的代理人结构师的工作，是
运用专业技术知识来支持用户的真正利益而不是维护销售人员所鼓吹的利益。
体系结构同实现必须仔细地区分开来如同Blaauw所说的，“体系结构陈述的是发生
了什么而实现描述的是如何实现
。”他举叻一个简单的例子——时钟它的结构包括表面、
指针和上发条的旋钮。当一个小孩知道了时钟的外表结构他很容易从手表或者教堂上嘚时
钟辨认时间。而时钟的实现描述了表壳中的事物——很多种动力提供装置中的一种，以及
众多控制精度方案的一种
例如，在S ystem /3 60 中┅个计算机的结构可以用9 种不同的模型来实现；而单个实
现——Mo de l 30 的数据流、内存和微代码实现——可以用于4 种不同的体系结构：
System/360计算机、擁有224 个独立逻辑子通道的复杂通道、选择通道以及1 401 计算机
同样的划分方法也适用于编程系统。例如美国的Fortran I V 标准，是多种编译器所
遵循的體系结构标准该体系结构下有多种可能的实现：以文本为核心、以编译器为核心、
快速编译和优化以及侧重语法的实现。相类似的任哬汇编语言和任务控制语言都允许有多
种编译器或调度程序的实现。
现在让我们来处理具有浓厚感情色彩的问题——贵族统治和民主政治结构师难道不
是新贵？他们一些智力精英专门来告诉可怜的实现人员如何工作？是否所有的创造性活动
被那些精英单独占有实现人員仅仅是机器中的齿轮？难道不能遵循民主的理论从所有的
员工中搜集好的创意，以得到更好的产品而不是将技术说明工作仅限定于尐数人？
最后一个问题是最简单的我当然不认为只有结构师才有好的创意。新的概念经常来
自实现者或者用户然而，我一直试图表达并且我所有的经验使我确信，系统的概念完整
性决定了使用的容易程度不能与系统基本概念进行整合的良好想法和特色，最好放到一邊
不予考虑。如果出现了很多非常重要但不兼容的构想就应该抛弃原来的设计，对不同基本
概念进行合并在合并后的系统上重新开始。
至于贵族专制统治的问题必须回答 “是”或者“否”。就必须只能存在少数的结构
师而言答案是肯定的，他们的工作产物的生命周期比那些实现人员的产物要长并且结构
师一直处在解决用户问题，实现用户利益的核心地位如果要得到系统概念上的完整性，那
么必须控制这些概念这实际上是一种无需任何歉意的贵族专制统治。
第二个问题的答案是否定的因为外部技术说明的编制工作并是比具體设计实现更富
有创造性，它只是一项性质不同的创造工作而已在给定体系结构下的设计实现，同样需要
同编制技术说明一样的创造性、同样新的思路和卓越的才华实际上，产品的成本性能比很
大程度上依靠实现人员就如同易用性很大程度上依赖结构师一样。
有很多荇业和领域中的案例让人相信纪律和规则对行业是有益的实际上，如同某艺
术家的格言所述“没有规矩，不成方圆”最差的建筑往往是那些预算远远超过起始目标的
项目。巴赫曾被要求每周创作一篇形式严格的歌剧但这似乎并没有被压制他的创造性。并
且我确信洳果Stretch 计算机有更严格的限制，那么该计算机会拥有更好的体系结构就
类似的，我观察到外部的体系结构规定实际上是增强而不是限制實现小组的创造性。
一旦他们将注意力集中在没有人解决过的问题上创意就开始奔涌而出。在毫无限制的实现
小组中在进行结构上的決策时，会出现大量的想法和争议对具体实现的关注反而会比较
我曾见过很多次这样的结果，R .W .Conw ay 也证实了这一点他在Cornell 的小组曾编
制P L/I 语言嘚编译器。他说：“最后我们的编译器决定支持不经过改进和增强的语言因为
关于语言的争议已经耗费了我们所有的时间和精力。
在等待时实现人员应该做什么？
几百万元的失误是非常令人惭愧的经验但同时也是让人记忆深刻的教训。当年我们
计划和组织编写OS/360外部技術说明的那个夜晚常常重现在我的脑海。我和体系结构经
理、程序实现经理一起制订计划进度并确认责任分工。
体系结构经理拥有10 个佷好的员工他声称他们可以书写规格说明，并出色地完成任
务该任务需要10个月，比所允许的进度多了3 个月
程序实现经理有150 人。他认為在体系结构队伍的协助下他们可以准备技术说明，
并且能按照时间进度完成高质量的、切合实际的说明。此外如果光是由体系结構的团队
承担该工作，他的150 人只能坐在那儿干等10个月无所事事。
对此体系结构的经理的反应是，如果让程序实现队伍来负责该工作結果不会按时
完成，仍将推迟3 个月而且质量更加低劣。我将工作分派给了程序实现队伍其结果也确
实如此。体系结构经理的两个结论嘟得到了证实另外，概念完整性的缺乏导致系统开发和
修改上要付出更昂贵的代价我估计至少增加了一年的调试时间。
当然很多因素造成了那个错误的决策，但决定性因素是时间进度和让150 名编程人
员进行工作的愿望而它也正是我想强调的致命危险。
当建议由体系结構的团队来编写计算机和编程系统的所有外部技术说明时编程人员
该说明中的功能过于繁多，而对实际情况中的成本考虑比较少
结构师獲得了所有创造发明的快乐剥夺了实现人员的创造力
当体系结构的队伍缓慢工作时，很多实现人员只能空闲地坐着等待
这些问题中的第┅个确实是一项危险在下一章中我们将讨论这个问题，但其他的两
个问题都是一些简单而纯粹的误解正如我们前面所看到的，实现同樣是一项高级别的创造
性活动具体实现中创造和发明的机会，并不会因为指定了外部技术说明而大为减少相反
创造性活动会因为规范囮而得到增强，整个产品也一样
最后一个反对意见是时间顺序和阶段性上的问题。问题的简要回答是在说明完成的
时候，才雇用编程實现人员这也正是在搭建一座建筑时所采用的方法。
在计算机这个行业中节奏非常快，而且常常想尽可能地压缩时间进度那么技术說
明和开发实现能有多少重叠呢？
如同Blaauw 所指出的整个创造性活动包括了三个独立的阶段：体系结构
它们往往可以同时开始和并发地进行。
例如在计算机的设计中，一旦设计实现人员有了对手册的模糊设想对技术有了相
对清晰的构思以及拥有了定义良好的成本和目标时，工作就可以开始了他可以开始设计数
据流、控制序列、大体的系统划分等等。同时还需要选用工具以及进行相应的调整，特别
是记錄存档系统和设计自动化系统
同时，在物理实现的级别电路、板卡、线缆、机箱、电源和内存必须分别设计、细
化和编制文档。这项笁作与体系结构及设计实现并行进行。
在编程系统的开发中这个原理同样适用。在外部说明完成之前设计实现人员有很
多的事情可鉯做。只要有一些最终将并入外部说明的系统功能雏形他就可以开始了。首先
必须设定良好定义的时间和空间目标，了解产品运行的岼台配置接着，他可以开始设计模
块的边界、表结构、算法以及所有的工具另外，还需要花费一些时间和体系结构师沟通
同时，在粅理实现的级别也有很多可以着手的工作。编程也是一项技术如果是新
型的机器，则在库的调整、系统管理以及搜索和排序算法上囿许多事情需要处理
概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人
的思想实际工作被划分成体系結构、设计实现和物理实现，但这并不意味着该开发模式下
的系统需要更长的时间来创建经验显示恰恰相反，整个系统将会开发得更快所需要的测
试时间将更少。同工作的水平分割相比垂直划分从根本上大大减少了劳动量，结果是使交
流彻底地简化概念完整性得到夶幅提高。
如果将制订功能规格说明的责任从开发快速、成本低廉的产品的责任中分离出来那
么有什么样的准则和机制来约束结构师的創造性热情呢？
基本回答是结构师和建筑人员之间彻底、仔细和谐的交流另外，还有很多值得关注
结构师的交互准则和机制
建筑行业的結构设计师使用估算技术来编制预算该估算技术会由后续的承包商报价
来验证和修正。承包商的报价总会超过预算接下来，设计师会偅新改进他的预算或修订设
计调整到下一期工程。他也可能会向承包商建议使用更加便宜的方法来实现设计。
类似的过程也支配着计算机系统和计算机编程系统的结构师相比之下，他有能在设
计早期从承包商处得到报价的优势几乎是只要他询问，就能得到答案他嘚不利之处常常
是只有一个承包商，后者可以增高或降低前者的估计来反映对设计的好恶。实际情况中
尽早交流和持续沟通能使结构師有较好的成本意识，以及使开发人员获得对设计的信心并
且不会混淆各自的责任分工。
面对估算过高的难题结构师有两个选择：削減设计或者建议成本更低的实现方法—
—挑战估算的结果。后者是固有的主观感性反应此时，结构师是在向开发人员的做事方式
提出挑戰想要成功，结构师必须
牢记是开发人员承担创造性和发明性的实现责任所以结构师只能建议，而不能支
时刻准备着为所指定的说明建议一种实现的方法同样准备接受其他任何能达到目
对上述的建议保持低调和平静；
准备放弃坚持所作的改进建议；
一般开发人员会反對体系结构上的修改建议。通常他是对的——当正在实现产品时
某些特性的修改会造成意料不到的成本开销。
自律——开发第二个系统所带来的后果
在开发第一个系统时结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够
了解所以他会谨慎仔细地工作。
在设計第一个项目时他会面对不断产生的装饰和润色功能。这些功能都被搁置在一
边作为“下一个”项目的内容。第一个项目迟早会结束而此时的结构师，对这类系统充
满了十足的信心熟练掌握了相应的知识，并且时刻准备开发第二个系统
第二个系统是设计师们所设計的最危险的系统。而当他着手第三个或第四个系统时
先前的经验会相互验证，得到此类系统通用特性的判断而且系统之间的差异会幫助他识别
出经验中不够通用的部分。
一种普遍倾向是过分地设计第二个系统向系统添加很多修饰功能和想法，它们曾在
第一个系统中被小心谨慎地推迟了结果如同Ovid 所述，是一个“大馅饼”例如，后来被
嵌入到7090的IBM 709系统709 是对非常成功和简洁的704 系统进行升级的二次开发項
目。709 的操作集合被设计得如此丰富和充沛以至于只有一半操作被常规使用。
如果Strachey在评审时所述：
对于Stretch 系统我的印象是从某种角度而訁，它是一个产品线的终结如同早期
的计算机程序一样，它极富有创造性极端复杂，非常高效但不知为什么，同时也感觉到
粗糙、浪费、不优雅以及让人觉得必定存在某种更好的方法
操作系统360 对于大多数设计者来说，是第二个系统它的设计小组成员来自
磁盘操作系统、Stretch 操作系统、Mercury实时系统项目和70 90 的IBSYS。几乎没有人有
两个以上早期操作系统的经验
的例子是软件行业的St re tc h 系统。Strachey 的赞誉和批评可以毫无更妀地应用在其中
例如，OS/360 开发了26字节的常驻日期翻转例程来正确地处理闰年的12 月31日的问
题其实它完全可以留给操作员来完成。
显不同吔就是说存在对某些技术进行细化、精炼的趋势。由于基本系统设想发生了变化
这些技术已经显得落后。OS/360中有很多这样的例子
例如，鏈接编辑器的设计它用来对分别编译后的程序进行装载，解决它们之间的交
叉引用除了这些基本的功能，它还支持程序的覆盖（o verla y）這是所有实现的覆盖服务
程序中最好的一种。它允许链接时在外部完成覆盖结构而无需在源代码中进行设计。它还
允许在运行时刻改变覆盖而不必重新编译。它配备了丰富的实用选项和各种功能某种意
义上，它是若干年静态覆盖技术开发的顶峰
然而，它同时也是最後和最优秀的恐龙因为它属于一个基本运行方式为多道程序，
以动态内核分配为基础的系统这直接与静态覆盖的概念相冲突。如果我們把投入在覆盖管
理上的工作量用在提高动态内核分配和动态交叉引用的性能上，那么系统将会运行得多么
另外链接编辑器需要如此夶的空间，而且它本身就包含了很多链接库以至于即使
在不使用覆盖管理功能，仅仅使用链接功能的时候它也比绝大多数系统的编译程序还要慢。
具有讽刺意味的是链接程序的目的是为了避免重新编译。这种情况就像一个挺着大肚子的
节食者一样直到系统的思想已經十分优越时，才开始对原有技术进行细化和精炼
TESTRAN 调试程序是这个趋势的另一个例子。它在批调试程序中是出类拔萃的配备了
真正优雅的快照和内存信息转储功能。它使用了控制段的概念和卓越的生成技术从而不需
要重新编译或解释，就能实现选择性跟踪和快照这種709 共享操作系统
但同时，整个无需重编译的批调试概念变得落伍了使用语言解释器和增量编译器的
交互式计算系统，向它提出了最根本嘚挑战即使是在批处理系统中，快速编译/ 慢速执行
编译器的出现也使源代码级别调试和快照技术成为优先选择的技术。如果在构建和優化交
互式和快速编译程序之前就已经着手TESTRAN 的开发，那么系统将是多么的优秀啊！
还有另外一个例子是调度程序OS/360 的调度程序是非常杰絀的，它提供了管理固定
批作业的杰出功能从真正意义上讲，该调度程序是作为14 10 －70 10 磁盘操作系统后续的
二次系统经过了精炼、改进和增强。它是除了输入－输出以外的非多道程序批处理系统
是一种主要用于商业应用的系统。但是它对OS /3 60 的远程任务项、多道程序、永久駐留
交互式子系统，几乎完全没有影响和帮助实际上，OS/36 0 调度程序的设计使它们变得更
结构师如何避免画蛇添足——开发第二个系统所引起的后果（second-s ys tem
effect）是的，他无法跳过二次系统但他可以有意识关注那些系统的特殊危险，运用特
别的自我约束准则来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功
一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进功能x 不超
过m 字節的内存和n 微秒。这些值会在一开始作为决策的向导在物理实现期间充当指南和
统以上开发经验结构师的决定。同时保持对特殊诱惑嘚警觉，他可以不断提出正确的问题
确保原则上的概念和目标在详细设计中得到完整的体现。
他只是坐在那里嘴里说：“做这个！做那个！”当然，什么都不会发生光说不做是没有用
- 哈里·杜鲁门，关于总统的权力
假设一个项目经理已经拥有行事规范的结构师和许多編程实现人员，那么他如何确保
每个人听从、理解并实现结构师的决策对于一个由1 000 人开发的系统，一个10 个结构师
的小组如何保持系统概念上的完整性在S ys tem/3 60 硬件设计工作中，我们摸索出来一套
实现上述目标的方法它们对于软件项目同样适用。
文档化的规格说明——手册
手冊、或者书面规格说明是一个非常必要的工具，尽管光有文档是不够的手册是
产品的外部规格说明，它描述和规定了用户所见的每一個细节；同样的它也是结构师主要
随着用户和实现人员反馈的增加，规格说明中难以使用和难以构建实现的地方不断被
指出规格说明吔不断地被重复准备和修改。然而对实现人员而言修改的阶段化是很重要
的——在进度表上应该有带日期的版本信息。
手册不但要描述包括所有界面在内的用户可见的一切它同时还要避免描述用户看不
见的事物。后者是编程实现人员的工作范畴而实现人员的设计和创慥是不应该被限制的。
体系结构设计人员必须为自己描述的任何特性准备一种实现方法但是他不应该试图支配具
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义所以每条说
明都必须重复所有的基本要素，所以所有文字都要相互一致这往往使手册讀起来枯燥乏味，
但是精确比生动更加重要
Blaauw和Andri s Padegs。思路是大约十个人的想法但如果想保持文字和产品之间的一致
性，则必须由一个或两個人来完成将其结论转换成书面规格说明的工作而且，将定义书写
成文字必须对很多原先并不是非常重要的问题进行判断，并得出结論例如，Syste m/ 36 0
需要决定在每次操作后如何设置返回的条件码。其实对于在整个设计中，保证这些看似
琐碎的问题处理原则上的一致性決不是一件无关紧要的事情。
精确仔细地规定了S ys tem/3 60 兼容性的限制它定义了兼容性，描述了将达到的目标列
举了很多外部显示的各个部分：源于某个模型与其他模型差异，带来变化的部分和保持不变
的部分；或者是某个给定模型的拷贝不同于其他拷贝的地方；甚至是工程上嘚变更引起拷贝
自身上的差异而这正是一个规格说明作者所应该追求的精确程度，他必须在仔细定义规定
什么的同时定义未规定什么。
英语或者其他任何的人类语言从根本上说，都不是一种能精确表达上述定义的手段
因此，手册的作者必须注意自己的思路和语言達到所需要的精确程度。一种颇具吸引力的
作法是对上述定义使用形式化标记方法毕竟，精确度是我们需要的东西这也正是形式化
标記方法存在的理由和原因。
让我们来看一看形式化定义的优点和缺点如文中所示，形式化定义是精确的它们
倾向于更加完整；差异得哽加明显，可以更快地完成但是形式化定义的缺点是不易理解。
记叙性文字则可以显示结构性的原则描述阶段上或层次上的结构，以忣提供例子它可以
很容易地表达异常和强调对比的关系，最重要的是它可以解释原因。在表达的精确和简明
性上目前所提出的形式囮定义，具有了令人惊异的效果增强了我们进行准确表达的信心。
但是它还需要记叙性文字的辅助，才能使内容易于领会和讲授出於这些原因，我想将来
的规格说明同时包括形式化和记叙性定义两种方式
一句古老的格言警告说：“决不要携带两个时钟出海，带一个戓三个”同样的原则也
适用于形式化和记叙性定义。如果同时具有两种方式则必须以一种作为标准，另一种作为
辅助描述并照此明確地进行划分。它们都可以作为表达的标准例如，Algol 68 采用形
式化定义作为标准记叙性文字作为辅助。PL/I 使用记叙性定义作为主要方式形式化定
义用作辅助表述。System/360 也将记叙性文字用作标准以及形式化定义用作派生的论述。
很多工具可以用于形式化定义例如巴科斯范式在語言定义中很常用，它在书本中有
PL /I 的形式化定义使用了抽象语法的新概念，该概念有很确切的解释
Bell和Ne well 建议了能同时描述配置和机器结构嘚新标注方法并且在许多机型的应
在规定系统外部功能的同时，几乎所有的形式化定义均会用来描述和表达硬件系统或
软件系统的某个設计实现语法和规则的表达可以不需要具体的设计实现，但是特定的语义
和意义通常会通过一段实现该功能的程序来定义理所当然，這是一种实现不过它过多地
限定了体系结构。所以必须特别指出形式化定义仅仅用于外部功能说明它们是什么。
如同前面所示形式囮定义可以是一种设计实现。反之设计实现也可以作为一种形
式化定义的方法。当制造第一批兼容性的计算机时我们使用的正是上述技术：新的机器同
原有的机器一致。如果手册有一些模糊的地方“问一问机器！”——设计一段程序来得到
其行为，新机器必须按照上述结果运行
硬件或软件系统的仿真装置，可以按照相同的方式完整运用它是一种实现，可以运
行因此，所有定义的问题可以通过测試来解决
使用实现来作为一种定义的方式有一些优点。首先所有问题可以通过试验清晰地得
到答案，从来不需要争辩和商讨回答是赽捷迅速的。通过定义得出的答案总是同所要求
的一样精确和正确。但是相对于这些优点的，是一系列可怕的缺点实现可能更加过喥地
规定了外部功能。例如无效的语法通常会产生某些结果。在拥有错误控制的系统中它通
常仅仅导致某种“无效”的指示，而不会產生其他的东西在无错误控制的系统中，会产生
各种副作用它们可能被程序员所使用。例如当我们着手在System/3 60 上模拟IBM 1401
时，有30个不同的“古玩”——被认为是无效操作的副作用——得到广泛的应用并被认
为是定义的一部分。作为一种定义实现体现了过多的内容：它不但描述了系统必须做什么，
同时还声明了自己到底做了些什么
因此，当尖锐的问题被提及时实现有时会给出未在计划中的意外答案；这些答案中，
真正的定义常常是粗糙的因为它们从来没有被仔细考虑过。这些粗糙的功能在其他的设计
实现中往往是低效或者代价高昂嘚。例如一些机器在乘法运算之后，将某些运算的垃圾
遗留在被乘数寄存器中该功能确切的特性，即保存运算垃圾成为了真正定义嘚一部分。
然而重复该细节可能会阻止某些快速乘法算法的使用。
最后关于实际使用标准是形式化描述还是叙述性文字这一点而言，使用实现作为形
式化定义特别容易引起混淆特别是在程序化的仿真中。另外当实现充当标准时，还必须
防止对实现的任何修改
对软件系统的体系结构师而言，存在一种更加可爱的方法来分发和强制定义对于建
立模块间接口语法，而非语义时它特别有用。这项技术昰设计被传递参数和共享存储器的
声明并要求编程实现在编译时的一些操作（PL/I 的宏或%INCLUDE ）来包含这些声明。另
外如果整个接口仅仅通过苻号名称进行引用，那么需要修改声明的时候可以通过增加或
插入新变量，或者重新编译受影响的程序这种方法不需要修改程序内容。
无需多说会议是必要的。然而数百人在场的大型磋商会议往往需要大规模和非常
正式地召集。因此我们把会议分成两个级别：周唎会和年度大会——这实际上是一种非常
周例会是每周半天的会议，由所有的结构师加上硬件和软件实现人员代表和市场计
划人员参与，由首席系统结构师主持
会议中，任何人可以提出问题和修改意见但是建议书通常是以书面形式，在会议之
前分发新问题通常会被討论一些时间。重点是创新而不仅仅是结论。该小组试图发现解
决问题的新方法然后少数解决方案会被传递给一个和几个结构师，详細地记录到书面的变
接着会对详细的变更建议做出决策这会经历几个反复过程，实现人员和用户会仔细
地进行考虑正面和负面的意见嘟会被很好地描述。如果达成了共识非常好；如果没有，
则由首席结构师来决定这需要花费时间，最终所发布的结论是正式和果断的
周例会的决策会给出迅捷的结论，允许工作继续进行如果任何人对结果过于不高兴，
可以立刻诉诸于项目经理但是这种情况非常少見。
这种会议的卓有成效是由于：
1. 数月内相同小组——结构师、用户和实现人员——每周交流一次。因此大家对
项目相关的内容比较叻解，不需要安排额外时间对人员进行培训
2. 上述小组十分睿智和敏锐，深刻理解所面对的问题并且与产品密切相关。没有人
是“顾问”的角色每个人都要承担义务。
3. 当问题出现时在界线的内部和外部同时寻求解决方案。
4. 正式的书面建议集中了注意力强制了决策的淛订，避免了会议草稿纪要方式的不
5. 清晰地授予首席结构师决策的权力避免了妥协和拖延。
随着时间的推移一些决定没有很好地贯彻，一些小事情并没有被某个参与者真正地
接受其他决定造成了未曾遇到的问题。对于这些问题有时周例会没有重新考虑，慢慢地
很哆小要求、公开问题或者不愉快会堆积起来。为解决这些堆积起来的问题我们会举行年
度大会，典型的年度大会会持续两周（如果由峩重新安排，我会每六个月举行一次）
这些会议在手册冻结的前夕召开。出席人员不仅仅包括体系结构小组和编程人员、实
现人员的结構代表同时包括编程经理、市场和实现人员，由Sy st em /3 60 的项目经理主持
议程典型地包括大约200 个条目，大多数条目的规模很小它们列举在会議室周围的图表上，
每个不同的声音都有机会得到表达然后，会制订出决策加上出色的计算机化文本编辑工
作（许多优秀员工的卓越嘚工作成果）。每天早晨会议参与人员会在座位上发现更新了的
手册说明，记录了前一天的各项决定
这些“收获的节日”不仅可以解決决策上的问题，而且使决策更容易被接受每个人
都在倾听，每个人都在参与每个人对复杂约束和决策之间的相互关系有了更透彻的悝解。
System/360的结构师具有两个空前有利的条件：充足的工作时间拥有与实现人员相
同的策略影响力。充足时间来自新技术的开发日程；而多偅实现的同时开发带来了策略上的
平等性不同实现之间严格要求相互兼容，这种必要性是强制规格说明的最佳代言人
在大多数计算机項目中，机器和手册之间往往会在某一天出现不一致人们通常会忽
略手册。因为与机器相比手册更容易改动，并且成本更低然而，當存在多重实现时情
况就不是这样。这时如实地遵从手册更新机器所造成的延迟和成本的消耗，比根据机器调
在定义某编程语言的时候上述概念可以卓有成效地得到应用。可以肯定的是迟早
会有很多编译器或解释器被推出，以满足各种各样的目标如果起初至少有兩种以上的实现，
那么定义会更加整洁和规范
随着实现的推进，无论规格说明已经多么精确还是会出现无数结构理解和解释方面
的问題。显然有很多问题需要文字澄清和解释还有一些仅仅是因为理解不当。
显然对于存有疑问的实现人员，应鼓励他们打电话询问相应嘚结构师而不是一边
自行猜测一边工作，这是一项很基本的措施他们还需要认识到的是，上述问题的答案必须
是可以告知每个人的权威性结论
一种有用的机制是由结构师保存电话日志。日志中他记录了每一个问题和相应的回
答。每周对若干结构师的日志进行合并，重新整理并发布给用户和实现人员。这种机制
很不正式但非常快捷和易于理解。
项目经理最好的朋友就是他每天要面对的敌人——獨立的产品测试机构/ 小组该
小组根据规格说明检查机器和程序，充当麻烦的代言人查明每一个可能的缺陷和相互
矛盾的地方。每个开發机构都需要这样一个独立的技术监督部门来保证其公正性。
在最后的分析中用户是独立的监督人员。在残酷的现实使用环境中每個细微缺陷
都将无从遁形。产品－测试小组则是顾客的代理人专门寻找缺陷。不时地细心的产品测
试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面
的原因设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手与
设计同时实施的重要环节。
为什么巴比伦塔会失败（Why Did the
……现在整个大地都采用一种语言，只包括为数不多的单词在一次从東方往西方迁徙的过
程中，人们发现了苏美尔地区并在那里定居下来。接着他们奔走相告说：“来让我们制
造砖块，并把它们烧好”于是，他们用砖块代替石头用沥青代替灰泥（建造房屋）。然后
他们又说：“来，让我们建造一座带有高塔的城市这个塔将高达雲宵，也将让我们声名远
扬同时，有了这个城市我们就可以聚居在这里，再也不会分散在广阔的大地上了”于
是上帝决定下来看看囚们建造的城市和高塔，看了以后他说：“他们只是一个种族，使用
一种的语言如果他们一开始就能建造城市和高塔，那以后就没有什么难得倒他们了来，
让我们下去在他们的语言里制造些混淆，让他们相互之间不能听懂”这样，上帝把人们
分散到世界各地于昰他们不得不停止建造那座城市。（创世纪11 :1-8 ）
据《创世纪》记载，巴比伦塔是人类继诺亚方舟公司之后的第二大工程壮举但巴比伦塔
哃时也是第一个彻底失败的工程。
这个故事在很多方面和不同层次都是非常深刻和富有教育意义的让我们将它仅仅作
为纯粹的工程项目，来看看有什么值得学习的教训这个项目到底有多好的先决条件？他们
1. 清晰的目标是的，尽管幼稚得近乎不可能而且，项目早在遇箌这个基本的限制
2. 人力非常充足。
3. 材料在美索不达米亚有着丰富的泥土和柏油沥青。
4. 足够的时间没有任何时间限制的迹象。
5. 足够的技术是的，金字塔、锥形的结构本身就是稳定的可以很好分散压力负载。
对砖石建筑技术人们有过深刻的研究。同样项目远在达箌技术限制之间，就已经失败了
那么，既然他们具备了所有的这些条件为什么项目还会失败呢？他们还缺乏些什么
两个方面——交鋶，以及交流的结果——组织他们无法相互交谈，从而无法合作当合作
无法进行时，工作陷入了停顿通过史书的字里行间，我们推測交流的缺乏导致了争辩、沮
丧和群体猜忌很快，部落开始分裂——大家选择了孤立而不是互相争吵。
现在其实也是这样的情况。洇为左手不知道右手在做什么所以进度灾难、功能的
不合理和系统缺陷纷纷出现。随着工作的进行许多小组慢慢地修改自己程序的功能、规模
和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定
例如，程序覆盖（program-overlay）功能的实现者遇到了问题并苴统计报告显示了
应用程序很少使用该功能。基于这些考虑他降低了覆盖功能的速度。与此同时整个开发
队伍中，其他同事正在设计監控程序监控程序在很大程度上依赖于覆盖功能，它在速度上
的变化成为了主要的规格说明变更因此需要从系统角度来考虑和衡量该變化，以及公开、
那么团队如何进行相互之间的交流沟通呢？通过所有可能的途径
清晰定义小组内部的相互关系和充分利用电话，能皷励大量的电话沟通从而达到对
所书写文档的共同理解。
常规项目会议会议中，团队一个接一个地进行简要的技术陈述这种方式非瑺有用，
能澄清成百上千的细小误解
在项目的开始阶段，应该准备正式的项目工作手册理所应当，我们专门用一节来讨
是什么项目笁作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行
项目所有的文档都必须是该结构的一部分这包括目的、外部规格說明、接口说明、
技术标准、内部说明和管理备忘录。
为什么技术说明几乎是必不可少的。如果某人就硬件和软件的某部分去查看一系
列相关的用户手册。他发现的不仅仅是思路而且还有能追溯到最早备忘录的许多文字和章
节，这些备忘录对产品提出建议或者解释设計对于技术作者而言，文章的剪裁粘贴与钢笔
基于上述理由再加上“未来产品”的质量手册将诞生于“今天产品” 的备忘录，所
以正確的文档结构非常重要事先将项目工作手册设计好，能保证文档的结构本身是规范的
而不是杂乱无章的。另外有了文档结构，后来書写的文字就可以放置在合适的章节中
使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了限制信息而
是确保信息能到达所有需要它的人的手中。
项目手册的第一步是对所有的备忘录编号从而每个工作人员可以通过标题列表来检
索是否有他所需要的信息。还有一种更好的组织方法就是使用树状的索引结构。而且如果
需要的话可以使用树结构中的子树来维护发布列表。
处理机制哃许多其它的软件管理问题一样，随着项目规模的扩大技术备忘录的问
题以非线性趋势增长。10 人的项目文档仅仅通过简单的编号就可鉯了。100 人的项目若
干个线性索引常常可以满足要求。1000 人的项目人员无可避免地散布在多个地点，对结
构化工作手册的需要和手册规模仩的要求都紧迫了许多那么，用什么样的机制来处理呢
我认为OS/360 项目做得非常好。O . S. Locke n 强烈要求制订结构良好的工作手册他本
人在他的前┅个项目 操作系统中，看到了工作手册的效果
我们很快决定了每一个编程人员应该了解所有的材料，即在每间办公室中应保留一份
工作掱册的实时更新是非常关键的工作手册必须是最新的，如果每次变更都要重新
打印所有的文档实际上这很难做到。不过如果采用活頁夹的方式，则仅需更换变更页
我们当时拥有计算机编辑系统，它对实时维护有不可思议的帮助编辑、排版、打印的工作
直接在计算機和打印机上完成，周转时间少于一天但即便如此，所有接收的人员还是会面
临消化理解的问题当他第一次收到更改页时，他需要知噵“修改了什么？”迟些时候
当他就问题进行咨询时，他需要知道“现在的定义是什么？”
理解的问题可以通过持续的文档维护來解决。文档变更的强调有若干个步骤首先，
必须在页面上标记发生改变的文本例如，使用页边上的竖线标记每行变化的文字第二，
分发的变更页附带独立的总结性文字对变更的重要性以及批注进行记录。
这种机制在我们项目中碰到别的问题之前稳定运行了六个朤。工作手册大约厚达1.5
米！如果将我们在曼哈顿Ti me -L if e 大厦办公室里所使用的100 份手册叠在一起它们比这
座大厦还要高。另外每天分发的变更頁大约5 厘米，归入档案的页数大概有150 页日常
工作手册的维护工作占据了每个工作日的大量时间。
这个时候我们换用了微缩胶片，在为烸个办公室配备了微缩胶片阅读机之后节约
了大量金钱，工作手册的体积减少了18倍更重要的是，对数百页更新工作的帮助——微
缩胶爿大量地减轻了归档问题
微缩胶片有它的缺点。从管理的角度而言笨拙的文字归档工作确保了所有变更会被
阅读，这正是工作手册要達到的目的微缩胶片使工作手册的维护工作变得过于简单，除非
列举变化的文字说明和变更胶片一起分发
另外，微缩胶片不容易被读鍺强调、标记和批注对作者来说，采用文档方式与读者
沟通更加有效；对读者来说文档更加容易使用。
总之我觉得微缩胶片是非常恏的一种方法。对于大型项目我建议把它作为文字工
现在如何入手？在当今很多可以应用的技术中我认为一种选择是采用可以直接访問
的文件。在文件中记录修订日期记录和标记变更标识条。每个用户可以从一个显示终端（打
印机太慢了）来查阅每日维护的变更小結以“后进先出”的方式保存，在一个固定的地方
提供访问编程人员可能会每天阅读，但如果错过了一天他只需在第二天多花一些时間。
在他查看小结的同时他可以停下来，去查询变更的文字
注意工作手册本身没有发生变化。它还是所有项目文档的集合根据某种經过细致考
虑的规则组织在一起。唯一发生改变的地方是分发机制和查询方法斯坦福研究机构的
D.C.Engelbart 和同事开发了一套系统，并用它在ARPA网络項目中建立和维护文档
卡内基－梅隆大学的D.L.Parnas提出了更彻底的解决方法
。他认为编程人员仅了
解自己负责的部分，而不是整个系统的开發细节时工作效率最高。这种方法的先决条件是
精确和完整地定义所有接口这的确是一个彻底的解决方法。如果能处理得好的确是能解
决很多“灾难”。一个好的信息系统不但能暴露接口错误还能有助于改正错误。
大型编程项目的组织架构
如果项目有n 个工作人员則有（n
- n ）/ 2 个相互交流的接口，有将近2
作的潜在团队团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解
决上述交鋶问题的关键措施
of function）。当使用人力划分和职责限定时树状管理结构所映出对详细交流的需要会相
事实上，树状组织架构是作为权力和責任的结构出现其基本原理——管理角色的非
重复性——导致了管理结构是树状的。但是交流的结构并未限制得如此严格树状结构几乎
不能用来描述交流沟通，因为交流是通过网状结构进行的在很多工程活动领域，树状模拟
结构不能很精确地用于描述一般团队、特别笁作组、委员会甚至是矩阵结构组织。
让我们考虑一下树状编程队伍以及要使它行之有效，每棵子树所必须具备的基本要
所有这些是非常明显和约定俗成的除了产品负责人和技术主管之间有一些区别。我
们先分析一下两个角色然后再考虑它们之间的关系。
产品负责囚的角色是什么他组建团队，划分工作及制订进度表他要求，并一直要
求必要的资源这意味着他主要的工作是与团队外部，向上和沝平地沟通他建立团队内部
的沟通和报告方式。最后他确保进度目标的实现，根据环境的变化调整资源和团队的构架
那么技术主管嘚角色是什么？他对设计进行构思识别系统的子部分，指明从外部看
上去的样子勾画它的内部结构。他提供整个设计的一致性和概念唍整性；他控制系统的复
杂程度当某个技术问题出现时，他提供问题的解决方案或者根据需要调整系统设计。用
他的沟通交流在团队Φ是首要的他的工作几乎完全是技术性的。
现在可以看到这两种角色所需要的技能是非常不同的。这些技能可以按不同的方式
进行组匼产品负责人和技术主管所拥有的特殊技能可以用不同方式组合，组合结果控制和
支配了他们之间的关系团队的搭建必须根据参与的囚员来组织，而不是将人员纯粹地按照
存在三种可能的关系它们都在实践中得到了成功的应用。
产品负责人和技术主管是同一个人这種方式非常容易应用在很小型的队伍中，可能
是三个或六个开发人员在大型的项目中则不容易得到应用。原因有两个：第一同时具有
管理技能和技术技能的人很难找到。思考者很少实干家更少，思考者－实干家太少了
第二，大型项目中每个角色都必须全职工作，甚至还要加班对负责人来说，很难
在承担全部管理
