目录

1. 概观
2. 构想
   1. 最初的敏捷需求建模
   2. 最初的敏捷架构建模
3. 迭代建模
4. 模型风暴
5. 通过TDD执行的规范
6. 评测
7. AMDD有何不同？
8. 为什么这样做？
9. AMDD的方法

1.概述

顾名思义，AMDD是模型驱动开发（MDD）的敏捷版本。 MDD是一种软件开发方法，在编写源代码之前会创建大量模型。 MDD的一个主要示例是对象管理组（OMG）的模型驱动架构（MDA）标准。使用MDD经常采用连续的开发方法，MDD在传统主义者中很受欢迎，尽管RUP / EUP显示可以采用MDD的迭代方法。与AMDD的不同之处在于，不是在编写源代码之前创建大量模型，而是创建敏捷模型，这些模型只是勉强足以推动整体开发工作。 AMDD是一种关键的策略，用于扩展敏捷软件开发，而不是我们在敏捷采用的第一阶段看到的小型，共址的团队方法。

图1描绘了AMDD用于发布系统的高级生命周期。首先，让我们从如何阅读图表开始。每个框表示一个开发活动。设想包括两个主要的子活动，初始要求设想和初始架构设想。这些是在Inception期间完成的，迭代是循环或sprint的另一个术语。 “迭代0或初始化”是开始进行开发迭代之前第一次迭代的常用术语，它是迭代一次（对于该版本）。其他活动 - 迭代建模，模型风暴，评论和实现 - 可能在任何迭代期间发生，包括Inception。每个方框中指示的时间表示平均会话的长度：也许您将建模几分钟然后代码几个小时。我将在下面更详细地讨论时序问题。

图1. AMDD生命周期：在项目的整个生命周期中建模活动。

图2描述了AMDD活动如何适应敏捷软件开发生命周期的各种迭代。 这只是表明敏捷项目从一些初始建模开始的另一种方式，并且建模仍然发生在每个构造迭代中。

图2.通过敏捷开发生命周期的AMDD。

2.构想

预想工作通常在项目的第一周执行，其目标是确定系统的范围以及解决它的可能架构。为此，您将执行高级需求建模和高级体系结构建模。我们的目标不是编写详细的规范，在实践中证明风险非常大，而是探索需求并为您的项目制定总体战略。对于短期项目（可能持续数周），您可以在最初的几个小时内完成这项工作，对于长期项目（可能是12个月或更长时间），您可能决定投入两周时间。我强烈建议不要投入更多的时间，因为你冒着过度建模和建模包含太多问题的东西的危险（在我看来，两周没有实施提供的具体反馈是很长时间的风险） 。

通过初始的高级建模，您可以获得指导项目所需的知识，但选择等待对其采取行动。

2.1初始需求建模

对于系统的第一个版本，您需要花费几天时间来确定一些高级需求以及发布的范围（您认为系统应该做什么）。目标是获得一个良好的直觉，感受项目的全部内容。对于您的初始需求模型，我的经验是您需要某种形式的使用模型来探索用户如何使用您的系统，初始域模型识别基本业务实体类型以及当时之间的关系，以及探索的初始用户界面模型用户界面和可用性问题。

我不能这么说：你的目标是建立一个共同的理解，它不是写详细的文档。一个关键的成功因素是使用包容性建模技术，使利益相关者积极参与。

2.2初始架构建模

初始架构建模工作的目标是尝试识别具有良好工作机会的架构。这使您能够为项目设置（希望）可行的技术方向，并提供足够的信息来围绕您的架构组织您的团队（对于大型或分布式团队而言，这一点尤为重要）。

