什么都可以驱动开发

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第四节审视MDA／MDD
    MDA(ModelDrivenArchitecture)也是一个方法论层面上的名词。它讨论的是“创建出机器可读和高度抽象的模型”的方法。受MDA影响的开发活动被称为MDD(ModelDrivenDevelopment)。
与MDD在同一个层面上的概念是：
》    TDD (TeStDrivenDevelopment)；
》    FDD (FeatureDrivenDevelopment)；
》    BDD (BusinessDrivenDevelopment)；
》    R-TDD(RapidTemplate-DrivenDevelopment)；
》 CDD (ContractDrivenDevelopment)；
》 RDD (RequirementsDrivenDevelopment)；
》    …
我不厌其烦地罗列这些名词，只想告诉读者一个事实：什么都可以‘‘驱动开发”。
不同的方案提供商基于自己的产品构架和当前的理论倾向，随时都在准备改变他们“驱动开发”的方式。在这种形势下的 “XDD"’或“XDA"’，已经成为他们促销产品的保留用词。
回到协同软件工程的过程环节中来吧，你会看到， “以什么驱动开发”只是一个“以哪个环节为中心(或导引)”的问题。所以你会看到TDD中的X模型(也可参考V模型)是这样的：
    如果你仍旧不能明白为什么会有这么多被神秘力量所“驱动着的开发”，那么你就干脆去厨房找个平底锅烧点热油，然后敲下一个鸡蛋，很快，你就会体悟到“以蛋黄驱动开发”的真谛了。抛开实现的技术细节不论，在工程中， “以什么驱动开发”其实是一个过程问题。而你应该明白，过程的选择(或制定)取决于你的工程需要，以及它在相关应用领域的适用性、过程工具的充备性和这个过程理论的完善程度，而不是大公司们的鼓吹。
    过程模型决定了工程的实施步骤和组织方式。但是Object ManagementGroup(OMG)尽管对MDA提出了一套完备的技术和方法体系，工程实施者却无法在这个体系中找到一个可以适用的软件过程模型——MDA不讨论过程。
    也就是说，MDA架构作为一个新的软件开发方法的架构，即使在技术研究、底层协议和软件实现方面经过了持续地完善而渐至成熟，然而如果没有同样成熟的OA软件过程理论支持，那么它在工程中的实用价值也就有限。
    仔细审视一下这个MDA，如果你现在就决定将下一个工程项目建立在这个构架的基础上，或者用MDD的方式来开发BIOS，那么你离精神病就不远了。

