敏捷十年的个人反思​

本文是《敏捷宣言》10 周年系列纪念文章之一，该系列文章将陆续在 InfoQ 上发表。

被邀请参加那次产生了敏捷宣言的会议我感到很惊讶，因为我所做的工作一直都是关于建模方面的。与 Paul Ward 一起著作的三卷本《结构化开发实时系统》，与 Sally Shlaer 合作的两本面向对象分析的图书都专注于分析和设计，而很少把深受敏捷实践者喜爱的编码和测试作为重点。

此外，我刚拜读过 Kent Beck 的极限编程。不重视前期思考、憎恶模型和反对文档，这吓了我一跳。然而，这显然是轻量的、极限的或是敏捷的达到目的的方法。因此我决定参加会议。事实上，在冬日的洛矶山脉无事可做。

我自我介绍时说，我是个想阻挠他们邪恶计划的间谍。而会议中我发现许多关于 过程的观点听起来不错（比如，与客户交流，时间窗），对模型的反对确实不合理。是的，对“前期大规模设计”的过分强调是存在的，但模型确实也还有些价值。 是的，撰写文档（和模型）已被视作最终目标，但显然正确的回应是不要让无意义的文档妨碍来自建模的生产效率增长。

那么为什么模型如此糟糕？因为它们并不执行，我被如此告之。然而我十多年来的工作都专注于构建可执行模型。这次会议前几天我与几乎所有的宣言签署者有过一段对话，有时对话不只一次。对话如下图所示：

这一意见相左的出现，是因为我们在“模型”这个词的含义上各持己见。一些签署人把模型视为草图（如果他们真的思考过模型的话），画在餐巾纸上用于沟通的草图，用完就扔。最让人愤怒的是把模型视作蓝图，画完后扔给隔壁言听计从的开发人员。这些观点我都不认可。我认为模型能运行。

虽然我们在 2001 年就在执行模型，用我们自己的动作语言运行。我在会议中不断的听到，没法用统一建模语言（UML）写个显示“Hello World！”程序。然而事实上在 UML 中显示“Hello World！”是可以做到的，当然这并不容易。实际上这是个编写代码的广告。如果建模想要被广泛地视为是可执行的，就需要解决这一问题。

在 1997 年，当 UML 作为标准被接受时，在模型中只能实现七种动作，其中之一是“无解释字符串。”（签署者认为模型不能执行当然是可以谅解的！）我曾提议为 UML 提供一个标准动作语言。一些人立即建议标准化 Java，或 Smalltalk，或…

但一门现有的编程语言是不能胜任的，因为它的抽象层次太低。所以它会（在某种程度上）把应用程序概念和实现混杂在一起。例如，当我们构建一个特定的数据结构（一个客户的列表，也就是一堆指向账户列表的指针）时，我们已经做出关于实现的决定。在 UML 中，我们会把这表示为一个关联，但不会指定它的实现。

此外，我们在代码中操作这一数据时，不得不要考虑到我们所选用的实现方式。例如，要统计某一顾客的所有账户余额，我们需要遍历链表。更简单的方式是说（以某种方式）“统计这名客户的所有账户余额”。

我们并不是非要能够在 UML 中执行模型——我们能通过加入代码就做到这点。我们想要的是达到更高的生产率，而这来自远离实现的更高抽象层次。我们也希望能够在不改变问题的描述的情况下，改变对实现的想法。如果我们把客户和账户放入数据库实现中，UML 模型也应有同样的应用含义。

在接下来的十二年间，我们（对 UML 进行标准化的对象管理组织的成员，尤其是来自模型驱动解决方案的 Ed Seidewitz）创作出一系列的标准，定义了允许在 UML 中进行的动作的种类；为了执行定义了一个 UML 的子集；明确地为这一子集定义了语义；并（终于！）为 UML 定义了一个标准动作语言。

在这一语言中，上面的例子会写成这样：

 
myCustomer.account.balance -> reduce '+'

其中“reduce”是一个操作，执行一个二元运算，从 myCustomer 遍历至他们所有的账户生成的一组余额，然后不断重复‘+’直至剩下一个值为止。当然这可以转化为实现，或用链表，或用数据库，或用其他。在任何规格说明书中都没有列表，仅对需要做什么有一个非常简洁的声明。（顺便说一下，该语言有一个设计需求：它应易于为 Java 程序员使用，其中许多语法与 Java 相似。在这儿给出的例子不是想让人迷惑，而是为了阐明摆脱实现的力量。）

早在 2001 年，承蒙其他签署人的好意，撰写宣言是用了“软件”（包含了可执行模型）一词，而不是“代码”（更具体。）说良心话，就这点而言我觉得我可以成为一名宣言的签署者，同时继续促进可执行建模。十年过去了，我们有了一个供敏捷建模用的标准动作语言。

我们很少在同一个句子里看到“敏捷”和“建模”这两个词，但它们一点也不冲突。恰恰相反，建模者能从实施敏捷的人身上学到许多（例如，尽早为模型构建测试），遵循敏捷过程的人还能受益于提高的生产率和轻松的客户沟通，这种轻松的沟通则来自于分享与客户结对建模构建出的可执行图表。无疑，所有人都能获益。

更多详细信息，包括重要参考文献，请查看这一链接。

关于作者

Stephen J Mellor 是一名独立教师及顾问，专注于实时和嵌入式系统的架构方法。他的著作有，结构化开发实时系统（早在 1985 年），对象生命周期，可执行 UML 和 MDA 精粹。他还是（也许有点让人吃惊）敏捷宣言的签署人。直到最近，他成为 Mentor Graphics 公司嵌入式软件部门的首席科学家，在 Project Technology 有限公司被收购前，他还是这一公司的创始人和轮值主席。他参与了对象管理组织（OMG）的许多 UML/ 建模相关的活动，他是 OMG 架构委员会的成员，这一委员会为所有 OMG 标准做最后的技术把关。

Mellor 先生曾担任 IEEE Software 顾问委员会主席十年之久，并两次担任这本杂志的客座编辑，最近一次是为了一个关于模型驱动开发的问题。他也是位于澳大利亚堪培拉的澳洲国立大学副教授。

查看英文原文： A Personal Reflection on Agile Ten Years On

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。