今天在看一本讲述项目经理技巧和导读的国外读物《人月神话》。
其中有讲解得很棒的部分我收录了下来，大家也可以在download.csdn.net或bbs.phpchina.com找到电子书的下载。
乐观主义
书中最早提到的程序员的“乐观主义”，我想的确是一种非常普遍的现象，几乎概括了程序员中90%的人口。
而这种自信往往也是致命的，包括我在也内也存在这样的问题。因为其普遍性，和自我认知、察觉等因素，我认为没有必要再总结到这里来。（这个问题就象跟行一样，每个程序员都会有，但未必会去改变）
文中大量暗示一个重点：系统应该由尽可能少的人员来开发。因为协助沟通的人数将直接影响开发成本。
而最理想的开发团队人数应该是精英10人以内，这绝对比开发团队达上百人更有效率。团队人数越多，所需要的管理将乘倍增加。
（以下加色的部分是书中原文）。
人月
首先是人月部分，所谓人月就是指一种预估进度安排中使用的工作量单位。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
目前我们公司采用的开发人员管理方式就是文中所指的“可沟通分解任务”——人员和时间之间的关系。
沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解，因此这部分增加的工作量随人员的数量呈线性变化。
相互之间交流的情况更糟一些。如果任务的每个部分必须分别和其他部分单独协作，则工作量按照n(n-1)/2 递增。一对一交流的情况下，三个人的工作量是两个人的三倍，四个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的问题，情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用。
因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
系统测试
由于我们的乐观主义，通常实际出现的缺陷数量比预料的要多得多。因此，系统测试进度的安排常常是编程中最不合理的部分。
1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。
2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。 通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能保证。 特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。
另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现即将发布前，那么将付出相当高的商业代价。
实际上，上述的二次成本远远高于其他开销。因此，在早期进度策划时，允许充分的系统测试时间是非常重要的。
进度安排
我喜欢P.Fagg，一个具有丰富经验的硬件工程师的忠告：“避免小的偏差（Take no small slips）”。也就是说，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
文中指出，在项目没有按预期评估的进度发展时，如若加入新的开发人员，那么所消耗的培训时间将会更加耽误项目进度。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
简单、武断地重复一下Brooks 法则：
向进度落后的项目中增加人手，只会使进度更加落后。
——（Adding manpower to a late software project makes it later）
瀑布模式
我是第一次知道瀑布模式，其实这是我加入程序开发这个行业以来一次沿用的一种开发模式。之所以没有发觉和想去改变最大因素是项目规模和开发人数起到了绝对因素。不过我现在到是非常重视这个模式，也想要将它从我的日常开发中移除。
瀑布模型的谬误是它假设整个系统一次性地被构建，在所有的设计、大部分编码、部分单元测试完成之后，才为闭环的系统测试合并各个部分。
例如，设计实现会发觉有些体系结构的功能定义会削弱性能，从而体系结构必须重新调整。编码实现会发现一些功能会使空间剧增，超过要求，因此必须更改体系结构定义和设计实现。
所以，在把任何东西实现成代码之前，可能要往复迭代两个或更多的体系结构－设计－实现循环。
目前看到177行。
