你知道人月么

读书笔记

---

【Brooks F P, Li Q. 人月神话[M]. 中国电力出版社, 2003.】
《人月神话》，软件工程行业的圣经级书籍，从无数前辈和网上的大牛口中听过对这本书的盛赞，因此这几乎是一本必读不可的书了。
这本书凝聚了作者从业数十年的经验，作者站在一个更高的角度指导我们在软件开发过程中会碰到的问题以及相应的解决方式，为人们管理复杂项目提供了最洞察力的见解。
这本书看完以后，书中有很多观点对我都有警示作用。虽然目前我仅仅是在实验室的一个小项目中担任负责人，但是很多管理理念却是想通的。而这些也就是贯穿整个软件开发过程中的。
书中第一个对我产生冲击的观念是对于软件任务的进度安排，作者认为合理的安排是

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

然而实际开发过程中，我们多半是用一大半的时间在编码，同时伴随着计划的不断更改，最后只预留一点时间做测试。而后期多半又会需要继续的测试以及bug修复。如果我们老板看过这本书的话，他应该就不会每次一提出需求就说这个只要半天那个只要两小时这种话了。
同时，作者还给了我们一个法则：向进度落后的项目中增加人手，只会使进度更加落后。这就是除去了神话色彩的人月。为什么这么说呢，一是新人加进来需要付出沟通成本，而原有的开发人员也会被拖慢速度来指导新人上手项目。这或许可以让我们意识到平常开发过程中我们在沟通上的花销到底有多大。
当然，作者还在书中举了一个例子来讲诉10人程序开发队伍的沟通模式。这个基础就是必须要有详细的职责划分，同时，要有唯一的可以进行意见统一的人。作者也给了我们一个困扰了很多人的式子，那就是：系统编程需要多少时间？研究结果表明，

$$工作量 = 常数 * 指令的数量^{1.5}$$
在程序员与产品经理的交互中，有以下是产品经理必须要牢记的事实：

• 牢记是开发人员承担创造性和发明性的实现责任
• 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法
• 对上述的建议保持低调和不公开
• 准备放弃坚持所做的改进建议

一般开发人员会反对体系结构上的修改建议。通常他们是对的—当正在实现产品是，某些次要特性的修改会造成意想不到的成本开销。这一段，希望所有的产品经理都能好好看看。
当然，书中还有很多其他的观点，我就不一一列举了，大家还是自己好好把书看看吧，确实是很有意义的。