在体系结构方面，我经常会创建自由形式的图表，探索技术基础架构，初始域模型以探索主要业务实体及其关系，并可选择更改案例以探索系统可能需要的潜在架构级需求支持一天。在以后的迭代中，您的初始需求和初始架构师模型都需要随着您了解更多而发展，但目前的目标是获得一些不够好的东西，以便您的团队可以开始工作。在随后的版本中，您可以决定将Inception缩短为几天，几个小时，甚至根据您的情况完全删除它。秘诀是保持简单。您不需要为很多细节建模，只需要足够的模型。如果您正在编写用例，这可能意味着点状注释足够好。如果您正在建模白板草图或CRC卡集合可能已经足够好了。对于您的体系结构，白板草图概述了系统如何端到端构建，这已经足够了。

许多传统开发人员都会采用灵活的初始建模方法，因为多年来他们被告知需要在项目早期定义综合模型。敏捷软件开发不是连续的，它是迭代的和渐进的（进化的）。通过演化方法，在模型存储会话的开发迭代期间，及时（JIT）完成详细建模。

3.迭代建模：思考你将要做什么这个迭代

在每次构建迭代开始时，团队必须计划他们将执行该迭代的工作。 Mike Cohn计划扑克中经常被忽视的一面是该技术所暗示的必要建模活动。敏捷团队按优先级顺序实现需求，请参见图3，将迭代的工作量从堆栈顶部移除。要成功完成此任务，您必须能够准确估计每个需求所需的工作，然后根据您之前的迭代速度（衡量您完成的工作量），从堆栈中选择那么多工作。例如，如果最后一次迭代你完成了15分的工作，那么假设所有事情都是平等的，那么你将能够在这次迭代中完成那么多工作。此活动通常被称为“计划游戏”或简称迭代计划。敏捷建模

图3.敏捷需求变更管理流程。

要准确地估计每个需求，您必须了解实现它所需的工作，这就是建模的用武之地。您将讨论如何实现每个需求，在适当的位置建模以探索或交流想法。这种建模实际上是对迭代实现的需求的分析和设计。

通过初始迭代建模，您可以探索构建所需的内容，以便有效地估计和规划迭代的工作。

4.模型风暴：及时（JIT）建模

我的经验是，绝大多数建模会话都涉及一些人，通常只有两三个人，他们在纸上或白板上草绘时讨论问题。这些“模型风暴会议”通常是即兴事件，一个项目团队成员会要求另一个人与他们一起建模，通常持续5到10分钟（风暴模型超过30分钟很少见）。人们聚在一起，聚集在一个共享的建模工具（例如白板）周围，探索问题直到他们对他们理解它们感到满意，然后他们继续（经常编码）。模型风暴即时（JIT）建模：您确定了需要解决的问题，您可以快速抓住一些可以帮助您的团队成员，小组探讨问题，然后每个人都像以前一样继续。极端程序员（XPers）会称模拟风暴会议直立式设计会议或客户问答会议。

5.通过测试驱动开发（TDD）的可执行规范

在开发过程中，将风暴模型设置为几分钟，然后按照常见的敏捷实践（例如测试优先设计（TFD）和重构）进行编码几个小时甚至几天，以实现您刚刚建模的内容是很常见的。 。为了便于讨论，测试驱动设计（TDD）是TFD和重构的结合。这是你的团队将花费大部分时间的地方，遗憾的是，图1不能很好地沟通。敏捷团队以可执行规范（通常是客户测试或开发测试）的形式完成大部分详细建模。为什么这样做？因为您的模型攻击工作使您能够思考更大的跨实体问题，而使用TDD，您可以通过非常集中的问题来思考，这些问题通常与单个实体一致。通过重构，您可以通过小步骤改进设计，以确保您的工作保持高质量。

TDD促进您的应用程序代码的验证测试和该代码的详细规范。客户测试（也称为敏捷验收测试）可以被视为详细需求和开发人员测试的一种形式，作为详细设计。像这样做“双重职责”的测试是单一来源信息的完美例子，这种做法使开发人员能够轻松地减少整体文档。但是，详细的规范只是整体情况的一部分 - 高级规范对于您的成功也是至关重要的。这就是我们需要超越TDD考虑AMDD的原因。

