诸如Scrum等管理风格是以较短的开发周期为中心，也就是冲刺，许多组织误解了这一点，并采取“无前期设计”和“从第一天开始编码”的方法。
对他们来说，理论上我们不需要设计软件解决方案。我们开始编码，但增量很小。在每个冲刺结束时，向产品所有者和利益相关者展示工作软件的演示。利益相关者提供反馈，然后我们修改应用程序，依此类推，直到我们可以交付软件应用程序。
我把这种对敏捷原则的误解称为演示驱动开发（Demo Driven Development，也简称DDD）。根据对方法论的这种误解，整个团队都冲向这个短期目标，并鼓励走捷径，以便为冲刺结束做好演示准备。
这似乎是个好主意，它让人们专注于一个共同的目标。有些人可能会说这让他们在冲刺期间更加努力地工作，因为他们有一个可以实现的目标。此外，产品利益相关者有机会提供早期反馈，如果需求被误解，可以尽早纠正。
这种开发方式还有许多其他所谓的好处，并且近年来一直在增长。我认为这种方法在一定程度上适用于某些情况：对于小型项目，对于具有相对简单领域的项目，或者开发人员对领域非常了解的情况。
但是，我建议这种软件开发风格不适合大中型项目或具有复杂领域的项目。
各种研究，例如Standish Chaos Report，表明超过一半的软件开发项目没有成功。
项目越大，失败的可能性就越大。因此，如果您的项目并不小，那么您就有统计数据对您不利。为了增加项目成功的机会，我建议采用领域驱动设计方法，而不是采用这些“从第一天开始编码”和“无前期设计”的软件开发风格，这种方法特别有益于大中型项目，或任何具有复杂领域的项目。
DDD是一种软件开发方法，由Eric Evans在他的著作领域驱动设计：解决软件核心的复杂性中创造，该书最初于 2003 年出版。从那时起，不断增长的 DDD 实践者社区的许多贡献丰富了它。
在我们研究使用 DDD 方法如何使您的项目受益之前，让我们更详细地探讨这个竞争对手的“演示驱动开发”实践（我称之为），或者更确切地说是检查它的不足之处。
法国数学家埃米尔·博雷尔 (Emil Borel)在 1913 年提出了无限猴子定理，该定理指出，一只猴子在打字机上随机敲击无限长的时间会产生威廉·莎士比亚的全集。
没有前期设计
总体而言，敏捷，尤其是 Scrum，以“无前期设计”方法为荣。我们的想法是，每个冲刺我们都将积压工作中的一个史诗或几个故事带入冲刺。我们专注于一次构建产品的一小部分。在冲刺结束时，我们展示我们生产的产品，产品负责人和其他利益相关者给我们反馈，告诉我们要改变什么。通过从sprint到sprint的迭代，每次更改和重建产品，最终我们会得到一个完整的解决方案。嗯，这让我想起了一件事……
是的，正如你猜的那样，这听起来像是：“如果你有无数次冲刺和一群猴子，你最终会得到想要的软件解决方案”
好吧，我们确实使用软件开发人员而不是猴子——所以我们不需要无限量的时间。但是，这种方法确实为大多数项目增加了大量时间。对于复杂的大型项目，这将导致代码在 DDD 社区中被称为“大泥球”或“意大利面条式代码”。持续重构方法可以提供帮助，但实际上有多少产品所有者和利益相关者允许这样做？
尽快开始编码
在 IT 工作了 20 多年之后，“从第一天开始编码”对我来说是软件开发项目中可能犯的最大错误。根据领域驱动设计原则，开发人员对领域的理解被提炼成代码。实际上，这意味着如果软件开发人员误解了领域和需求，他们将开始构建错误的产品。
确实，随着项目的进展，经过多次迭代和冲刺，开发人员最终会了解他们需要什么。不幸的是，到了这个阶段，他们已经创建了大量结构不佳的代码，因此难以更改和维护。这就是开发人员对利益相关者说的重点：“我们真的应该废弃所有现有代码并从头开始重建。” 在这一点上，管理人员开始寻找一些“优秀的开发人员”来雇用，当然，这些并不存在。
问题 不在于开发人员的质量，而在于使用了错误的软件开发方法。
领域驱动设计
幸运的是还有另一种方式。您不需要执行众所周知的“两年分析阶段”，这通常被认为是瀑布方法的陷阱，您也不必在没有任何设计的情况下开始编码。相反，您可以采用领域驱动设计方法。
领域驱动设计 (DDD)是一种软件开发方法：一组用于帮助开发复杂系统的技术、原则和模式。
实践 DDD 的目标是用系统的方法处理复杂的场景，使领域专家（利益相关者、产品用户等）和开发团队（产品所有者、软件架构师、开发人员等）可以有效地协作最小摩擦。通常，他们在域探索会话期间聚集在白板周围，并使用 DDD 提供的多种技术生成各种类型的图表。这些技术超出了本博客的范围，互联网上有许多资源可以为您提供概述。
领域驱动设计和敏捷
DDD可以和Agile结合使用，毕竟是两种不同的东西。敏捷是一种项目管理方法，而 DDD 是一套软件开发技术和方法。
我想在这个博客中提出的主要观点是：不要在每个冲刺结束时专注于演示完全工作的软件。相反，您可以演示作为 Knowledge Crunching 会话产品的各种 DDD 工件。例如，您可以演示域故事图、事件风暴表、域模型中的实体图、限界上下文图……所有这些工件都可以在 Sprint 审查会议上进行演示和审查。
这意味着您仍然可以迭代，但不能通过重新开发代码，而是可以通过改进领域模型来迭代图表。更改一些图表比更改工作软件更容易（也更便宜）。
此外，如果您正在与 DDD 建模并行进行原型设计，那么您可以演示各种原型（同时向利益相关者强调“这只是一个原型。”）