作者：FrederickP.Brooks.Jr   阅读时间：2012.8.30      回首评分：8.5 分

回首小评：《人月神话》是一本关于项目管理的方面的书籍，内容源于作者Brooks担任项目经理时的经历。这本书让我记忆最深的内容有两点：一是我们在对项目做预估时总是过于乐观，其实项目进行中会有各种风险出现；另一个是人月不能简单互换，向已经延后的项目中投入更多的人力不一定能按预期加速项目的进行。之前写过的那篇《加班之我见》中，很多思想也是源于《人月神话》这本书。本书的内容不多，读起来并不吃力，可以为项目管理人员尤其是新手提供一种思路。无论是从事研发工作还是产品经理的工作，对于项目都应有一个整体的概念，这本书就能满足这一点需求，所以还是推荐大家用几天时间过一遍，了解几点重要的思想与法则。

笔记：

1. 创造性活动分为三个阶段：构思、实现与交流（与用户）。

2.在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。

3.导致不合理安排的原因：过于乐观、假设人月可以互换、缺少监督、当意识到进度偏移时下意识的反应是增加人力。

4. 可以让200人去解决问题，而仅仅需要协调其中的20人即可，他们是那些关键的人。

5. 概念的完整性的确要求系统只反应唯一的设计理念。（少数人决定）

6. 架构师应：

（1）牢记开发人员承担创造性和发明性的责任，所以架构师只能建议，而不能支配。

（2）时刻准备为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法。

7. 项目开始前应考虑：是否有清晰的目标？人力？材料？足够的时间？足够的技术？充分的交流与组织？

8.   产品负责人组件团队、划分工作以及制定进度表，他争取并一直保证必要的资源，主要工作是与团队外部进行向上的沟通和水平沟通。他建立团队内部的沟通和报告方式，最后他确保进度目标的实现，根据环境的变化调整资源和团队的构架。

9.   对于常用的编程语言，生产率似乎是固定的。这个固定的生产率包括了注释和可能存在的错误。使用适当的高级语言，编程的生产率可以有较大提升。

10. 软件项目文档：目标、资源、产品技术说明（以建议书开始，以用户手册和内部文档结束）、时间、资金、人员、地点。

11.许许多多的失败完全是由那些产品未精确定义的地方导致的。细致的功能定义，仔细的规格说明，规范化的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量。

12. 进度表中的里程碑必须是具体的、特定的、可度量的事件。一定要明确定义，这样很少有人会弄虚作假。

13. 老板得到计划偏离的信息时，不要对项目经理自己可以解决的问题作出安排，这样不会压制信息公开。

14. 用户文档：目的（功能？开发原因？）、环境、范围（有效输入、输出）、功能与算法、格式、用户选项。

15. 测试用例：

（1）大部分为对常规数据测试的用例。

（2）小部分合法边界用例。

（3） 小部分非法数据。

16. 段落注释有助于自文档化。

17. 没有银弹，没有一种策略、技术或技巧可以极大地提高程序员的生产力。

18.良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。

19. 向进度落后的项目增加人手，只会使进度更加落后。（工作中断、培训、沟通）

20. 概念完整性是产品质量的核心，拥有一位架构师是迈向概念完整性最重要的一步。

21. 有必要使设计队伍共享一幅相同的用户图像，需要把用户群的属性记录下来，包括他们是谁、他们需要什么、他们认为自己需要什么、他们想要什么。

22. 清晰和错误都比模糊不清好得多。