这是50年前的一本关于30年前软件开发经验的书。

布鲁克斯法则

谚语与布鲁克斯法则同出一辙，特别是某些不可分割或者并行的工作。

这是一本来自改革开放之前的书，在软件工程界至今仍有不可撼动的地位，可以称为软件行业的《共产党宣言》，具有极高的指导思想意义。书如其名，本书的多次重印让其价值越来越宝贵，或将是软件工程界的神书。一开始我被这个名字吸引了，在不知道是软件工程方面的书籍的前提下认为这是一本科幻书，读了才知道人月是一个衡量项目任务量的单位。

本书的贡献在于编程和项目管理上，在相关领域学习和工作的读者可以开卷吸收。有很多经验，现在拿来还具有指导意义。由于讲解的是人和团队，因此读者不限于专业，均可读。

读后感

我是第一遍读这本书，云里雾里，但是坚持读完了，先有个印象。现在的段位还不能够体会其中之美，看了很多名人评价有的读了四五遍。因此，本书可以重复重复再重复的读，每个阶段对此的理解会不相同。又或者是因为中文翻译的问题，不是原汁原味，书中多处晦涩难懂，有不流畅的体验。

佛雷德里克·布鲁克斯履职事迹

时间段	参与工作
早期	计算机编程
1956-1963	硬件架构
1964	OS/360经理

重点语句摘抄

章节	章节名称	语句
0	序言	维持产品自身的概念完整性。
1	焦油坑	学习编程最难的部分就是将做事的方式向追求完美的方向调整。
2	人月神话	在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其它所有的因素加起来影响还要大。
3	外科手术队伍	同每个成员截取问题的某个部分的做法相反，由一个人来完成问题的分解，其他人给予其支持，以提高效率和生产力。
4	贵族专治、民主政治和系统设计	对于大型项目来说，将设计方法、体系结构与具体实现相分离是获得概念完整性强有力的方法。
4	贵族专治、民主政治和系统设计	项目经理如何避免开发第二个系统所引起的后果，从而避免画蛇添足须坚持拥有至少两个系统以上的开发经验的结构师的决定。
5	画蛇添足	项目经理如何避免开发第二个系统所引起的后果，从而避免画蛇添足须坚持拥有至少两个系统以上的开发经验的结构师的决定。
6	贯彻执行	将定义书写成文字，必须对很多原先并不是非常重要的问题进行判断，并得出结论。
8	胸有成竹	对常用的编程语言来说，生产率是似乎是固定的；使用高级的编程语言，编程的生产率可以提高5倍。
9	削足适履	开发人员要有从系统整体出发和面向用户的态度。
10	提纲挈领	任何管理任务的关注焦点是时间、地点、任务、项目内容和资金。
11	未雨绸缪	对于一个广泛使用的程序来说。维护总成本通常是开发成本的40%或更多。
12	干将莫邪	每个骨干人员都仔细地保管自己工作生涯中搜集的一套工具集。
13	整体部分	关键的部分是产品的定义：细致的功能定义，仔细的规格说明、规范化的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量。
13	整体部分	阶段化、定期变更。
14	祸起萧墙	好的里程碑对团队来说是一项服务。
15	另外一面	“自文档化”的思想可以得到大规模的应用。
16	没有银弹	构建专家系统的前提条件是拥有专家。
16	没有银弹	最重要的工作是寻求培养优秀设计人员的途径。
16	没有银弹	产品的技术特色最终依赖于设计人员。
17	再论“没有银弹”	思索的层次越高，所需要处理的基本思考要素也就越多。

软件项目管理任务安排

一般情况下的软件任务时间分配安排比例如下所示，实际上系统测试需要留出1/2的时间来应对。

2022

February

March

April

May

June

July

August

September

October

November

December

计划(1/3) 编码(1/6) 构建测试和早期系统测试（1/4）系统测试（1/4）软件任务

软件任务安排情况

编程队伍元素组成

元素	功能
任务
产品负责人	组件队伍、划分工作及制定进度表；与团队外部进行向上的沟通和水平的沟通，建立团队内部的沟通和告方式；确保进度目标实现，根据环境变化调整资源和团队的架构。
技术主管或结构师	构思设计，识别系统子部分，提供设计的一致性和完整性；控制系统的复杂程度。
进度
人力的划分
各部分之间的接口定义

其中产品负责人和技术主管的角色存在三种组合方式。

项目规模	组合方式
小（3-6人）	合二为一
中、大	左（产品负责人）主右辅
小	右主左辅

培养优秀的设计人员

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

这是50年前的一本关于30年前软件开发经验的书——《人月神话》读书笔记