前言:人月神话是写于1975年的一本软件工程论著,它描述了软件开发中出现种种问题和桎梏,虽然它所举例子距离我们相去甚远,然而在阅读的过程中我仍对其中的一些问题产生了共鸣。清晰的定义这些问题,迈出了预防并解决这些问题的第一步,它并不列举具体的解决方案,但是在更高的层面上提出了高效开发的可能的解决办法。
第一章 焦油坑--细小问题的累积给整个项目带来的巨大灾难。
一个程序员日常编写的是程序,它本身是完整的可以在作者开发的平台上运行的,但是这不能让程序变为更有用的,但是成本更高的产物。
按照普遍认可的的风格编写+完备的测试+完备的文档 = 编程产品
按照普遍认可的风格编写+符合预期的资源限制+与其他单元的协同测试 = 编程系统
编程产品 + 编程系统 = 编程产品系统
编程产品和编程系统的编写时间一般来说要消耗程序的3倍时间。
第二章 去除神话色彩的人月神话---项目滞后的罪魁祸首-不合理的进度安排
大型编程上的错误思考1 乐观主义假设,每一项任务都将运作良好,每一项任务仅花费它“应该”花费的时间,事实证明子任务的犬牙交错,让一切正常的概率接近与零。
错误思考2 人月的线性相关 事实上由于无法分解的任务和沟通成本的原因,”月“的缩短并不能靠”人“增加来完全实现,添加过多的人手反而会延长项目的时间。
错误的思考3 进度安排顺序限制给测试带来的巨大影响。
书中列举的软件进度安排经验法则:
1/3 时间计划
1/6 时间编码
1/4 时间构件测试和早期系统测试
1/4 时间系统测试,所有构件完成
错误思考4 空泛的估算 为了满足客户期望的日期而造成的不合理进度安排
非阶段化方法的采用,少得可怜的数据支持,再加上完全借助直觉的判断很难生产出有力的能够规避风险的估计。
错误思考5 重复产生的进度灾难
假设项目的第一个例程落后的情况下项目经理有哪些可选的方案呢,这里直接给出结论,就是通过添加更多的人手会使这一落后过程不断重复,从而导致需要添加更多的人手。以上几点是作者论述的去除神话色彩的人月,也是现代实际开发中遇到的问题。
第三章 外科手术团队 一个优秀团队的构建
| 架构设计师(技术总管) | |
管理员 | | 副手 |
文秘 | | 程序人员 |
| | 工具维护人员 |
编辑 | | 测试人员 |
文秘 | | 语言专家 |