巴比伦塔项目为什么失败？
- 先决条件齐全: 目标清晰、人力充足、材料丰富、没有时间限制、技术足够（锥形结构稳定、砖石技术成熟）;
- 失败点: 项目远在遇到技术限制之前就失败了;
- 真正缺失的两样: 交流, 以及交流的结果--组织;
- 后果链: 无法相互交谈 → 无法合作 → 工作停顿 → 争辩、沮丧、群体猜忌 → 部落分裂, 选择孤立而非争吵;
大型项目中交流不畅会造成什么后果？
- 症状: 进度灾难、功能的不合理、系统缺陷纷纷出现, "左手不知道右手在做什么";
- 机制: 各小组慢慢修改自己程序的功能、规模和速度, 明确或隐含地更改了输入输出用法上的约定;
- 例子: 程序覆盖功能的实现者因统计显示很少使用而降低覆盖速度, 而其他同事正在设计的监控程序严重依赖该速度, 于是变成主要规格说明变更;
- 教训: 这类变更必须从系统角度衡量, 并公开、广泛地发布;
团队可以通过哪些途径交流？
- 非正式途径: 清晰定义小组内部相互关系, 充分利用电话, 达到对所书写文档的共同理解;
- 会议: 常规项目会议, 团队逐个进行简要技术陈述, 能澄清成百上千的细小误解;
- 工作手册: 项目开始阶段就准备正式的项目工作手册;
- 20 年后补注: 还应包括电子邮件;
项目工作手册是什么、为什么需要？
- 不是独立文档: 它是对项目必须产出的一系列文档进行组织的一种结构;
- 必须涵盖: 目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录;
- 原因一（可追溯）: 技术说明背后往往有可追溯到最早备忘录的许多文字和章节;
- 原因二（结构规范）: 事先设计好手册结构, 后来写的文字就能放进合适的章节, 而不是杂乱无章;
- 原因三（控制发布）: 控制发布不是为了限制信息, 而是确保信息到达所有需要它的人手中;
- 检索方式: 先给备忘录编号, 用标题列表检索; 更好的是树状索引结构, 用子树维护发布列表;
工作手册如何分发和更新？
- 规模效应: 10 人项目简单编号即可, 100 人需要若干线性索引, 1000 人项目人员散布多地, 对结构化手册的需要最紧迫;
- OS/360 做法: 每人一份拷贝; 采用活页夹以便只换变更页; 用计算机编辑系统维护, 周转时间少于一天;
- 变更标注: 在页面标记改变的文本（如页边竖线）; 分发变更页时附独立的总结性文字, 记录变更重要性和批注;
- 遇到的问题: 手册厚达 1.5 米, 每天分发约 5 厘米变更页, 归档约 150 页, 维护占据大量工作时间;
- 后续方案: 改用微缩胶片, 体积减少 18 倍; 优点是维护简单, 缺点是难强调、标记和批注, 且归档的"笨拙"恰好保证了变更被阅读;
- 作者结论: 微缩胶片适合作为大型项目文字工作手册的补充;
- 现在的方式: 直接访问的文件 + 修订日期记录 + 变更标识条, 从显示终端查阅, 每日变更小结按后进先出方式保存;
什么是"信息隐藏"式的替代方案，作者后来如何评价？
- Parnas 的方案: 编程人员只需了解自己负责的部分, 而不是整个系统的开发细节, 前提是精确完整地定义所有接口;
- 原著评价: 作者认为这是"灾难的处方", 坚持所有程序员应该了解所有材料;
- 20 年后的修正: "Parnas 是正确的, 我是错误的";
- 修正理由: 信息隐藏（今天常内建于面向对象）是提高软件设计水平的途径; 它面对变更时更健壮, 更适合"为变更设计"的理念;
- 边界: 任何技术都可能演变成灾难--Mills 的开放技术让程序员理解接口另一侧的详细语义, 但接口隐藏会导致系统 bug; Parnas 的技术面对变更更健壮;