敏捷误解:无需设计的演示驱动开发 - Darko

21-06-11 banq

诸如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 建模并行进行原型设计,那么您可以演示各种原型(同时向利益相关者强调“这只是一个原型。”)

 

 

3
猜你喜欢