《人月神话》读书笔记-优快云博客

本文链接：https://blog.youkuaiyun.com/rt_tryqc/article/details/142758626

写在开头：因为在很多场景，比如面试或读书分享会，都有提问或交流 —— 你最近看了哪些专业相关的书籍。这里打算做个系列，算是读后便签，可以快速回顾。（有时来不及读，就看这小抄）

作者是美国人，书写于50年前（1975年），讲的是软件工程项目管理。书中倒没有什么高深的技术代码。读这本书，你会感叹 —— 历史是有着重蹈覆辙感的螺旋上升，目前的项目和50年前的项目，有时二者遇到的问题，似曾相识。【这本书还有“20周年纪念版”，也就是30年前】

作者被认为是“IBM 360 系统之父”，他担任了 360 系统的项目经理以及 360 操作系统项目设计阶段的经理 —— 由此可见，他拥有丰富的项目管理经验，什么排期啊人员安排，应该自是不在话下。

“人月” || “人天” || “人年” —— 无论多少个母亲，孕育一个生命都需要十个月

完全人数和时间的互换 —— 割小麦或收获棉花

项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。培训和沟通都要时间。

结论：即人力（人）和时间（月）之间的平衡，远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。[ “除去了神话色彩的人月” -- 盲目向落后的项目增加人手，并不能创造神话 ]

对于软件任务的进度安排，作者以自己多年的管理经验总结出如下法则：

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

【外科手术队伍】

注意：大家是合力做一件事，（相反，如果是均分每个人不同任务，就容易矛盾争吵）

一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力

大型项目团队扩建：更多人去解决问题，更少人(比如20个)协调

[系统体系结构设计在概念上具有完整性，和技术实现有界限/分离，这样工作易于管理]

易用性实际上需要设计的一致性和概念上的完整性

产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖结构师一样

任务里程碑/关键节点 - 没有达到预期，采取关键措施；达到预期，鼓舞人心【必要时提前干预】

· 注意新人的培训和磨合也需要时间，估算有效的人月 .

文档的重要性（精确比生动更加重要、一致性）；早测试、多测试；周会年会（半年一述职）；

讨论结果形成书面文字：

"正式的书面建议集中了注意力，强制了决策的制订，避免了会议草稿纪要方式的不一致"

概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。

Boehm 的 COCOMO 模型发现团队质量目前是项目成功最大的决定因素，实际上是下一个次重要因素的 4 倍。现在，软件工程的大多数学术研究集中在工具上。

项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。

正确的文档结构非常重要。事先将项目工作手册设计好，能保证文档的结构本身是规范的，而不是杂乱无章的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节中。

【画蛇添足】—— 本章讨论了“ 第二个系统是设计师们所设计的最危险的系统 ” —— 他着手第三个或第四个系统时，先前的经验会相互验证，而第一个系统，会因为经验和时间等，还有对未来“下一个”的期望，更注重完成度，相对克制。

有些人开发第二个系统时，往往全力挥洒自己的创造力，从而使产品不够简洁易用或过多冗余，甚至难以完成开发。

special 观点：