Big Design Up Front（简称BDUF） 是一种在开始实施之前预先完成和完善网站、应用程序或软件设计的方法。它需要一个瀑布过程，并且依赖于预测。这是在敏捷出现之前几十年的流行方法。过去，网站和软件的构建成本非常高，因此有必要在成本高昂的工程发生之前解决尽可能多的问题。
把它想象成绘制一艘船的航向图。如果您已经知道路线、天气、洋流和潮汐，您可以在下水之前计划好行程。一旦你离开港口，你就不必浪费时间来确定你的方位了。
BDUF 假设
- 我们可以预先完全了解设计的目标、要求和范围——而这些不太可能发生重大变化。
- 在编写代码之后进行设计修订通常更难且成本更高。通过在设计中尽可能多地整理来获得效率。
- 我们可以而且必须在设计解决方案完全发挥作用之前判断它是好的还是有效的。
- 工程师可以在设计过程中查明开发挑战，因此我们可以在编写代码之前找到替代设计解决方案。
- 如果任其自生自灭，工程师将把事情搞得一团糟。设计需要引领潮流，否则用户体验和美学将受到影响。
BDUF 优势
- 如果您确切地知道自己想要什么，这是到达那里的最有效方式。
- 由于所有设计都是一次完成的，因此有足够的机会进行缩小、经常集成和整体设计。
- 用户体验由设计师设计和完善，设计文档决定了工程师开发的功能。每个角色都发挥自己的优势。
- 易于成本和计划设计，因为它从一开始就是已知的数量。
BDUF 弱点
- 不容易适应范围的变化或目的的转变。如果目标或要求发生变化，您可能必须游回瀑布才能重新开始。
- 设计并不那么容易测试和验证，因为直到线性过程结束时，它的任何部分都无法完全发挥作用。
- 不利用瀑布过程后期可能出现的新知识或更好的解决方案。
敏捷与应急设计
敏捷开发方法是为复杂的、不确定的、非线性的项目设计的。它优先考虑适应性而不是预测性，减少获得证据之前所需的信念飞跃。
敏捷旨在将项目分解成更小的块。然后，跨职能团队使用具有短时间框架的 sprint 来完成整个瀑布流程的加速版本——目标是在每个 sprint 中设计、生产和测试一些东西。然后将他们的学习整合到项目不断发展的范围中，并帮助塑造下一个冲刺和迭代的方向。
如果 BDUF 是一个事先计划好的旅行，那么敏捷就是让你的船离开港口，只是对你要去的地方有一个模糊的想法，然后在水中探索、计划和适应。这是一系列小赌注，而不是一个经过精心计算的赌注。
敏捷软件开发宣言基于十二项原则（通过维基百科）：
- 通过早期和持续交付有价值的软件来满足客户的需求。
- 欢迎不断变化的需求，即使是在后期开发中。
- 经常交付工作软件（几周而不是几个月）
- 业务人员和开发人员之间密切的日常合作
- 项目是围绕有动力的个人建立的，他们应该被信任
- 面对面交谈是最好的沟通方式（同地办公）
- 工作软件是进度的主要衡量标准
- 可持续发展，能够保持恒定的步伐
- 持续关注卓越的技术和良好的设计
- 简单——最大化未完成工作量的艺术——是必不可少的
- 最佳架构、需求和设计来自自组织团队
- 定期，团队反思如何变得更有效率，并做出相应的调整
应急设计
敏捷方法需要一种新的思维方式，这种思维方式被描述为紧急设计。应急设计旨在做与 BDUF 相反的事情——预先进行最少的设计或没有设计，这样我们就可以尽快进行运输、测试和验证。
应急设计假设
- 如果没有大量的测试和学习，我们就无法完全理解问题或其理想的解决方案。必须推导出需求和设计，因此最好尽快开始构建测试。
- 代码中的更改比设计中的更改要便宜。（或者至少同样昂贵）。
- 只有在现实世界中构建并可用时，才能对设计进行判断或验证。
- 如果他们的工作不经常集成和测试，设计师可能会创建技术上不可能或昂贵的解决方案。
- 过多的预先设计（和任何文档）都是浪费精力，因为在设计实施之前需求会发生变化或新的解决方案就会出现。
应急设计优势
- 设计会随着时间的推移而发展，并且可以利用新的学习成果。
- 设计是一个协作的努力，而不是一个单独的、隐居的过程。正如Manuel Dahm 所说：“这需要设计师从孤独的创意天才象牙塔搬进团队思想的共享公寓。”
- 设计和开发并行进行，这促进了巨大的跨团队协作和快速解决问题。火灾一出现就可以扑灭。
- 很少有假设或直觉。设计只有在数据证明成功的情况下才能实施。消除了有关设计有效性的不确定性。
应急设计弱点
- 敏捷可能过于注重输出，并鼓励特征工厂。
- 具有讽刺意味的是，冲刺的背景允许在宏观层面上更频繁地集成，但提供的深入、整体设计思维的机会却更少。过于狭隘的焦点和不够广阔的视野意味着在设计系统层面上整合的机会更少。这可能导致平庸、不一致的设计，缺乏抛光和完整性。
- 设计很难计算成本，因为它是一个由利益相关者反馈和冲刺周期决定的移动目标。直到项目进行到一半（或进一步）时，才可能出现完整的设计范围。
- 当“足够好”的设计出现时，冲刺和重复周期通常会结束。然后它在没有太多机会将设计提升到平庸的情况下发货。当仅由数据决定决策时，设计师就失去了质量控制的优先级。
足够的预先设计
“前面的大设计很愚蠢，但不做前面的设计更愚蠢。”
——戴夫·托马斯
我曾经认为敏捷是好的设计的敌人，但后来我意识到糟糕的敏捷并没有为好的设计留下空间。我拒绝采用敏捷方式或工作，因为我的许多经验都突出了紧急设计的弱点，并且没有用它们的优势来弥补它们。
任何产品开发方法都试图在最便宜的时候回答设计问题。敏捷支持者坚信，在短冲刺期间，以小幅度递增是最便宜的。BDUF 在前期最便宜并被视为整体时起作用。但是当他们没有产生好的设计结果时，他们都不会为设计师工作。
我不相信 BDUF 或敏捷找到正确的平衡点。它介于两者之间。
因此，我首选的设计方法是 Just Enough Design Up Front (JEDUF)。
JEDUF 救援
JEDUF 认识到需要一些总体设计才能实现更详细的工作。我们不能总是以“牛仔发展”为目标。首先，我们需要一些球门柱。我们需要架构和设计来为我们的 sprint 打下基础。
- 早期的设计工作可能很粗糙，但考虑到当时可用的信息，应该总是尽可能好。是的，更多的设计工作将在以后出现，但如果我们能在第一时间把它做好，我们不想重做任何设计。
- 前期设计应被视为项目或产品的最基本方面，因此它会告知在早期冲刺期间构建和测试的优先级。换句话说，识别最高风险，然后首先针对它们进行设计。这为设计系统奠定了基础，尽早进行压力测试，通常由开发的最高价值的部分进行。有人将这种必要的前期设计称为“原始整体”。
超越 JEDUF
我自己的 JEDUF 版本包括在项目的各个阶段进行设计解压缩和集成的机会。我称它为“刚刚足够的前端和中间设计”。
JEDUF&M 平衡了小冲刺（放大的焦点）和从广泛的角度进行整体设计集成的机会。当出现大量功能时，可以暂停 sprint 周期以考虑更深入的设计。
把它想象成另一个前期设计会议，只是它的目标是关于凝聚力而不是探索。一旦设计系统感觉整体和可控——整合和协调以前冲刺和学习的修订——下一轮冲刺开始。设计师需要认识到何时需要“中间”设计中断，而不是让项目陷入细枝末节。
我发现 JEDUF&M 是最终的设计方法。它平衡了适应性、快速迭代和专注于验证，这使敏捷变得如此强大——同时还允许休息、集成和整体设计系统思考，这些思考可能会在冲刺和功能交付中迷失。
如果，即使在这种方法论的理想平衡下，你发现自己对不确定性的数量感到焦虑，请这样想：拥抱不确定性。现在，您可以决定这些约束会变成什么样子，而不是让它们预先确定并由您决定。这是更多的责任，也是更多的灵活性。如果您沉着应对该角色，您将交付一个没有遗憾或妥协的结果，即使该过程在此过程中更具挑战性。