《人月神话》打动我的那些章节----论几十年前的软件工程开发理念在当代还有多少理论行得通（一）

前言：人月神话是写于1975年的一本软件工程论著，它描述了软件开发中出现种种问题和桎梏，虽然它所举例子距离我们相去甚远，然而在阅读的过程中我仍对其中的一些问题产生了共鸣。清晰的定义这些问题，迈出了预防并解决这些问题的第一步，它并不列举具体的解决方案，但是在更高的层面上提出了高效开发的可能的解决办法。

第一章 焦油坑--细小问题的累积给整个项目带来的巨大灾难。

一个程序员日常编写的是程序，它本身是完整的可以在作者开发的平台上运行的，但是这不能让程序变为更有用的，但是成本更高的产物。

按照普遍认可的的风格编写+完备的测试+完备的文档 = 编程产品

按照普遍认可的风格编写+符合预期的资源限制+与其他单元的协同测试 = 编程系统

编程产品 + 编程系统 = 编程产品系统

编程产品和编程系统的编写时间一般来说要消耗程序的3倍时间。

第二章 去除神话色彩的人月神话---项目滞后的罪魁祸首-不合理的进度安排

大型编程上的错误思考1 乐观主义假设，每一项任务都将运作良好，每一项任务仅花费它“应该”花费的时间，事实证明子任务的犬牙交错，让一切正常的概率接近与零。

错误思考2 人月的线性相关 事实上由于无法分解的任务和沟通成本的原因，”月“的缩短并不能靠”人“增加来完全实现，添加过多的人手反而会延长项目的时间。

错误的思考3 进度安排顺序限制给测试带来的巨大影响。

书中列举的软件进度安排经验法则：

1/3 时间计划

1/6 时间编码

1/4 时间构件测试和早期系统测试

1/4 时间系统测试，所有构件完成

错误思考4 空泛的估算 为了满足客户期望的日期而造成的不合理进度安排

非阶段化方法的采用，少得可怜的数据支持，再加上完全借助直觉的判断很难生产出有力的能够规避风险的估计。

错误思考5 重复产生的进度灾难

假设项目的第一个例程落后的情况下项目经理有哪些可选的方案呢，这里直接给出结论，就是通过添加更多的人手会使这一落后过程不断重复，从而导致需要添加更多的人手。以上几点是作者论述的去除神话色彩的人月，也是现代实际开发中遇到的问题。

第三章 外科手术团队 一个优秀团队的构建

十人团队的组成

	架构设计师（技术总管）
管理员		副手
文秘		程序人员
		工具维护人员
编辑		测试人员
文秘		语言专家