总览

巴比伦塔为什么失败

他们具备了很多的条件，失败的原因在于

• 交流

• 交流的结果-组织

当交流的缺乏导致了争辩，沮丧和群体猜忌之后，大家选择孤立，而不是争吵。

缺少交流

项目设计手册应该做好，未来的产品将会基于他，并且要控制信息发布，以确保信息可以达到所有需要它的人手里。

系统编程需要多少时间？

编程大约只占 1/6。但是根据小型项目的估时没法得出大型项目的估时的，就像用百米跑的记录推算跑 1 英里的时间是不对的。

工作量 = 常数 x 指令的数量的 1.5 次方

• 对于常用的编程语句，生产率是固定的

• 使用适当的高级语言或特性，编程的效率可以提高 5 倍

提纲挈领

文档是集中考虑，并使各种讨论意见明朗化的主要时刻。可以终止项目无休止的混乱状态。文档本身可以作为检查列表，状态控制，也可以作为汇报的数据基础。

文档需要包含的内容：

• 目标：定义待满足的目标

• 技术说明：手册以及性能说明

• 进度

• 预算

• 组织结构图

• 工作空间的分配

• 报价，预测和价格

为什么要有文档？

• 只有书面记录下来，分歧才会明朗，矛盾才会突出。书写过程中的无数细小决定才能让人们从混乱的现象中找到清晰，确定的策略

• 文档能够作为同其他人的沟通渠道。很多应该被普遍认同的策略，完全不为团队的一些成员所知

• 只有书面计划才是精确并且可以沟通的

书面记录让我们做很多细微的决定，并能保证传达的效率和广泛度。

唯一不变的是变化

大多数项目，第一个开发的系统并不合用。是否要预先计划抛弃原型的开发或者将该原型发布给用户。

变化是与生俱来的，不是不合时宜和令人生厌的异常情况。开发人员交付的是用户的满意程度

软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。所以我们要：为了变更设计系统！

前进两步，后退一步

对一个广泛使用的程序，维护总成本通常是开发成本的 40%或更多。缺陷修复总会以(20%~50%)的几率引入新的 bug，整个过程是前进两步，后退一步。

随着时间的推移，系统会越来越无序，修复工作迟早是去根基。尽管系统理论上一直可用，但实际上，系统的面目全非，无法再成为下一个进展的基础。

系统软件开发是减少混乱度的过程，本身是亚稳态的。软件维护是提高混乱度的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

开发者必须时刻保持警觉，经常重构，以优秀清楚的设计来应对这个过程！

干将莫邪

开发和维护公共的通用编程工具的效率更高。对这类工具的开发不能吝啬人力和物力。交互式编程的生产率是原来的 2 倍。

变更必须被阶段化，并且定期发布。每个用户拥有稳定的生产周期，这种方法与持续波动所造成的混乱无序要好一些。

看到这句想到我们固定了发布周期的事情真是不谋而合~

失败的原因

通常失败的原因是因为白蚁的肆虐，而不是龙卷风的侵袭。

如何根据严格的进度来控制大型项目，第一步是制定进度表。进度表上的每一件事情被称为‘里程碑’。

里程碑必须是清晰定义，可度量的事件。90%完成，测试都是在 99%的时候完成，计划完毕是任何人只要愿意，就可以声明的事件。

里程碑是百分之百的事件！

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 981909093@qq.com