第五节审视AP和XP
XP是一种AP。也就是说， “极限(Extreme)”是达到“敏捷(Agile)’，的一种途径，或者说“极限”的词义就是“极端敏捷”。我当然知道我这样解释XP与AP会被人骂成白痴。但我的确试图用较直接的眼光来看问题，并理解它——如果一个问题被理解得过于直接而“失去了技术的乐趣”，那可能在这个“问题”本身之上，就覆盖了大量的“技术尘土”，这才是使你看不到它的本相的根源。
如今业界一说“敏捷”，便会立即讨论它具体的方法论、过程理论和工程工具，或者干脆把它的典型范例“极限编程(XP)”拿来讨论。所以看起来，在敏捷的旗帜下有着异常丰富的实现：众多的工程组织和电子商务团队都在说“我很敏捷”。
然而在我看来，这些都不过是“技术尘土”。因为真正的问题是： “敏捷’，是什么呢?
开发人员大多有一种极端主义思想：好的要较好，精的要较精，全的要较全。无数人为了类似于“写出较精巧的程序”这样的目标而奋斗。而“敏捷”，旨起来也就是这样的一个“目标”。
如果把“敏捷”作为目标，那么目标的具体衡量就是“敏捷性”的量值。而“敏捷性”的定义却没有编程中的数据类型那样精确。例如你可以问“这个数据类型占几个字节”，却不能问“你有多敏捷”。
衡量“敏捷性”的是一份宣言： “敏捷软件开发宣言(ManifestofoI．AgilesoftwareDevelopment)”。尽管这份宣言没有提供量器，但却设定了衡量的对象。例如宣言说在开发小组中较有效率也较有效果的信息传达方式是“面对面向交谈”，所以你的团队是“面对面的交谈”，还是“书写一份文档”就成为“是否敏捷”的一个标志。但“交谈达到的效果”却没有衡量的依据。
事实上， “写文档”起码可以用页数和小组中签出文档的频度来衡量文档的价值(尽管不准确)，但“交谈”的效果却无法衡量。 “敏捷宣言”概而言之地说“这样就有了敏捷性”，其实是取巧的办法。
所以“敏捷软件开发宣言”根本上并不能、也不打算让你去‘‘衡量敏捷性”。因为连“衡量”这件事，在“敏捷者”们看来也是没有什么价值的——你较好直接与小组成员花点时间去解说并协助他们实现技术原型，而不是去“做一份漂亮的文档”。在“敏捷者”们来说，他们就认为前者是“敏捷的”、 “有效的”，根本就不需要像下面这样去衡量：
    》    文档页数是否满足公司规范；
    》    文档规格是否符合RUP的标准；
    》    文档是否被团队的所有成员签出。
    ——试图去衡量它，就已经使“事情变得不那么敏捷”了。
    在“敏捷者”们看来， “(在实施中)发现问题比(在文档中)预测问题更实际”，因此“敏捷”起码看起来有点“经验主义”。也正如ScottW·Ambler在讨论“敏捷数据”时所提出的他对“成为敏捷软件开发人员”三个关键见解：
    》你不必非要做一个超人；
    》敏捷性其实只是一个思维集；
    》    成为一名博学型的专家。
    第一条就是强调沟通：找别人解决问题比自己解决问题来得迅速。第二条则说明敏捷的根源是学会思维而不是立即着手解决问题。第三条说明“知道更多”则更容易找到解决问题的方法，因而比“精通”重要。可见，Scott的三条见解都是围绕“如何解决问题”而提出的“敏捷方法”。
    这些敏捷方法的核心之一，就是“寻找更有经验的成员来解决问题”或“使自己变得更有经验”。
    类似的“解决问题的敏捷方法”还有《超限战》这本书。其中的一个例子是：打赢战争的方法，可以是兵力的对抗，也可以是非军事的行为(如恐怖活动、贩毒、破坏环境、传播电脑病毒，等等)。这根本上来说是围绕“取得胜利”这个核心问题提出的“敏捷方法”。
    巧合的是，这两者所面临的争议也是类同的。因为“敏捷”更多的时候是一种“有悖传统”的理念。例如“敏捷宣言”陈述其价值观时，第一条就说“人和交互重于过程和工具”。这在本质上就是对传统工程方法学的挑战。因为“牛屎图”表达的含义就是： ‘‘工程二(面向工程目标的)工具+方法+过程”。
    ——当然，敏捷宣言还是为传统工程理论家们留了点面子。敏捷宣言在否定传统之余，也不忘记说过程和工具等“也具有价值”。
    无论我打算用怎样挑衅的词汇来对立“敏捷”与“传统”，我们也要看到二者的本质。 “敏捷”所表达的其实是对工程目标的尊重，是对人的创造性和主动性的尊重。而另一方面， “传统工程”所代表的则是规范和规模化。
    如同我在讨论“工具本质”时所提到的一样，无论多敏捷，如果具体的方法不能应用于“团队化的工程”，那敏捷本身就失去了工程价值。因此，为了应对“规模化”这个目标， “敏捷宣言”基于的前提是：工程团队认可敏捷的价值，遵循敏捷提出的价值观和基本原则。
    “敏捷宣言”试图通过成员对共同契约的遵守来解决‘‘规模化’’的问题；而传统工程则通过制度、规范和确定的方法与工具来达到这个目的。从这一点上来看，这是“人治”与 “法治”的区别，也是‘‘敏捷方法是难以应用于大型工程的‘轻量型’开发方法”这样的观点的根源。从这个角度来讲， ‘‘敏捷’’也是与团队文化相关的一种方法：如果你的团队原本就有它维护自己‘‘规模