浅读人月神话（1）

读书笔记：

      今日翻书浅读人月神话几个章节，从《序言》开始至《贯彻执行》结束，布鲁克法则值得背诵牢记，关于《贯彻执行》章节并未看懂，需要再次研读。

章节	笔记感想
序言	1.维持产品自身概念完整性
焦油坑	1.问题累计增多便成为焦油坑淹没开发团队 2.编程的过程注定难以理想化
人月神话	1. 人员数量和时间不可替换，进度和工作量也不可相互混淆 2. 在估算不可得时，项目经理有必要坚持个人判断 3. Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后
外科手术队伍	1. 各司其职，手术室只听一人指挥
贵族专制、民主政治、系统设计	1. 概念完整性要求设计只由一人或者少数人实现 2. 工作的垂直划分优于水平分割
画蛇添足	1. 项目经理必须坚持至少拥有两个系统以上开发经验结构师的决定
贯彻执行	1. 将事物定义，通过定义取得想要的答案，保证系统概念完整性

名词注解：

1. 线性收敛：设序列xk趋向于x0,而且 lim |x(k+1)-x0|/|xk-x0|=a,当k趋向无穷大 如果0<a<1,则xk是线性收敛的。如果a=0,则xk是超线性收敛的。 因为区间长度是之前的1/2，所以这里a是1/2，故线性收敛。

调试和查错往往是线性收敛的：在修BUG过程中，每次收敛的量是一定的。

2. 焦油坑：类似沼泽，越挣扎越深陷，大型系统开发就像是焦油坑，当问题纠缠累计，项目就深陷其中无法达成既定目标。

3. 巴科斯范式：以美国人巴科斯(Backus)和丹麦人诺尔(Naur)的名字命名的一种形式化的语法表示方法，用来描述语法的一种形式体系，是一种典型的元语言。

摘录：

1. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所 有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？ 首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但 并不真实的假设——一切都将运作良好。 第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互 混淆。 第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工 作。 第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程 序，在软件工程中常常被认为是无谓的举动。 第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用 汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会 导致灾难的循环。

2. 然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后 的次序，从而一切正常的概率变得非常小，甚至接近于无。

3.用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的

4.向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）

5. 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计， 确信自己的经验和直觉总比从期望派生出的结果要强得多。

6. Harlan Mills 的提议提供了一个崭新的、创造性的解决方案。Mills 建议大型项目 的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来进行问题的分解，其他人 给予他所需要的支持，以提高效率和生产力。

7.项目经理如何避免画蛇添足（second-system effect）？他必须坚持至少拥有两个系 统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题， 确保原则上的概念和目标在详细设计中得到完整的体现。