人月神話
2004/04/04
經濟新潮社
Frederick P. Brooks, Jr.
416
錢一一
无
很少有一本軟體專案管理的書，像《人月神話》這樣深具影響力而且歷久不衰，Fred Brooks以軟體工程上的實例，搭配發人深省的評論，為如何管理大型、複雜專案提供了精闢的見解。他曾經擔任過IBM System/360電腦系列，以及與之搭配的OS/360這種大型軟體系統的專案經理，書中文章即取材自他擔任這些職務的實際經驗。在《人月神話：軟體專案管理之道》首次出版二十年後，作者對他當初所提出的理念做了一番回顧，並加入了新的思維與建議，獻給對《人月神話：軟體專案管理之道》已經熟悉的讀者，以及第一次接觸《人月神話：軟體專案管理之道》的人。 二十週年紀念版新增的章節包括：（１）將本書初版中所主張的所有論斷整理出一個簡潔的摘要，包括了原書的主要理念：就人力配置的比例而言，大型軟體專案所面臨的是跟小型專案完全不同的管理問題，這引申出產品的概念整體性是其中的關鍵，而達成概念整體性雖然困難，但卻是可能辦到的；（2）作者對他當初所提出的這些論斷，在經過一個世代之後所做的觀察；（3）轉載他1986年發表於IEEE Computer的經典論文〈沒有銀彈〉；以及（4）他對於他1986年的論斷「十年內不會有任何銀彈」所做的回應。 1975年出版的《人月神話》是軟體開發方面的經典之作。近三十年來，《人月神話：軟體專案管理之道》能在技術日新月異的計算機領域持續受到歡迎，正是因為它不僅是技術性的書籍，還包括要開發一個大型系統所應注意的管理層面問題，這使得《人月神話：軟體專案管理之道》涵蓋軟體、管理的層次，而經得起考驗。如果您從事程式設計工作，或是和程式設計者共事，或負責軟體專案的管理，甚至如果您是IT產業的領導者，您都應該閱讀《人月神話：軟體專案管理之道》。
Frederick P. Brooks, Jr.任教於北卡羅萊納大學Chapel Hill分校，擔任計算機科學的Kenan講座教授。由於他在IBM System/360開發階段擔任專案經理一職，遂以「IBM System/360之父」聞名於世，隨後擔任過OS/360設計階段的軟體專案經理，為此，他與Bob Evans、Erich Bloch共同獲頒了1985年國家科技成就獎的殊榮，在此之前，還曾經是IBM Stretch和Harvest電腦的架構設計師。1999年，他獲頒美國計算機協會（ACM）的圖靈獎（A. M. Turing Award），這是在計算機領域中最具權威性的技術獎項，美國計算機協會盛讚他「對計算機結構、作業系統和軟體工程做出了劃時代的貢獻」。 Brooks博士在Chapel Hill分校創建了計算機科學系，並自1964至1984年間擔任該系的系主任，也曾任職於國家科學委員會和國防科學委員會。目前，他所從事的是計算機結構（computer architecture）、分子模型繪圖（molecular graphic），以及虛擬環境（virtual environment）方面的教學和研究。
有些書，對於讀者和作者就像是年金一樣，可以年年分紅。《人月神話》就是這樣一本書……年輕的軟體工程師、缺錢的研究生、懶惰的程式設計老手，常常問我哪一本電腦書是最好的。「如果我被困在一個荒島上，只能帶一本電腦書，」他們問，「應該是哪一本？」這問題很荒謬，但是他們堅持要答案。假如你真的被放逐到這樣的小島上，應該陪伴你的是《人月神話》。 ——Ed Yourdon，軟體界知名顧問與作家 我唯一一本讀過一遍以上的計算機相關書籍，是Fred Brooks的《人月神話》，事實上我每隔幾年都會重讀其中的某些章節。一部分原因是這本書文筆很好，而且書中的忠告很有價值，即使是在這本書出版了超過 25年之後。當然，現在在很多細節上，還有我們做事的方法都不一樣了，我們的工作更自動化，電腦的「馬力」也更強了，但書中依然有非常多很好的忠告。我非常推崇這本書，這是我唯一覺得你能從中體會到樂趣和思想的計算機科學書籍。 ——Brian Kernighan，The C Programming Language作者
无
概念的完整性的确需要系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。
外科手术队伍，外科医生和副手了解所有的设计和全部的代码。上下级关系可以达到可观的一致性。让200人去解决问题，仅仅需要协调20个外科医生。
人月神话的骗局。开发中人力与时间的关系，他们并不是简单的对等的，而是一个更加复杂的函数。
如何避免第二个系统所引起的后果，从而避免画蛇添足？运用特别的自我约束准则，来避免哪些功能上的过于修饰，根据系统基本理念及目的变更，舍弃一些功能。
手册的重要性：绝不要携带两个时钟出海，带一个或三个。
程序维护中的一个基本问题是缺陷修复总会以固定（20%-50%）的几率引入新的bug。整个过程是前进两步，后退一步。
文档的重要性，遇到问题记下来，有记录，分歧才会明朗，矛盾才会突出。
概念完整性。一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略，。用户所感受到的产品概念完整性是易用性中最重要的因素。
结构师。结构师负责产品所有方面的概念完整性，这些是用户能实际感受到的。结构师开发用于向用户解释使用的产品概念模型，概念模型包括所有功能的详细说明以及调用和控制的方法。结构师是这些模型的所有者，同时也是用户的代理。在不可避免地对功能、性能、规模、成本和进度进行平衡时，卓有成效地体现用户的利益。这个角色是全职工作，只有在最小的团队中，才能和团队经理的角色合并。结构师就像电影的导演，而经理类似于制片人。
将体系结构和设计实现、物理实现相分离。为了使结构师的关键任务更加可行，有必要将用户所感知的产品定义棗体系结构，与它的实现相分离。体系结构和实现的划分在各个设计任务中形成了清晰的边界，边界两边都有大量的工作。
人月神话介绍软件工程应该注意的问题，比如团队组织，空间、银弹——开发技术，时间日程表等等。初出茅庐的菜鸟读起来压力很大。
搬家，准备出售一些闲置书籍，
包括人月神话，转让。有需要着请与我联系。多为计算机方面书籍。
下面链接是我在孔夫子网上书摊
http://tan.kongfz.com/106218/204986748/
这是一本谈项目管理小册子，是一些经验的罗列，没有什么系统性，但是比较有用。这本书强调几个重要的理念：
1.项目中，一般用人月来计算工作量，但是人和月是不能互换的。在项目延期的情况下，加更多的人往往会使项目更糟，因为新成员的加入需要很高的沟通成本。
2.概念的一致性：项目中的概念在不同阶段，不同成员之间要保持一致性很难，但很重要。
3.交流很重要：巴比伦塔失败的原因是因为人们不能有效的沟通。
4.随着程序规模的增加，工作量不是按比例增长，而是按指数增长，计划、文档、测试、集成等工作都要考虑在内。就像人跑一千米所用的时间不等与百米冲刺的10倍一样。 他给出一个公式：工作量 ＝ （常数）×（指令的数量）1.5 不知道他怎么得出这个公式的，我觉得现在以指令数量来衡量已经不适用了吧。
5.培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
6.系统刚发布时，发现bug的数量会逐渐减少，但过几个月后，会增加。因为用户的使用到了新的熟练水平，开始使用新的功能。
。。。。
书中的一些技术细节读起来比较费力，我更多地是从“项目管理”的角度来阅读此书。
【1】缺乏合理的时间进度是造成项目滞后的最主要原因。
【2】通常，我们会过于乐观，错误地假设“一切都将运作良好，每项任务仅花费它所应该花费的时间”。
【3】在估计和进度安排中常常使用“人月”作为工作单位。但我们往往错误地假设人员数量和时间是可以相互替换的。当项目进度滞后时，我们往往会投入更多的人力。然而，此时我们需要考虑额外增加的培训成本、沟通成本等。
【4】Brooks 法则：向进度落后的项目增加人手，只会使进度更加落后。
我认为应该辩证地看待这个法则，我发现在实际工作中发现进度落后的时候，一般采取以下三种措施（1）加班（2）减少项目范围（3）增加人手
【5】系统测试进度的安排。由于我们的乐观主义，通常实际出现的缺陷数量比预料的要多得多。作者会把项目一半的时间预留在测试上。
在今后参与测试相关的项目时，留意一下如何安排测试进度的。
【6】为了获得概念完整性，设计必须由一个人或者具有共识的小型团队完成。概念上统一的系统能更快地开发和测试。尽早交流和持续沟通能使结构师有较好的成本意识。
【7】外科手术队伍。对于大型系统，小型精干的队伍太慢了。建议采用外科手术队伍的团队架构（有一个主要的负责人，其他人都是分工协作的副手），既能获得由少数头脑产生的产品完整性，有能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
【8】团队中的交流（项目工作手册）和组织架构影响项目的成败；同时也强调了文档的重要性。
“软件的复杂度是根本属性，不是次要因素。因此，抽掉复杂度的软件实体描述常常也去掉了一些本质属性。数学和物理学在过去三个世纪取得了巨大的进步，数学家和物理学家们为复杂的现象建立了简化的模型，从模型中抽取出各种特性，并通过试验来验证这些特性。这些方法之所以可行，是因为模型中忽略的复杂度不是被研究现象的根本属性。当复杂度是本质特性时，这些方法就行不通了。”
“爱因斯坦曾不断地重申自然界一定存在着简化的解释，因为上帝不是专横武断和反复无常的。软件工程师却无法从类似的信念中获得安慰，他必须掌握的很多复杂度是随心所欲、毫无规则可言的，来自若干必须遵循的人为惯例和系统。它们随接口的不同而改变，随时间的推移而变化，并且，这些变化不是必需的，仅仅由于他们是不同的人——而非上帝——设计的结果。”
“当我们试图用图形来描述软件结构时，发现它不仅仅包含一个，而是很多相互关联、重叠在一起的图形。这些图形可能代表控制流程、数据流、依赖关系、时间序列和名字空间的相互关系等等。它们通常不是有较少层次的扁平结构。实际上，在上述结构上建立概念控制的一种方法是强制将关联分割，直到可以层次化一个或多个图形。”
原书中，这两段话分别针对软件四项内在特性中的两项：“复杂度”和“一致性”而论，这三段话让我有豁然开朗的感觉，所以相当喜欢！
第一段加深了我对数学和物理的理解——我们的学习思路的确是这样的；
第二段反映了一个心结：我们都想将精力放在解决问题本身，而不是因为人为设计不一致造成的无谓却必要的劳动上；
第三段则介绍用图形描述软件结构的一种抽象方法——强制将关联分割。
“没有银弹”全篇（包括16、17章）则深化了我对软件的认识，这源自本篇的中心论点：软件存在根本的和次要的两种困难，为了提高软件开发的效率，人们同时在为解决这两种困难而努力着。如今，解决次要的困难已经取得了巨大进步，但根本的困难仍然困扰着人们——这也是作者“没有银弹”论断的来源。（将软件开发比作人狼——简单明了的东西可能变成落后进度、超出预算、存在大量缺陷的怪物，杀死人狼的武器是银弹，但是解决软件开发困难的银弹可能并不存在，因为人们面对的是软件的根本困难。）
由于作者所有的讨论都是针对软件的根本困难和次要困难，所以，理解这两种困难对于深化软件的认识至关重要，这也是我认为全书最精华的地方——作者讲得深入浅出，又发人深省。
··················································
作者认为，所有的软件活动包括两种任务：
1.根本任务：打造构成抽象软件实体的复杂概念结构。
2.次要任务：使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。
相应的，软件就存在两种困难：
1.根本的困难：软件特性中固有的困难。
2.次要的困难：出现在目前生产中，但并非那些与生俱来的困难。
作者的观点是：
“我认为软件开发中困难的部分是规格说明、设计和测试这些概念上的结构，而不是对概念进行表达和对现实逼真程度进行验证。”
所以，软件无法规避的内在特性是（虽然书中没有明说，但我能感觉到，这些就是作者所说的根本困难）：
1.复杂度：没有任何两个软件部分是相同的（至少在语句的级别上）……数字计算机本身就比人类建造的大多数东西复杂……软件系统的状态又比计算机的状态多若干个数量级……软件的复杂度是根本属性，不是次要因素……
2.一致性：许多情况下，因为是开发最新的软件，它必须遵循各种接口。另一些情况下，软件的开发目标就是兼容性……很多复杂性来自保持与其他接口的一致方面，对软件的任何再设计，都无法简化这些复杂特性……
3.可变性：软件实体经常会遭受到持续的变更压力……系统中的软件包含了很多功能，而功能是最容易感受变更压力的部分……软件可以很容易地进行修改——它是纯粹思维活动的产物，可以无限扩展……所有成功的软件都会发生变更……功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们……软件一定是在某种计算机硬件平台上开发，成功软件的生命期通常比当初开发软件所用的计算机硬件平台要长……简言之，软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫软件也随之变化……
4.不可见性：软件是不可见的和无法可视化的……软件的客观存在不具有空间的形体特征……除去软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造创意。这种缺憾不仅限制了个人的设计过程，也严重阻碍了思路相互之间的交流。
*注：这里，未必说作者所说的都是对的，我们当然需要批判性思维，但是当这方面的知识远逊于作者时，将其作为知识吸收，从而促进自己的思考，显然是个不错的选择。
文章中剩余的部分则讨论了解决次要困难的突破（高级语言、分时、统一编程环境），以及解决根本困难的可能途径（Ada和其他高级编程语言、面向对象编程、人工智能、专家系统、“自动”编程、图形化编程、程序验证、环境和工具、工作站）——当然这些都被作者否定了。
最后，作者提出了自己所认为的一些可能解决根本困难的方法（参考如今的软件开发，作者30多年前的观点多么具有前瞻性啊！）：
1.购买和自行开发。
2.需求精炼和快速原型。
3.增量开发——增长，而非搭建系统。
4.卓越的设计人员。
以上节选自：http://wuguoren.com/2012/12/29/%E3%80%90%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E3%80%91%E6%B2%A1%E6%9C%89%E9%93%B6%E5%BC%B9-%E6%9C%89%E5%85%B3%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E7%9A%84%E8%AE%BA%E6%96%AD/
张小龙说“不听摇滚的程序员不是好产品经理”，作为一个听摇滚但不是程序员的产品经理，理应寻找中间的那个名词。
1、向进度落后的项目中增加人手，只会使项目更加落后；
2、项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量；
3、研究表明，效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平；
4、需要协作沟通的人员数量影响着开发成本；
5、对于效率和高年的完整性来说，最好由少数干练的人员来设计和开发，面对于大型系统，则需要大量的人手，以使产品在时间上满足需求；
6、以易用性为目标，功能与理解上复杂程度的比值才是系统设计的最终测试标准；简洁和直白来自概念的完整性；易用性实际上需要设计的一致性和概念的完整性；
7、手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物；
8、手册需精确的规定限制，描述将达到的目标，列举差异，需在仔细定义规定什么的同时，定义来规定什么；
9、产品责任人和技术主管必须在基本的技术理论上具有相似的观点，他们必须在主要的技术问题出现之前，私下讨论这些问题，产品责任人必须对技术主管的技术才能表现出尊重；
10、交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理和仔细考虑，相关经验的积累和能力的提高同软件本身一样重要；
11、实践是最好的老师，但智者还能从其他的地方有收获；
12、为了满足目标，每个人都在局部优化自己的程序，很少有人会停下来考虑一下对客户的整体影响；
13、培养开发人员从系统整体出发，面向客户的态度是软件编程管理人员最重要的职能；
14、技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高；
15、数据的表现形式是编程的根本；
16、软件开发人员为客户所承担的最重要的职能不断重复的抽取和细化产品的需求；
17、不了解，就无法真正拥有；
18、原型通常展示了应用程序的功能主线，但不能处理任何如无效输入，退出清除等异常情况；
19、原型的目的是明确实际的概念结构，使客户可以测试一致性和可用性；
20、增量开发——增长，而非搭建系统；
21、低劣设计和良好设计之间的区别可能在于设计方法的完善性，而良好设计和卓越设计之间的区别肯定不是如此，卓越设计来自卓越设计人员；
22、我们理解也好，不理解也好，描述都应该简短精炼；
23、项目经理面临的中心问题就是如何设计架构和流程，来提高而不是压制主动性和创造力；
24、管理人员的职责不是要人去工作，而是创造工作的可能；
25、附属职能行驶原理：如果较低级别组织的自由和责任得以保留，中心权威实际上得到了加强。
很难想象是50年前写成的
更难想象50年前 人们曾经走过的弯路 我们如今还在走
除了经典的人月理论，列举一些个人认为至今依然收益的论断
- Documentation is the chief production of the architecture
- Second system effect
- The first version is done to be thrown away
- Build up a surgeon team
1，老外在32年前就对软件项目管理有了很深入透彻的了解，令人惊叹。
2，前人总结出来的经验教训，而我们由于各种原因一直在重犯。
3，某些语言或者技术会过时，但是这部书的内容永远不会过时。
-
这本书是“国外程序员推荐：每个程序员都应读的书”中一本非技术书，书中没有任何技术知识。我花了大概一周的时间粗略读了一遍，感触呢，如书中所说“大多数观点本来已经知道”。
软件工程师应该至少过一遍书中提出的观点，在实际工作中加以运用，比如：多交流，不知道的一定要问；多做实验来验证不确定的东西；选顺手的工具；用合理的方式管理文档。
其实我更建议经理级别的人/部门老大来读这本书，从而能用更合理的方式来管理项目和工程师。为什么产品总是延期？为什么增加人手不能赶上进度？为什么工程师士气低落？为什么...... 本书不仅解答了这些为什么，而且提出了实施的建议。我先后经历过几家公司，发现管理上的混乱是如何拖慢进度，如何消磨大家工作的积极性的，希望这本书能引起老大们的注意。
诚然，国内环境复杂，软件工程师就是被压迫的一个阶层，想必书中观点也很难在现实中应用。