《人月神话》的读书笔记

分类： 管理

• 1. 编程是一个痛并快乐的活动。痛点：（1）编程是一个逆熵的过程，但是这个世界是增熵的过程，所以需要你付出艰苦的努力。（2）目标、资源自己说了不算，需要别人提供。（3）寻找琐碎的bug。快乐：（1）是一种创造性的活动，是一种类神的活动。（2）自己的产出，能对别人提供帮助。（3）看到他们精妙的运作，犹如齿轮啮合一样精妙的运转。（4）易于进行概念上的实现和重构。
• 1. 对进度的估算普遍偏乐观，甚至用人月去估算工期。因为实际工作中，把项目分解完之后，人与人之间是有沟通的工作量的。从而添加人手，却使这种网状的沟通更多复杂，导致工期更加延长。作者提供了一个进度的经验法则：3644。1/3计划、1/6编码、1/4构件测试和早期系统测试、1/4系统测试。其中近一半的时间是测试。Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。
• 1. 对于一个大型项目而言，不能采用一拥而上的方式去做，而应采用外科手术式的方式。由一个人A进行项目的架构（保持概念上的完整性）和设计，其他人提供他所需要的支持。下面是沟通模型。

1. 概念的完整性

4.1无规矩不成方圆。一个人去设计或少数几个人去设计的确带来了效率上的提升和概念上的完整性。对工作进行垂直分割避免了一些重复性的工作和沟通的时间。工作的水平分割：比如把一个系统分成多个模块，每个模块让一个人去设计，这样就会导致会有许多人去进行设计，并且设计风格都不一样，还要花费很多时间进行模块之间的交流。

4.2体系结构、设计实现、代码实现其实是可以并行的。

5.对结构师的建议

（1）进行成本估算的时候，与承包商及早沟通修正成本

（2）对实现人员进行建议而不是支配。

（3）对系统进行第二次升级的时候，不要添加太多的功能与想法。

1. 贯彻执行

（1）用户手册及其版本更新，并体现在进度表中。以保证一致性。

（2）周例会和年度大会

（3）产品测试并且需要尽早着手。

1. 为什么巴比伦塔会失败？

交流和交流的结果–组织，是成功的关键。对于小型的团队来说产品负责人和技术负责人最好是同一个人。对于大型项目产品负责人作为管理者是更合适的安排。组织中的交流是网状的，而不是树状的。

1. 编程人员的生产率

每项工作花费的时间大约是估计的两倍。人员在一周的时间中不是只编程，还有其它许多事情要做。

1. 总体规划

培养编程人员从系统整体出发、面向用户的态度。数据的表现形式是编程的根本。

1. 文档

项目管理人员主要工作是沟通、制定计划、实现计划。但是只有书面计划是精确和可以沟通的。

1. 唯一不变的是变化

（1）第一版的系统必须抛弃。

（2）技术人员与管理人员的职位要能够同级互换。

（3）修复bug会以（20-50）%的机率引入新的bug。软件开发是减少熵的过程，而维护软件是增加熵的过程。

1. 维护工具

（1）分配一部分开发资源给通用的工具开发小组。

13.系统性的考虑

（1）自顶向下进行结构化的设计。（2）阶段性的变更，而不是频繁变更。（3）重视测试平台的搭建和测试用例的准备。

1. 进度的落后

进度监督人员是早期预警系统，防止项目慢慢落后。

1. 流程图

此处的流程图不是那种非常标准的流程图，很少有编程人员在编码之前会画标准的流程图，只要能表达清楚就可以，而且往往上线之后才会画。不要过于迷信流程图。对于文档整理，作者给出的方案是把文档整合到代码中。

1. 没有银弹

软件是根植于应用，用户，自然及社会规律、硬件的、不可见的。它的根本性困难是在设计上，而不是实现上。增量开发，而不是一次性搭建系统。

1. 反思

17.1软件工作是一个创造性的工作，其中人是关键的因素。所以管理者所做的应该是：对人的重视和尊重，比如： 不受打扰的环境，关注、激励、培养。

17.2开发软件也是一个主动性的工作，不要打击员工的积极性。

17.3软件开发是一个系统性的工程，对结构划分是十分重要的，结构之间是通过接口通讯的，隐藏了内部的实现方式。

17.4它更接近社会学而不是科学技术，不需要大量的数学知识做支持。

17.5模块复用是一个美丽的愿景，但现实还有很大的差距。

17.6让系统层次化（分层的理念）、增量化（敏捷式开发）。

目录