您甚至可能希望使用诸如Rational Software Architect（RSA）之类的复杂建模工具进行“可视化编程”。这种方法需要比大多数开发人员通常更多的建模技能组，尽管当您拥有由具有这些技能的人组成的团队时，您会发现使用正确的建模工具可以提高工作效率。

6.评论

您可以选择保留模型评论甚至代码检查，但正如我在模型评论中写的：最佳实践或过程气味？这些质量保证（QA）技术似乎在敏捷软件开发中似乎已经过时，至少在小型软件开发中是这样。在较大的团队或非常复杂的情况下，评论可以增加价值，因为当他们做得好时，他们会为您的IT治理工作提供出色的反馈。

7. AMDD有何不同？

从设计的角度来看，图1的AMDD方法与传统开发方法非常不同，在传统开发方法中，您首先创建设计模型然后从中编写代码。使用AMDD，您可以进行一些建模，然后进行大量编码，并在需要时进行迭代。您的设计工作现在分散在您的建模和编码活动之间，大多数设计都是作为实施工作的一部分完成的 - 在许多方面，对于许多传统项目来说也是如此，开发人员通常会做的事情与在设计模型中，设计师经常责怪开发人员，而不是质疑他们过于连续的流程。

AMDD与诸如特征驱动开发（FDD）或EUP和敏捷统一过程（AUP）的用例驱动开发（UCDD）样式之类的技术不同，因为它没有指定要创建的模型的类型。所有AMDD建议你应用正确的工件，但它并不坚持该工件是什么。例如，FDD坚持认为特征是您的主要要求，而UCDD坚持认为用例是。 AMDD适用于FDD或UCDD方法，因为消息类似 - 所有三种方法都说在编码之前建模是个好主意。

图1的一个有趣的含义是让那些只是在您的开发团队中建模专家的人没有任何意义。他们要做什么，模拟几分钟然后坐一小时或几天直到他们再次需要？真正需要的是我称之为概括专家，在整个生命周期中具有一个或多个专业知识以及一般技能的人，他们既可以编码，也可以在他们需要建模时使用。

8.为什么这样做？

AMDD的工作原因有以下几点：

1. 您仍然可以满足您的“项目计划需求”。通过尽早确定高级需求，并通过尽早识别潜在架构，您可以获得足够的信息来生成初始成本估算和计划。
2. 您管理技术风险。您最初的架构建模工作使您能够在项目早期识别技术风险的主要区域，而不会承担过度建模系统的风险。这是建筑建模的实用“中间道路”方法。
3. 你最大限度地减少浪费。 JIT的建模方法使您可以专注于您实际要构建的系统的各个方面。使用串行方法，您通常可以模拟系统中没有人真正想要的方面。
4. 你问更好的问题。等待风暴需求的时间越长，您对域名的了解就越多，因此您就可以提出更加智能的问题。
5. 利益相关者提供更好的答案。同样，您的利益相关者将更好地了解您正在构建的系统，因为您将定期交付工作软件，从而为他们提供具体的反馈。

9. AMDD的方法

在项目中应用AMDD有三种基本方法：

1. 手册。使用简单的工具（如白板和纸张）和包容性模型进行建模。这可能是所有业务应用程序建模工作的70-80％。
2. 设计工具。包容性模型用于探索利益相关者的需求，并分析这些需求。然后，开发人员使用复杂的建模工具进行详细设计，（重新）从模型中生成源代码。这可能是所有业务应用程序建模工作的20-30％。
3. 敏捷MDA。非常复杂的基于MDA的建模工具，用于创建生成工作软件的大量模型。最好，这种方法将用于5-10％的业务应用程序建模工作。

原文：http://www.agilemodeling.com/essays/amdd.htm

本文：https://pub.intelligentx.net/agile-model-driven-development-amdd-key-scaling-agile-software-development

讨论：请加入知识星球或者小红圈【首席架构师圈】