人月神话

乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误” 人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。

系统开发的时间安排 1／3 计划 1／6 编码 1／4 构件测试和早期系统测试 1／4 系统测试，所有构件已完成 需要特别指出的是，不为系统测试安排足够的时间简直就是一场灾难

简化Brooks的法则：向进度落后的团队增加人手，只会让进度更加落后。

它们挣扎得越猛烈，焦油就纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去了解问题。

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

因为软件开发本质上是一项系统工作棗错综复杂关系下的一种实践棗沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

首先，苦恼来自追求完美。 其次，苦恼来自他人来设定目标、供给资源和提供信息。 最后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。

在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会仔细谨慎地工作。 一种普遍倾向是过分的设计第二个系统，向系统添加很多的修饰功能和想法，他们曾在第一个系统中被小心翼翼地放在次要位置。

他们还缺乏两个方面﹣交流，以及交流的结果﹣组织。

非正式途径：电话… 会议：常规项目会议 工作手册：在项目的开始阶段应该准备正式的项目工作手册。

它是对项目必须产出的一系列文档进行组织结构的一部分

让我们考虑一下树状编程队伍，以及要使他们有效，每棵子树所必须具备的基本要素： 1、任务（a mission） 2、产品负责人（a producer） 3、技术主管或结构师（a technical director or architect） 4、进度（a schedule） 5、人力的划分（a division of labor） 6、各部分之间的接口协议（interface definitions among parts）

1、技术主管和产品经理是同一个人。适用于6人左右的团队，通常这两种技术兼具的人相当少。 2、产品负责人指挥，技术主管充当左右手。这种情况相当难，很难在技术主管不参与任何管理工作的同时，建立起其在技术上的权威。 3、技术主管作为总指挥，产品经理作为其左右手。还是适用于小型团队。

•为什么要有正式的文档 首先，书面记录决策是很有必要的。只有记录下来，分歧才会明朗，矛盾才会突出。 第二，文档能够作为同其他人的沟通渠道。 最后，项目经理的文档还可以作为数据基础和检查列表。

•试验性工厂和增大规模 对于大多数项目，第一个开发的系统并不合用。现在的问题是“是否构建一个实验性的系统，然后抛弃它” 为舍弃而计划，你一定要这样做

抛弃原型的概念本身就是对事实的接受﹣随着学习的过程而改进

∙为变更计划系统 变更的阶段化是一种必要技术。每个产品都应该有相应的数字版本号。

•为变更计划组织架构 为变更组建团对比为变更进行设计更加困难。当系统发生变化时，管理结构需要进行相应的调整。 老板必须对他们的能力培养给予极大的关注，使管理人员和技术人员具有可换性。

•前进一步，后退两步 程序维护中的一个问题﹣缺陷修复总会以固定（20%~50%）的几率引入新的bug

软件开发是熵减的过程，所以它是处于亚稳态的，软件的维护是处于熵增的过程，只是放缓了系统退化到亚稳态的过程。

•里程碑还是沉重的负担 里程碑的选择只有一个原则，那就是必须要是具体的，特定的，可度量的事件，能够清晰定义。 里程碑的边界和明显没有歧义，比他容易被老板核实更为重要。

∙“其他的部分反正会落后” 并不是每一天的滞后都是灾难 随着项目的推进，PERT图为前面那个泄气的借口，“其他部分反正会落后”提供了答案。它展示了某人为了使自己的工作远离关键路径，需要超前多少，也建议了补偿其他部分失去时间的方法。

第一份PERT图通常是很恐怖的

•地毯的下面 有两种掀开毯子把污垢展现在老板面前的方法，它们都必须被采用。一种是减少角色冲突和鼓励状态共享，另一种是猛地拉开地毯。

我主张在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计

我主张在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反应一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。

概念完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。实际工作被划分为体系结构、设计实现和物理实现，但这并不意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系统将会开发得更快，所需要的测试时间将更少。同工作的水平分割相比，垂直划分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅提高。

软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。 一旦认识到试验性的系统必须被构建和丢弃，具有变更思想的重新设计不可避免，从而直面整个变化现象的思想是非常有用的。第一步是接受这样的事实：变化是与生俱来的，不是不合时宜和令人生厌的异常情况。 用户的实际需要和用户感觉会随着程序的构建、测试和使用变化。

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

所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。