注：

本文为《我的读书笔记之人月神话》系列的第一篇，欢迎指正。

=============================================================

文章的开头是很美的一段：

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.
美食的烹调需要时间；片刻的等待，更多美味，更多享受。

—- Menu on restaurant Antoine, New Orleans.

相信所有的饕客都会对此感同身受，频频点头。作者可能是想藉此说明，软件开发就如同美食烹调，都是循序渐进，有章可循的。贸然跃进，可能只会适得其反。

接下来，开篇就提出了全书最重要的观点：人月(Man Month)不能互换。

长期以来有一种观点认为，一个软件项目，如果需要3个人做4月的话，那么4个人做3个月也可以完成。通俗的来讲，就是效率（或者说进度）会随着人数的增派而相应提升，从而缩短了整体的时间。事实上，在阅读此书之前，排除一些细小因素（比如人员个体差异等），我大体上也是这么想的。

不成立的原因有很多，作者给出了如下几点（每项后面的是我的注解，下同）：

1. 项目时间依赖于顺序上的限制

确实如此，但如果每个环节上都增派了人手，似乎对进度提升还是有帮助的。

2. 人员培训和交流的时间更多

这个就是我所说的个体差异了。但是交流成本的增加确实是我事先没有想到的。

3. 有些任务是不能拆解的，添加人手对进度没有帮助

碰到过类似情况，有一个任务在身，Leader分配了另外一人来帮忙，结果给他解释的功夫自己做完都足够了。

4. 人员的增加会引起模块的重新划分，从而导致测试的延长

没有想到过，但是觉得很有道理。

当然，对于何时成立的情况作者也给出了说明（如图所示）：

也就是当 y = N/x （N为常数，即总的工作量）的时候才成立，换句话说就是两者（人力，时间）乘积恒定为常数。当然这是我的分析，作者并未明确指出这一点。

另外，他还列举了缺乏合理进度安排的若干原因：

1. 对估算技术缺乏有效的研究

这个尚待研究，确实需要补充学习。

2. 错误的隐含假设人、日可以互换，将进度与工作量混淆
3. 由于缺乏信心，软件经理不会有耐心持续估算
4. 对进度缺少跟踪和监督

有经验的项目经理可能会在这方面做一些努力和尝试，但是目前为止我还没有见到过实际应用中特别成功的例子。

5. 意识到进度有偏移时，下意识的反应是增加人力

wrong decision!

最后作者给出了他认为的进度安排的经验法则：

• 1/3计划
• 1/6编码
• 1/4构件测试和早期系统测试
• 1/4系统测试，所有的构件已完成

放在目前中国的大部分项目上来看，可能很少有团队能够按照这个比例来做事。这个也有可能是跟他所从事的一直是大型项目（比如IBM的OS/360）有关，到那个Level的感觉就不是我现在所能体会的了，但有了良好的设计做前提保障，编码确实是可以花最少时间的部分。

作者中间还放了一个煎蛋的启示：

如果煎一个鸡蛋需要2分钟，而客户想在1分钟内得到，那么只能坚持让他等待，或者生吃。否则蛋会因为火太旺而变得一半焦，一半却是生的。

即：

不要为了满足客户的期望，而设定不合理的进度安排（坚持自己的估计——基于充分的经验和直觉）

从我有限的项目经验来看，中国的客户更倾向于做上帝。他们可能希望你在指定时间内把产品交付出来，至于说后期的bug之类，可以慢慢补（菜里面忘记放盐了，不好意思，我再回一下锅 ）。而国外的客户则更青睐于使用相对比较成熟和稳定的产品，而不是依靠后期的不断修正（微软，我不是故意说你的 ^_^）。

最后，以Brooks法则来结束此文：

向已经进度落后的项目中增加人手，只会使进度更加落后。
Adding man power to a late software project makes it later.

顺便提一下Solution：重新安排进度；削减任务。

先到这里吧。