《人月神话》笔记

这本书算是软件工程管理的圣经，之前看过了纸质书，这回又听了一遍音频的。本文是音频书的笔记，简洁版。

人月：一个人在一个月所完成的工作量。

作者弗雷德里克·布鲁克斯，本书首版：1975

1、什么是“人月神话”？

不能简单的用 人月工作量 来换算出可以加入多少人来开发，就能保证项目进度完成。

比如，一个工作量为10个人月的项目，如果只有一个人做，那么需要10个月才能完成；软件工程的管理人员想一个月就完成，于是，他认为，只要再加入9个人，那么，这10个人就可以在一个月的时间里完成项目。

然而，实际情况却并非如此。因为软件工程的各项工作之间，往往有一个前后承继的关系，得完成一项，才能进行另一项。加进来的人手，并不能马上就开展后面的工作。所以，想要通过增加人手来缩短工程时间，其实只是一个“神话”。

2、“人月神话”反映出项目管理中怎样的难题？

“人月神话”所反映出的，是软件开发在项目管理中遇到的难题：管理人员因为盲目乐观，在计算项目的工作量和交付时间上采用了错误的计算方法，忽略了团队细节对整体的巨大影响，这就很可能导致项目延期。

3、如何靠近这个神话，进行有效的项目管理。

a.以小团队的方式开展工作

让优秀的人作为整个团队的核心来开展工作；团队中其他人各司其职，作为辅助来完成整体工程。这就是外科手术团队的奥秘，即以主刀医生为核心，其他像负责助理医师，麻醉师，护士等人都是为主刀医生服务的，大家各司其职、齐心协力，从而保证手术可以顺利完成。

这个思路，反映到软件工程管理上，就是：首席程序员或者架构师充当主刀医生的角色，而团队管理者充当副手或者服务人员，其它团队成员则分别负责单元代码编写，功能单元测试，文档管理，工具开发以及技术专家支持等职能。即使整个项目团队人数庞大，只要根据工作边界，将大家划分到一个个类似外科手术队伍那样的小团队当中去，就可以保障项目在一定程度上的效率提升。

b.有效沟通

记录电话会议的内容，定期召开统筹项目进度的例会，对数据结果进行监督和全员反馈、使用产品文档、“手把手带”方式、思维导图 等等。

c.注意一个个微小的错误，发现错误刚有苗头或征兆时，就加以预防与制止，坚决不让它继续发展，造成更严重的问题。

软件工程是一个复杂的项目，作者建议：

• 设立关键节点(“里程碑事件”)，保证100%完成目标，明确了大家的目标。一般由项目管理者设立。
• 为项目设立一个专门的规划和控制小组。该小组行使监督和管理进度的职责，对相关目标进度进行检查和汇报，帮助项目管理人员获取最新进展，可以避免团队之间相互推卸责任。
• 项目管理人员必须要认清这样一个现实，那就是：“唯一不变的就是变化”。对程序进行模块化设计、版本号记录 等等方法。
• 为了避免项目延迟和失败，要尽可能地提前集成测试。(持续集成)

4、软件工程中，没有“银弹”。人月神话中的一些问题，根源在于软件工程本身的特性，是无法彻底解决的。

“银弹”在西方是用来杀死狼人的白银子弹。这里用来表示彻底解决问题的招数或者技能。

没有银弹的2个原因：

• 一，计算机技术的发展太快了。硬件、软件都在飞速发展。每一次的新技术学习都是挑战。
• 二，软件研发本身的内在特性也制约了软件工程的进展。作者用四个词概括这种特性：复杂性、一致性、可变性、不可见性。各特性说明如下：

复杂性表现在：
a.技术需求复杂性：比如，用户想要什么产品，他自己很多时候是描述不清楚的，大多数用户只是说“我想做个app”，“帮我开发一个XX管理系统”…… 要把这种需求梳理清楚，然后交给架构师和软件团队去设计和实现，这整个过程是很复杂的，牵扯很多角色的管理与相互协作：需求分析师、产品经理、设计师、交互设计师、架构师、技术工程师等等。
b.组织管理复杂性：除了计算机领域，其它领域也有这个难题。刚刚上面提到的各个角色的协调就很复杂。
c.计算机系统的复杂度

可变性：无时不刻的变化存在着。程序员埋怨产品经理改需求频繁、产品经理又要面对运营的各种要求、运营又在接受用户的各种抱怨。用户需求在变，业务环境在变，竞争对手也在变。这时根本困难，无法改变的软件工程的可变性。我们唯有拥抱变化。

一致性：软件工程师面对无规则可言的复杂因素，想通过一个规则来减轻彼此的负担是不现实的。

不可见性：软件是一种思维的产物，它看不到也摸不到。沟通的双方只能通过语言来表达思维过程。自然会产生交流和认知困难。

5、如何尽可能的改善“没有银弹”这种困境

第一个建议，采用新技术。

第二个建议，先“快速开发原型”，后再做“增量开发”，迭代版本。

第三个建议，人才。卓越的设计人员的重要性。