【读书笔记】人月神话
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
6/49
《人月神话》的由来
• IBM的System/360是第一个特大型软件项目，它催生了《人月神话》
7/49
《人月神话》的由来
• System/360的开发过程被视为计算机发展史上最大的一次豪赌，为了 研发System/360这台大型机，IBM决定征召6万多名新员工，创建五5 座新工厂，当时的研发费用超过了50亿美元（相当于现在的340亿美元， 约2200亿人民币），但出货的时间不断的顺延。
– 做什么：开发目标 – 怎么做：产品技术说明。以建议书开始，以内部文档和用户
手册结束 – 时间：进度表 – 资金：预算 – 地点：工作空间分配 – 人员：组织图
26/49
焦油坑之三--文档问题
自文档化的程序 – 为什么提倡自文档化程序？
数据处理的基本原理告诉我们，试图把信息放在不同文件中，并试图维 护它们的同步是件费力不讨好的事情。在软件开发里，我们却试图维护 一份机器可读的程序，以及一系列包含记述性文字和流程图的文档。
18/49
焦油坑之一：进度滞后
• Brooks法则
– 定义："Adding manpower to a late software project makes it later."--Brooks
– 出现原因： 新增的程序员需要进行培训，同时增加了沟通的成本，使得开发 团队增加了更多的开发时间，这个时间超过了新增程序员所做的 贡献。
24/49
焦油坑之三--文档问题
• 撰写关键的文档
– 书面的决策更加精确 – 文档可作为沟通交流的手段 – 文档可为系统将来的优化和扩展提供指导 – 项目经理的文档可作为项目的数据基础和检查表
• 不提倡过度文档
– 给用户使用的最终产品并非是文档
25/49
焦油坑之三--文档问题
• 需要提供哪些关键的文档？
• 然而，他最广为认知的功绩则是在软件领域的重要经典著作—— 《人月神话》，可以说正是此书让软件工程学进入了人们的视野。
3/49
弗雷德里克·布鲁克斯的经典著作——《人月神话》
40
《
《
人
人
月
月
神
神
话
话
》
》
20
周
周
年
年
纪
纪
念
念
版
版
《 人
• 书籍简介
月
神 话
– 1975年首次发行
》
32
– 软件工程的经典之作
• 在《人月神话》中，Brooks博士为人们管理复杂的项目提供了最具洞察 力的见解，既有很多引人深思的观点，又有大量软件工程的实践。
8/49
人月神话
• 人月：软件开发过程中衡量工作量的常用度量单位。 • 而在实际情况中，增加“人”并不能缩短“月”的量
• 为什么说人月是神话？ （1）许多任务是无法拆解的 （2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加 以(n-1)*n/2的规模递增
周
年 纪
– 收录了作者多年的技术文章
念
版
– 为大型的软件开发提供启示
4/49
软件领域的神话 —— 一本畅销不衰的著作
• 在计算机这个日新月异的领域中，长盛不衰的书籍几乎是凤毛麟角的。 为什么《人月神话》的魅力能不因技术的更替而黯淡，反而能在这多 变的时代中证明自己的价值，乃至有了20年，32年，40年的纪念版 出现呢？
23/49
焦油坑之二--缺乏沟通
• 在树状组织架构中进行交流
传统的沟通方式是网状的，n个人之间的交流需要(n-1)*n/2个接口。然而团队的 组织架构总是树状的，可以利用这种树状的组织结构减少沟通成本。需要为每棵 子树定义一些基本要素：
– (1)每棵子树需要完成的任务 – (2)子树的产品负责人（对外沟通） – (3)子树的技术主管（对内技术指导） – (4)进度 – (5)人员的划分 – (6)子树对外接口的定义
• 第11章 未雨绸缪
• 第12章 干将莫邪
• 第13章 整体部分
• 第14章 祸起萧墙
• 第15章 另外一面
• 第16章 没有银弹-软件工 程中的根本和次要问题
• 第17章 再论“没有银弹”
• 第18章 《人月神话》的观 点：是与非
• 第19章 20年后的《人月 神话》
10/49
人月神话——焦油坑
人类的语言，巴比伦塔不得不停工了。
--旧约 第11章
巴别：在希伯来语中是"变乱"的意思
22/49
焦油坑之二--缺乏沟通
如果大型编程项目中交流不足，很可能面临和巴别塔一样的结局。
• 大型编程项目中的交流方法
– (1)成员之间非正式途径的经常性讨论 – (2)定期召开的项目会议 – (3)项目工作手册
16/49
焦油坑之一：进度滞后
图一: 可以完全分解的任务 （在软件开发中不存在)
图二: 可以分解但需要沟通 交流的任务(一般情况)
17/49
图三: 关系错综复杂的任务
（极端情况)
焦油坑之一：进度滞后
• 各项任务的时间安排不合理
– 作者的经验之谈：
测试时间不足的恶果：直到项目的发布时期，才有人发现进度的问题。
• 大型的系统开发类经常遇到焦油坑！ “表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被
解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变 得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很 难看清问题的本质。” ——Brooks
12/49
软件开发中的焦油坑
• Windows NT 5.0(即windows 2000) • 时间：
• 两种可能：
– (1)微软雇佣了5000名不合格的程序员去开发windows NT 5.0 – (2)开发一个大规模的程序系统产品远难于堆砌出单一的程序。
• 作者目的：尽可能地帮助大型系统开发人员走出焦油坑
14/49
焦油坑之一：进度滞后
• 进度滞后的原因
– 乐观主义的盛行（软件开发是纯思维性的活动） – 人月神话 – 各项任务的时间安排不当（特别是测试时间） – 迫于用户压力制定了不合理的进度计划 – brooks法则
• 当时的专案经理Frederick P. Brooks, Jr.事后根据这项计划的开发经验， 写作《人月神话：软件项目管理之道》（The Mythical Man-Month: Essays on Software Engineering）记述人类工程史上一项里程碑式的 大型复杂软件系统开发经验。
– 如何产生自文档化的程序？
(1)在程序源代码里附加尽可能多的信息，例如变量名，函数名等 (2)尽可能使用空格和一致性的格式来提高程序的可读性，表现从属和嵌 套关系 (3)以段落注释的格式，向程序插入必要的记述性文字
27/49
人月神话——精美的烹饪需要时间
美酒的酿造需要年头，美食的烹调需要时间；片刻等待，更多美味，更多享受。 Good Cooking takes time. If you are made to wait, it is to serve you better, and to please you.
《人月神话》读书笔记
人百度文库神话
弗雷德里克·布鲁克斯 Frederick P. Brooks, Jr.
人物简介：
• 美国工程院院士
• “IBM 360系统之父”，曾担任 360系统的项目经理，及该项目设 计阶段的经理。凭借在此项目中的 杰出贡献，在1985年获得美国国家 技术奖。
• 1999年荣获美国计算机领域最具声 望的图灵奖 （A.M.TURINGAWARD）桂冠。
• 它仍然是计算机书籍中被引用次数最多的书籍，而且即便本书最初出 版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说 一句“对极了！”是很难受的。 ——Stee McConnell,Construx公司首席软件工程师
• 我唯一一本读过一遍以上的书，是Fred Brooks的《人月神话》，实 际上我每过一两年就会重读一遍。部分原因是这本书文笔很好，另外 就是书中的忠告很有价值，即使是25年以后。我非常推崇这本书， 这是我唯一能想起来的能从中体会到乐趣和思想的计算机学科书籍。 ——Brian Kernighan ,著名《C程序设计语言》的合著者之一。
一座带有高塔的城市，这个塔将高耸云霄，也让我们声名远扬。”于
是上帝决定下来看看人们建造的城市和高塔，看了以后，他说：“他
们只是一个种族，使用一种语言，如果他们一开始就能造出城市和高
塔，那以后就没有什么能难得倒他们了。来，让我们在人类的语言里
制造些混淆，让他们相互之间不能听懂。”上帝于是改变并区别开了
– 结论过于武断？应该附加的前提： (1)项目已经进行了相当长时间的开发 (2)系统比较复杂，新人的学习成本较高
19/49
焦油坑之一：进度滞后
• 对于进度滞后项目的解决方案 – (1)在新的进度安排中分配充分的时间，确保工作能彻 底、认真地完成 – (2)当项目延期所导致的后续成本很高时，往往削减系 统的功能是唯一的解决方法
• 如： 20人* 5个月 > 50人* 2个月
9/49
《人月神话》目录
• 第1章 焦油坑 • 第2章 人月神话 • 第3章 外科手术队伍 • 第4章 贵族专制、民主政治
和系统设计 • 第5章 画蛇添足 • 第6章 贯彻执行 • 第7章 为什么巴比伦塔会失
败 • 第8章 胸有成竹 • 第9章 削足适履 • 第10章 提纲挈领
2/49
弗雷德里克·布鲁克斯的经典著作——《人月神话》
• 2000年新年伊始，国际计算机协会（ACM）在纽约宣布1999年图 灵奖得住为时年为69岁的Frederick P. Brooks, Jr.。评选委员会主席 在致辞中提到，“今天我们所看到的计算机体系结构、软件工程及三 维计算机图形，均受益于Brooks 的开创性工作，是他改变了这些领 域的面貌。”Brooks确实是一位在计算机科学各方面均作出杰出贡 献的奠基者。
史前
今天
焦油坑
大型软件项目
• 图为洛杉矶自然历史博物馆 George C.Page馆内布拉雷亚 焦油坑的中生代情形想象图原 图
吞噬 成千上万的巨兽
围困 无数庞大的开发团体
11/49
软件开发中的焦油坑
“史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震 撼。上帝见证着恐龙、剑齿虎在焦油中的挣扎。它们挣扎的越是猛烈， 焦油越是缠的越紧，没有任何猛兽足够强壮或具有足够的技巧，能够 挣脱束缚，它们最后都沉到了坑底。” ——Brooks
– 计划开发时间：3年 – 实际开发时间：5年 • 公布数据： – 程序员人数：5,000人 – 代码行数：35,000,000 行代码 – 开发时间：5年 • 每位程序员每年生产多少行代码？
13/49
软件开发中的焦油坑
• 每位程序员每年生产多少行代码？ 以最不幸的情况来估计，每行代码都需要自己编写，得到 结果：35,000,000 行/(5000人*5年) = 1400行/人.年。 这个效率远远低于一名正常程序员的产出量。
15/49
焦油坑之一：进度滞后
“使用人月为单位来衡量一份工作的规模是一个危险和具有欺骗性的神话。它暗 示着人员数量和时间是可以相互替换的。”——brooks
• 人月神话 – 人月：参与开发的程序员数目 * 项目持续的月数 – 为什么说人月是神话？ （1）许多任务是无法拆解的 （2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加 以(n-1)*n/2的规模递增 20人* 5个月 > 50人* 2个月
• 精美的烹饪需要时间
• 软件开发项目常以人月来衡量工 作，这种度量暗示着人手和时间 是可以互换的。这种“人多力量 大”的想法是一种一厢情愿的虚 妄神话。
• Brooks法则：向滞后的软件项目 追加人手会使得进度更迟缓。
• 图为早年新奥尔良的安东尼奥法式餐厅的菜单
28/49
人月神话——外科手术队伍
对于许多小型的开发团队，加派人手是通常的解决方法？
20/49
焦油坑之二--缺乏沟通
• 巴别塔为什么会失败？
巴别塔：圣经中继“诺亚方舟”后人类第二个大工程，以失败告终
21/49
焦油坑之二--缺乏沟通
• 巴别塔为什么会失败？
......现在整个大地都使用同一种语言。在一次迁徙的过程中，人们发
现了苏美尔地区，并且在那里定居下来。他们说：“来，让我们建造
• 技术并非《人月神话》的着眼点，它更关注的是软件的创造过程、需 求的变化无常和管理的永恒困境。
• 《人月神话》的中心思想已经超越了具体的时代和技术。
5/49
名家谈人月神话
• 这是一本经典著作，与软件开发有关的每一个人都应该不只一遍地读 这本书。 ——Philippe Kruchten Rational 统一过程首席架构师
《人月神话》的由来
• IBM的System/360是第一个特大型软件项目，它催生了《人月神话》
7/49
《人月神话》的由来
• System/360的开发过程被视为计算机发展史上最大的一次豪赌，为了 研发System/360这台大型机，IBM决定征召6万多名新员工，创建五5 座新工厂，当时的研发费用超过了50亿美元（相当于现在的340亿美元， 约2200亿人民币），但出货的时间不断的顺延。
– 做什么：开发目标 – 怎么做：产品技术说明。以建议书开始，以内部文档和用户
手册结束 – 时间：进度表 – 资金：预算 – 地点：工作空间分配 – 人员：组织图
26/49
焦油坑之三--文档问题
自文档化的程序 – 为什么提倡自文档化程序？
数据处理的基本原理告诉我们，试图把信息放在不同文件中，并试图维 护它们的同步是件费力不讨好的事情。在软件开发里，我们却试图维护 一份机器可读的程序，以及一系列包含记述性文字和流程图的文档。
18/49
焦油坑之一：进度滞后
• Brooks法则
– 定义："Adding manpower to a late software project makes it later."--Brooks
– 出现原因： 新增的程序员需要进行培训，同时增加了沟通的成本，使得开发 团队增加了更多的开发时间，这个时间超过了新增程序员所做的 贡献。
24/49
焦油坑之三--文档问题
• 撰写关键的文档
– 书面的决策更加精确 – 文档可作为沟通交流的手段 – 文档可为系统将来的优化和扩展提供指导 – 项目经理的文档可作为项目的数据基础和检查表
• 不提倡过度文档
– 给用户使用的最终产品并非是文档
25/49
焦油坑之三--文档问题
• 需要提供哪些关键的文档？
• 然而，他最广为认知的功绩则是在软件领域的重要经典著作—— 《人月神话》，可以说正是此书让软件工程学进入了人们的视野。
3/49
弗雷德里克·布鲁克斯的经典著作——《人月神话》
40
《
《
人
人
月
月
神
神
话
话
》
》
20
周
周
年
年
纪
纪
念
念
版
版
《 人
• 书籍简介
月
神 话
– 1975年首次发行
》
32
– 软件工程的经典之作
• 在《人月神话》中，Brooks博士为人们管理复杂的项目提供了最具洞察 力的见解，既有很多引人深思的观点，又有大量软件工程的实践。
8/49
人月神话
• 人月：软件开发过程中衡量工作量的常用度量单位。 • 而在实际情况中，增加“人”并不能缩短“月”的量
• 为什么说人月是神话？ （1）许多任务是无法拆解的 （2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加 以(n-1)*n/2的规模递增
周
年 纪
– 收录了作者多年的技术文章
念
版
– 为大型的软件开发提供启示
4/49
软件领域的神话 —— 一本畅销不衰的著作
• 在计算机这个日新月异的领域中，长盛不衰的书籍几乎是凤毛麟角的。 为什么《人月神话》的魅力能不因技术的更替而黯淡，反而能在这多 变的时代中证明自己的价值，乃至有了20年，32年，40年的纪念版 出现呢？
23/49
焦油坑之二--缺乏沟通
• 在树状组织架构中进行交流
传统的沟通方式是网状的，n个人之间的交流需要(n-1)*n/2个接口。然而团队的 组织架构总是树状的，可以利用这种树状的组织结构减少沟通成本。需要为每棵 子树定义一些基本要素：
– (1)每棵子树需要完成的任务 – (2)子树的产品负责人（对外沟通） – (3)子树的技术主管（对内技术指导） – (4)进度 – (5)人员的划分 – (6)子树对外接口的定义
• 第11章 未雨绸缪
• 第12章 干将莫邪
• 第13章 整体部分
• 第14章 祸起萧墙
• 第15章 另外一面
• 第16章 没有银弹-软件工 程中的根本和次要问题
• 第17章 再论“没有银弹”
• 第18章 《人月神话》的观 点：是与非
• 第19章 20年后的《人月 神话》
10/49
人月神话——焦油坑
人类的语言，巴比伦塔不得不停工了。
--旧约 第11章
巴别：在希伯来语中是"变乱"的意思
22/49
焦油坑之二--缺乏沟通
如果大型编程项目中交流不足，很可能面临和巴别塔一样的结局。
• 大型编程项目中的交流方法
– (1)成员之间非正式途径的经常性讨论 – (2)定期召开的项目会议 – (3)项目工作手册
16/49
焦油坑之一：进度滞后
图一: 可以完全分解的任务 （在软件开发中不存在)
图二: 可以分解但需要沟通 交流的任务(一般情况)
17/49
图三: 关系错综复杂的任务
（极端情况)
焦油坑之一：进度滞后
• 各项任务的时间安排不合理
– 作者的经验之谈：
测试时间不足的恶果：直到项目的发布时期，才有人发现进度的问题。
• 大型的系统开发类经常遇到焦油坑！ “表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被
解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变 得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很 难看清问题的本质。” ——Brooks
12/49
软件开发中的焦油坑
• Windows NT 5.0(即windows 2000) • 时间：
• 两种可能：
– (1)微软雇佣了5000名不合格的程序员去开发windows NT 5.0 – (2)开发一个大规模的程序系统产品远难于堆砌出单一的程序。
• 作者目的：尽可能地帮助大型系统开发人员走出焦油坑
14/49
焦油坑之一：进度滞后
• 进度滞后的原因
– 乐观主义的盛行（软件开发是纯思维性的活动） – 人月神话 – 各项任务的时间安排不当（特别是测试时间） – 迫于用户压力制定了不合理的进度计划 – brooks法则
• 当时的专案经理Frederick P. Brooks, Jr.事后根据这项计划的开发经验， 写作《人月神话：软件项目管理之道》（The Mythical Man-Month: Essays on Software Engineering）记述人类工程史上一项里程碑式的 大型复杂软件系统开发经验。
– 如何产生自文档化的程序？
(1)在程序源代码里附加尽可能多的信息，例如变量名，函数名等 (2)尽可能使用空格和一致性的格式来提高程序的可读性，表现从属和嵌 套关系 (3)以段落注释的格式，向程序插入必要的记述性文字
27/49
人月神话——精美的烹饪需要时间
美酒的酿造需要年头，美食的烹调需要时间；片刻等待，更多美味，更多享受。 Good Cooking takes time. If you are made to wait, it is to serve you better, and to please you.
《人月神话》读书笔记
人百度文库神话
弗雷德里克·布鲁克斯 Frederick P. Brooks, Jr.
人物简介：
• 美国工程院院士
• “IBM 360系统之父”，曾担任 360系统的项目经理，及该项目设 计阶段的经理。凭借在此项目中的 杰出贡献，在1985年获得美国国家 技术奖。
• 1999年荣获美国计算机领域最具声 望的图灵奖 （A.M.TURINGAWARD）桂冠。
• 它仍然是计算机书籍中被引用次数最多的书籍，而且即便本书最初出 版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说 一句“对极了！”是很难受的。 ——Stee McConnell,Construx公司首席软件工程师
• 我唯一一本读过一遍以上的书，是Fred Brooks的《人月神话》，实 际上我每过一两年就会重读一遍。部分原因是这本书文笔很好，另外 就是书中的忠告很有价值，即使是25年以后。我非常推崇这本书， 这是我唯一能想起来的能从中体会到乐趣和思想的计算机学科书籍。 ——Brian Kernighan ,著名《C程序设计语言》的合著者之一。
一座带有高塔的城市，这个塔将高耸云霄，也让我们声名远扬。”于
是上帝决定下来看看人们建造的城市和高塔，看了以后，他说：“他
们只是一个种族，使用一种语言，如果他们一开始就能造出城市和高
塔，那以后就没有什么能难得倒他们了。来，让我们在人类的语言里
制造些混淆，让他们相互之间不能听懂。”上帝于是改变并区别开了
– 结论过于武断？应该附加的前提： (1)项目已经进行了相当长时间的开发 (2)系统比较复杂，新人的学习成本较高
19/49
焦油坑之一：进度滞后
• 对于进度滞后项目的解决方案 – (1)在新的进度安排中分配充分的时间，确保工作能彻 底、认真地完成 – (2)当项目延期所导致的后续成本很高时，往往削减系 统的功能是唯一的解决方法
• 如： 20人* 5个月 > 50人* 2个月
9/49
《人月神话》目录
• 第1章 焦油坑 • 第2章 人月神话 • 第3章 外科手术队伍 • 第4章 贵族专制、民主政治
和系统设计 • 第5章 画蛇添足 • 第6章 贯彻执行 • 第7章 为什么巴比伦塔会失
败 • 第8章 胸有成竹 • 第9章 削足适履 • 第10章 提纲挈领
2/49
弗雷德里克·布鲁克斯的经典著作——《人月神话》
• 2000年新年伊始，国际计算机协会（ACM）在纽约宣布1999年图 灵奖得住为时年为69岁的Frederick P. Brooks, Jr.。评选委员会主席 在致辞中提到，“今天我们所看到的计算机体系结构、软件工程及三 维计算机图形，均受益于Brooks 的开创性工作，是他改变了这些领 域的面貌。”Brooks确实是一位在计算机科学各方面均作出杰出贡 献的奠基者。
史前
今天
焦油坑
大型软件项目
• 图为洛杉矶自然历史博物馆 George C.Page馆内布拉雷亚 焦油坑的中生代情形想象图原 图
吞噬 成千上万的巨兽
围困 无数庞大的开发团体
11/49
软件开发中的焦油坑
“史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震 撼。上帝见证着恐龙、剑齿虎在焦油中的挣扎。它们挣扎的越是猛烈， 焦油越是缠的越紧，没有任何猛兽足够强壮或具有足够的技巧，能够 挣脱束缚，它们最后都沉到了坑底。” ——Brooks
– 计划开发时间：3年 – 实际开发时间：5年 • 公布数据： – 程序员人数：5,000人 – 代码行数：35,000,000 行代码 – 开发时间：5年 • 每位程序员每年生产多少行代码？
13/49
软件开发中的焦油坑
• 每位程序员每年生产多少行代码？ 以最不幸的情况来估计，每行代码都需要自己编写，得到 结果：35,000,000 行/(5000人*5年) = 1400行/人.年。 这个效率远远低于一名正常程序员的产出量。
15/49
焦油坑之一：进度滞后
“使用人月为单位来衡量一份工作的规模是一个危险和具有欺骗性的神话。它暗 示着人员数量和时间是可以相互替换的。”——brooks
• 人月神话 – 人月：参与开发的程序员数目 * 项目持续的月数 – 为什么说人月是神话？ （1）许多任务是无法拆解的 （2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加 以(n-1)*n/2的规模递增 20人* 5个月 > 50人* 2个月
• 精美的烹饪需要时间
• 软件开发项目常以人月来衡量工 作，这种度量暗示着人手和时间 是可以互换的。这种“人多力量 大”的想法是一种一厢情愿的虚 妄神话。
• Brooks法则：向滞后的软件项目 追加人手会使得进度更迟缓。
• 图为早年新奥尔良的安东尼奥法式餐厅的菜单
28/49
人月神话——外科手术队伍
对于许多小型的开发团队，加派人手是通常的解决方法？
20/49
焦油坑之二--缺乏沟通
• 巴别塔为什么会失败？
巴别塔：圣经中继“诺亚方舟”后人类第二个大工程，以失败告终
21/49
焦油坑之二--缺乏沟通
• 巴别塔为什么会失败？
......现在整个大地都使用同一种语言。在一次迁徙的过程中，人们发
现了苏美尔地区，并且在那里定居下来。他们说：“来，让我们建造
• 技术并非《人月神话》的着眼点，它更关注的是软件的创造过程、需 求的变化无常和管理的永恒困境。
• 《人月神话》的中心思想已经超越了具体的时代和技术。
5/49
名家谈人月神话
• 这是一本经典著作，与软件开发有关的每一个人都应该不只一遍地读 这本书。 ——Philippe Kruchten Rational 统一过程首席架构师