什么是试验性工厂的类比？
- 化学工程的经验: 实验室可以进行的反应过程, 并不能在工厂中一步实现;
- 中间步骤: 需要"实验性工厂"（pilot plant）为提高产量和在缺乏保护的环境下运作提供宝贵经验;
- 规模例子: 海水淡化的实验室过程先做成 10,000 加仑/天的试验场所, 再用于 2,000,000 加仑/天的净化系统;
- 软件对照: 项目通常一开始设计算法, 然后直接把第一次开发的产品发布给顾客, 跳过了这个中间步骤;
第一个系统为什么通常不合用？
- 常见结果: 第一个开发的系统可能太慢、太大、难以使用, 或三者兼有;
- 唯一出路: 除了重新开始以外没有别的办法, 即开发一个更灵巧或更好的系统;
- 实现方式: 系统的丢弃和重新设计可以一步完成, 也可以一块块地实现;
- 必然性: 所有大型系统的经验都显示这是必须完成的步骤;
- 不可回避: 新的系统概念或新技术会不断出现, 即使最优秀的项目经理也不能在最初就无所不知地解决这些问题;
管理者真正要决定的问题是什么？
- 伪问题: "是否构建一个试验性系统, 然后抛弃它?"--答案是必须这样做;
- 真问题: "是否预先计划抛弃原型的开发, 或者是否将该原型发布给用户?"
- 发布原型的代价: 对用户使用极度痛苦; 对重新开发的人员分散精力; 对产品影响声誉, 即使最好的再设计也难以挽回名声;
- 原著结论: 为舍弃而计划, 无论如何你一定要这样做;
为什么必须承认变化是常态？
- 变化不是异常: 变化与生俱来, 不是不合时宜和令人生厌的异常情况;
- Cosgrove 的观察: 开发人员交付的是用户满意程度, 而不仅仅是实际的产品;
- 变化来源: 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化;
- 与硬件的对比: 物体的客观存在容纳和阶段化了用户对变更的要求;
- 软件的特殊性: 软件易于掌握的特性和不可见性, 导致构建人员面临永恒的需求变更;
- 边界: 不建议把所有需求变更都整合进设计; 但目标上和设计策略、技术上的变化无可避免, 事先准备总比假设它们不会出现好得多;
作者 20 年后如何修正这一章？
- 最大错误: 第 11 章隐含地假设了传统的顺序或瀑布开发模型;
- 影响范围: 不只是第 11 章, 从第 2 章的进度计划规则开始贯穿了整本书;
- 更准确的建议: 应该一块块地丢弃和重新设计系统, 而不是一次性地完成替换;
- 理由: 顺序模型把系统测试乃至用户测试放在构件过程的末尾, 只有投入全部开发投资之后才能发现无法接受的性能问题、笨拙功能或对用户企图的误解;
- 正确定位: 第 11 章不是对错误的诊断, 而是补救措施;
- 替换方案: 采用增量开发模型, 见本组 030;