本节书摘来自华章计算机《需求设计：构建用户想要和需要的产品》一书中的第3章，第3.5节,作者： [英] 克里斯·布里顿（Chris Britton） 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.5 BDUF为什么如此笨重
笔者觉得很多人翻开这本书之后，会认为我只不过是提出了一种新的BDUF方法而已。简单地说，笔者确实同意设计先行（DUF，design up front），我只是反对前面那个大（B，Big）字。可问题在于，设计先行是不是很容易叫人做出庞大的设计来？很遗憾，确实如此。这完全是个心理学问题，尤其与会议心理学有关。一群专家在开会的时候，其中的每一位专家都觉得自己应该对会议有所贡献，但他们同时又不想反驳在场的其他人。于是，冲突最小的办法，就是把每位专家的意见都包含在最终的产品里面。此外，专家之间还会彼此交换想法，这本身是件好事，但通常会也会令大家发现一些从前没有考虑到的特性。
顺便说一句，这种以委员会讨论的方式令问题陷入复杂境地的状况，不仅仅发生在业务应用程序之中，其他领域也是如此，例如，当时的希腊就是这样加入欧元区的。制定行业标准的那种委员会，也面临着同样的问题。笔者有一份1992年的SQL标准，整整600页的艰涩文句之中，没有穿插任何范例，而且也没有把面向对象扩展和空间数据等后起的技术包括进来。与之相反，那些对业界造成巨大影响的技术，如TCP/IP、Web以及C语言等，并不是由委员会制定出来的，而是在一个具有特定倾向的气氛之中讨论出来的，参与讨论的人都刻意要把这项技术做得简洁一些。
敏捷开发方式不太可能落入过分复杂的陷阱之中。首先，设计者只会与少数几个人对话，而不会像委员会式的讨论那样，容易产生一些复杂的结果，其次，给项目提出见解的人，对实现相关功能所需的成本，其实是有一定了解的，因为他们是亲眼看着这些应用程序逐步制作起来的。
面对设计方案容易膨胀的问题，我们可以采取下列措施：
- 削减需求列表，尽量减少其中的需求数量。
- 把应用程序的各种特性分成几个不同的阶段来开发。
- 寻求已有的实现（SOA方法），并试着依靠这些实现来制作应用程序。
- 尝试设计一套更为简单的解决方案，以满足绝大部分需求，同时，该方案应该易于扩展。
有一项技巧既可以缩减需求列表，又能把应用程序的开发分成多个阶段来推行，这项技巧就是定义MVP（minimum viable product，刚好够用的产品）。
无论是要精简需求列表，还是要把应用程序分成多个阶段来推行，我们都必须把依赖关系考虑进来，只有这样，才能缩减项目的需求规范。如果任务A依赖于数据表B，那么我们在不删除数据表B的前提下，就没有办法直接把任务A删掉。因此，我们必须像研究一个庞大的鸟巢那样，把设计图之中的所有任务、数据表以及用户组都观察到，并且要注意它们之间的依赖关系。我们可以从缩减鸟巢的外缘入手，此外，如果我们发现了一些相互关联的元素，但这些元素与其余部分之间只有一条依赖关系，那我们就可以将这些元素视为一个整体，把它从整个设计之中拿掉。我们之所以必须捕获情境设计之中的所有依赖关系，这也算是其中的一个原因。
刚才提到的第四种办法，值得特别说明一下，也就是怎样寻求更为简单的解决方案。下面举一个例子。假设我们正在编写一款银行业应用程序，该程序的复杂之处在于有很多种不同类型的账户需要处理，那么，我们就可以考虑针对账户类型专门创建一张表格：
上面这套方案，相当于是把账户的所有特征都表示成了参数。于是，我们无需额外编写代码，即可轻松地创建一种新型的账户。在账户类型只有三种的时候，该方案的优势还不太明显，但是当账户类型达到200种时，它的优势就非常突出了（因为基于历史原因，系统之中可能会出现很多遗留的账户类型）。我们再来举一个例子。假设现在有很多种报表需要实现，那么你可以只把最常用的那几种报表类型用程序编写出来，并且提供一个选项，以下载其中已经选定的某一部分数据，这样，用户就可以在电子表格里面进行详细的搜索了。简单的方案通常比原来那种较为复杂的方案更好，因此，我们要发挥创意、力求简洁。
在试着缩减成本的时候，绝对不能降低产品的质量。对于小型项目来说，即便降低品质，也没办法有效地节省成本，因为你最终还是得花时间来修复那些由于质量低下而产生的问题。要是把业务成本也考虑进来，那就更不应该去降低产品的质量了，因为那样做会令应用程序变得不够可靠，从而引发更大的成本。对于大型项目来说，降低品质会产生灾难性的后果，因为后续的很多工作，都必须在早前的代码能够正常运作这一前提下才可以展开，如果以前实现的那些代码写得很糟糕，或是充满了bug，那么后续的工作就会受到严重影响。
