《人月神话》读书笔记

作为一本软件行业里的经典书籍，这本书我有很多地方看不懂，因此只算是略读。这主要是我在工作时所看到和感受到的，今后可能还会经常遇到。

以下为原文引用

1、项目滞后的主要原因：

在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？

首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设：一切都将运作良好。

第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。

第三，由于对自己的估算缺乏信心，产品经理喝研发负责人通常不会有耐心持续地进行估算这项工作。

第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。

第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。

2、两个重要的谬误——人性的乐观和错误的工作量单位

在单个的任务中，"一切都将运转正常"的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，"不会延迟"仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。

第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的，但是在软件编程中几乎不可能。

3、为什么软件开发会功亏一篑？

通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能保证。特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。

4、千军易得，一将难求？

“软件经理很早就认识到优秀程序员和较差的程序员之间生产率的差异，但实际测量出的差异还是令我们所有的人吃惊。在他们的一个研究中，Sackman、Erikson 和 Grand 曾对一组具有经验的程序人员进行测量。在该小组中，最好的和最差的表现在生产率上平均为10:1；在运行速度和空间上具有5:1的惊人差异！简言之，$20,000/年的程序员的生产率可能是$10,000/年程序员的10倍。数据显示经验和实际的表现没有相互联系（我怀疑这种现象是否普遍成立。）”

5、为什么要先构建一个试验性的系统然后抛弃它？

“对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的办法——即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。而且，新的系统概念或新技术会不断出现，所以开发的系统必须被抛弃，但即使是最优秀的项目经理，也不能无所不知地在最开始解决这些问题。因此，管理上的问题不再是"是否构建一个试验性的系统，然后抛弃它？"你必须这样做。现在的问题是"是否预先计划抛弃原型的开发，或者是否将该原型发布给用户？"从这个角度看待问题，答案更加清晰。将原型发布给用户，可以获得时间，但是它的代价高昂--对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。因此，为舍弃而计划，无论如何，你一定要这样做。——唯一不变的就是变化本身

一旦认识到试验性的系统必须被构建和丢弃，具有变更思想的重新设计不可避免，从而直面整个变化现象是非常有用的。第一步是接受这样的事实：变化是与生俱来的，不是不合时宜和令人生厌的异常情况。Cosgrove 很有洞察力地指出，开发人员交付的是用户满意程度，而不仅仅是实际的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。”

6、解决软件根本问题的方法：

现在的技术中最有希望的，并且解决了软件的根本而非次要问题的技术，是开发作为迭代需求过程的一部分：快速原型化系统的方法和工具。软件系统的快速原型对重要的系统界面进行模拟，并演示待开发系统的主要功能。原型不必受到相同硬件速度、规模或者成本约束的限制。原型通常展示了应用程序的功能主线，但不处理任何如无效输入、退出清除等异常情况。原型的目的是明确实际的概念结构，从而客户可以测试一致性和可用性。

---

以下为我的经历和思考：

对于初创的中小团队来说，软件开发的逻辑应该是这样的：

• 小型、精干的队伍是最好的。（人与人的差距巨大且沟通成本巨大）
• 明确的用户群体和用户需求，需要非常明确。
• 为用户群的属性明确地记载各种猜测，清晰和错误都比模糊不清好得多。
• 快速开发原型化的产品验证用户需求，不需要任何实际的产品功能
• 保持产品概念的完整性需要由一个人或少数人来完成
• 步步为营，模块化的开发形式很有必要
• 文档记录的重要性。一是因为人会遗忘，即使是自己做的东西；二是在整个生命周期能对克服懒惰和进度的压力起到促进激励作用。三是开发人员必须为自己的开发设计决策进行明确说明，因为这涉及到个人职业尊严。
• 编辑代码只需一次，而查阅代码和测试代码将耗费远比编辑更多的时间，因此非常有必要为测试安排更多时间，并将测试前置。
• 为计划和分解计划安排更多的时间，以至于分配好团队的时间和减少扯皮
• 为开发任务设定节点里程碑，以至于无法自欺欺人时，开发者就会很少就里程碑的问题弄虚作假。
• 试验性的第一版本的产品在完成其使命之后就坚决抛弃。
• 为软件的研发留下冗余的时间，以免开发者因为乐观和时间估算不足而导致的延后，同时当延后发生时，坚决不为其增加任何人手，因为这样做是无效且随着时间会有相反效果。
• 唯一不变的只有变化本身。
• 开发人员交付的是用户满意程度，而不仅仅是实际的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化，因此保持适当幅度的迭代是必须的。
• 开发者绝不是搬砖的力工，而是创新者，他们身上的创新力才是他们职场生存和引以为傲的根本，而不是时间和代码的堆砌。可悲的是众多中高层并不这么认为，也有很多开发者从来不这样做，这两个致命的问题，前者会让众多软件公司不具备强有力的竞争力，后者会让众多程序员变成一个吃青春饭的过客，即赚不到很多钱也没有什么成就感，还会常感疲惫。

---

我们正在做一款辅助个人股票投资者降低决策误判概率的工具：【棱镜】，它能够将你的分析决策逻辑由文字和框架转化为算法，让计算机和算法辅助你共同决策并给出决策反馈，并检验你的逻辑在过去各类情况下是否会犯错，以辅助你降低决策误判的概率，欢迎来玩。