开始之前，我先引用一下 Donald Rumsfeld 的诗。
未知的未知数
世界上有已知的未知，也就是说我们知道我们还不知道的那些事情。但是，还有未知的未知，那些我们不知道我们不知道的事情。
—Donald Rumsfeld，美国前国防部长
Rumsfeld 对未知进行区分，有些我们知道存在但是我们找不到，但是他也承认还有一些存在是超出我们的知识和经验的，我们甚至不知道要去寻找：这就是 “未知的未知”。
Rumsfeld 讨论的是战争的不确定性，但也是在说软件。如果您曾编写过一些重要软件，您可能涉及过未知之未知 问题 — 软件设计中最大的一个问题。您认为您对解决方案实现过程中所遇到的问题都有一个很好的理解，但是不可避免还是会出现一些不可预料的问题。同一个开源框架交互不是您想的那么简单，问题可能比原来所预计的更细微，需要更加精细缜密。
不可预期的设计问题会不断出现，因为软件的容错能力很低 — 比物理系统低很多。例如，以您身边的建筑物为例，构建一个大楼是一个多人数月（甚至数年）的项目。现在考虑类似时间段上的一个多人软件项目。这些项目有类似的规模，但是物理建筑往往更加宽容结构缺陷。如果一个开关不能完全掩盖墙上安装电线的洞，整个大楼不会倒塌。但是软件中的一个小问题可能会导致系统崩溃。将其比作原子，位元的容错都是不可原谅的。当然，软件易于修复：我们可以在洞上抹墙粉（修复 bug）立即改造房子。
如果一个机翼脱落了，工程师首先会查看机翼连接的位置：在物理系统上，错误和功能的临近度通常很高。但是在软件中，执行一行可能导致不稳定的代码，通常会使数百行甚至几千行似乎不相关的代码出现问题。
软件预先设计（Design up front）比较困难，因为各个部分之间以无数种、甚至不可预期的方式相互作用。预测这些交互的实现目前不在我们的能力范围之内，紧急设计包含这些不可避免的令人惊讶的复杂性，试着减少变化的破坏。
设计波谱
紧急设计不是一个二元状态。您不能肯定地说您的设计是 100% 敏捷的或是 0 敏捷的；有 图 1 所示的这样一个波谱：
图 1. 图 1. 设计波谱
在 图 1 的最左边，有传统的 Big Design Up Front (BDUF) ，具体反映在很多常见开发技术中。BDUF 以其优秀的稻草人（straw-man）形式体现了象牙塔架构，创建设计工件，不作任何更改直接交给开发人员来进行实现。在 nonparody 格式中，该设计方法努力尝试在编码之前找出所感兴趣的一切。这是一个预测模型，设计软件的预测模型。
图 1 右边显示了您在中学时期所做的各种编码：您可以进行修改使之运行，然后继续改进。这在小范围内可以很好地运行（基本上，只要这个问题小到您用脑子想想就可以解决），但是不能超出太多。
紧急设计通常在两个极端情况下失效，但是和左边比起来更趋向于右边。紧急设计是一个响应式的、被动的软件设计方法。
面对这么多的失败和不被看好的项目，还有这么多组织机构继续使用 BDUF，真的很令人费解！我并不是说您不能成功地使用 BDUF。（事实上，我曾做过很多这类项目。）但是数十年间关于这个开发技术的记录很少。Fred Brooks 的重要著作 Mythical Man Month 探讨了以该模式构建软件存在的问题，于 1975 年发布（见 参考资料）。
团队想使用这种风格进行开发并不奇怪，因为这更符合设计在传统工程中的工作方式。如果您正在设计小部件或 iPods，您必须进行所有的预先设计，因为您不能重构原子。看看原始的 Intel Pentium 处理器。在它发布之后，在浮点数据单元中发现了一个 bug，需要每个操作系统创建者来编写特定代码解决这个问题。一旦操作完成，您就不能对硬件进行更改。软件截然相反：软件项目的多数生命周期是在原始版本发布之后发生，通过增强、bug 修复、以及其他 “维护” 活动。我们处理位元而不是原子，位元的可塑性是无限的。
多少预先设计？
敏捷设计并不是要在项目开始阶段忽略设计。您对问题的本质知道得越少，在此过程的早期您所能做的就越少。我常常会问，“您如何决定在一个项目开始阶段进行多少设计合适？” 不同项目有不同的准则，它们在种类和复杂程度上的变化比多数非技术人员所意识到的要多很多。大致上说，您需要平衡两件事：如果您的早期决策足够精准可以避免日后进行更改，那么要考虑预先设计。如果后期修改成本太大，就要考虑收益问题。因此，您需要对早期阶段以及开发技术（可能会是后期更改代价昂贵）有一个很好的了解。敏捷设计反对这个观点，因为人们倾向于过高地估计他们在早期制定精确决策的能力，因而他们将遭受不断扩大的后果。
这里是一些项目示例，了解一下您应该为哪些项目做更多的预先设计：
• 有严格的稳定性需求，数年之内没有更改计划的项目。
• 高度隔离的环境（比如太空傲游，水底探险），出于安全性考虑的项目。
• 您所编写的项目与之前的软件完全相同、同一组人、没有范围变化。（您将对该项目有一个极度精确的评估。）
• 对环境高度约束的项目，比如，嵌入式系统，确保您考虑到了环境约束条件。（我仍然会尽量使行为功能性尽可能多地出现。）
您不需要进行太多预先设计的项目有：
• 有高度可变性、项目需求不断变化的项目（几个月或几周），像多数商业应用程序。
• 需要响应外部因素（比如，市场条件）的项目。
• 您还不能确定技术或业务细节的项目，注意这实际上包括每个项目，又回到 Rumsfeld 的 “未知之未知” 理论上了。
• 从订阅到部署都可以从中收益的项目，而不是那些人为地区分为 “已完成的” 项目。没有软件项目是彻底完成的，因此您总是需要购买一个订阅，您越早认识到这一点，就表现的越像。
选择正确的时间制定决策比较困难，但很重要。所有项目都是独一无二的，给出具体建议无用。但是，这有一些通用的指导方针：
• 注意当 “最简单的工作” 已经工作一段时间之后，需要解决的问题变得更重要更复杂，例如，假设您正在使用一个数据库作为基础后台、异步活动的一个简单消息传递队列。然而现在，在性能变差的同时将两个新需求添加到各种异步活动中了。现在是重新访问您的 “最简单事情” 决策的最佳时间，因为您的解决方案不能匹配该准则。
• 在查看问题的整体规模时，试着隔离将趋向紧急设计技术的数据包。例如，假设您正在处理一个需要地理编码支持的应用程序，您不可能在此之前就使用一个地理编码库。您应该执行一些 spikes（简单直接的研究与开发项目）来确保您可以理解评估目的。尽量避免在不完全理解的基础上制定架构决策（后期很难改变），重新访问应用程序其余部分和这个隔离部分之间的接口点，看看是否能在更好理解的基础上进行改进。
• 试着保留应用程序之间的交互作用点。Simple Object Access Protocol (SOAP) 这类协议的一个副作用是在刚性结构和强类型（strong types）上的持久性。灵活性的秘密是特异性少，这种认识推进了 Representational State Transfer (REST) 和相关技术的广泛应用。构建一个 API 时，试着接受最通用的合理性，这也将应用于集成。
