自从上回老杜把TDD,DDD在中国的处境看成是‘水土不服’之后，雨辰就一直想找个机会再跟老杜‘理论’一下。后来在整理以前资料的时候找到了Ivar Jackbson(UML三友，用例的发明人)在2008中国之行时做的一次演讲时用的PPT，其中提出了一种称之为‘明智软件开发’的软件开发思路。雨辰当时看这个大约4M的ppt时的第一印象就是Ivar破天荒的提出将UP与敏捷有机结合到一起，并最终用于软件开发的过程中。让这两个阵营中的优秀思想相互补充，各自发挥所长，听起来倒是一种不错的想法。

当然IVAR也对AGILE阵营中对“架构”的偏激思想进行了反击，正如后来孟岩所总结的那样：

明智软件开发——Ivar Jacobson博士上海英雄会演讲的主要思想。

Agile认为，应尽快产生可执行代码，架构可以随后重构出来，而他（Ivar）认为，skinny system就是架构(软件一开始的核心架构)，开发skinny system的过程也就是确定架构的过程。而架构是一个系统中最重要的部分，对质量要求不折不扣的部分，因此必须精心设计，丝毫马虎不得，也别指望事后能够通过重构产生好的架构（这时雨辰所一直信奉的）。另外一方面，也不要执迷于那些通用的庞大的企业级架构。正如skinny system暗示的，好的架构都是小而简单的。Ivar认为，软件各部分对于质量的要求是不一样的，与架构无关的部分，适当降低质量要求以求得开发效率的提升可以的，事后也完全可以通过重构等手段改善之。然而架构却是必须从一开始就认真对待的，Ivar甚至说，“唯一重要的质量就是架构的质量”。

看了上面孟岩BLOG中一段文字，雨辰又联想起2006年9月《程序员》杂志中，IVAR发表过一篇名为《让统一过程也敏捷》的文章。在该文中作者提出了一个叫EssUP ”核心统一”过程的方法，其可以看成是UP,XP,CMMI的‘三合一’，如下图：

而现在看来，该文章所阐述的内容其实就是在为IVAR后来提出的“SMART”开发做‘铺垫’。当然“SMART”本身绝不是对Agile进行‘招安’，而是对RUP&UP的一种有益补充，必定RUP太重了。从这一点看，IVAR要比AGILE阵营的态度要温和，更有‘大家’之气，也更老辣。

EssUP方法认为传统的软件过程，比如统一过程（UP），是通过对她所定义的不同角色所进行的活动和生产的制件进行描述的。这些活动和制件可能服务于不同目的，例如基于用例的需求，测试驱动的设计、架构的构建、基于组件的开发（这些都是过程）。换句话说，他们在处理不同的实践。这些实践不是外在的、也不是可见的，甚至没有一个名字。这样的过程中所包含的许多实践可以被形象地比喻为“一锅汤”。即过程是您选择的一组实践的组合。”

上面的原文意思（按雨辰自己的理解）就是将要开发的软件根据功能分割成N个‘过程’中，每个过程比如用例需求分析或基础架构等都是由一些实践组合而成，而那些实践包括敏捷实践，架构实践等，但必需是经过验证且简单有效的，并且这些实践可以被组合成为所‘需要’的实践。

除了将过程细化，Ivar同时该方法还引入了卡片机制来使用‘过程’变得敏捷，而卡片与agile中的story card基本无异，当然引入卡片本身也没什么可奇怪的，必定‘卡片’与‘用例’差不多，而IVAR又是用例的发明人，所以理所当然了。

EssUP将每一个实践通过一系列的过程卡片进行呈现，这些卡片包含了定义你自己的过程所需要的各项元素， 包括关键能力， 活动和制件。这些卡片可以用来为您的项目建立一副牌，通过卡片组合来为项目成员规定项目任务，或者定义新的过程元素。 在项目中， 还可以通过卡片实例来表现实际交付物和任务。卡片使得过程本身变得敏捷，易于使用。无论是电子卡片还是打印的版本，都能有效地推动过程采用， 项目计划， 并为实践者提供方便的参考指导。这些卡片使过程“活“起来，比静态的网页和书更方便阅读、理解。

一口气读下来，感觉该方法是将UP做为了开发流程的主干，而敏捷这类的实践变成了流程中的相应环节和一砖一瓦。再说的简单一些，就是当你要设计开发一个非常复杂的系统时，你可以在其中使用UML,，XP，AGILE，RUP，只要场景适合允许，那就可以将其做为一个组件加以使用，最后再将这些过程衔接起来，构成软件开发的整个流程。

当然在IVAR之前，就有一些案例使用了类型IVAR所强调的这种‘大杂烩’的开发方法。比如：TRW公司于1987-1994年间为美国空军开发的导弹预警和地面指挥控制系统CCPDS-R是历史上非常著名的、融合统一过程（该项目所采用的过程方法后来形成了RUP的一个主要来源）和敏捷思想的成功范例。该获奖项目的规模为75人、6年、100多万行Ada代码，采用了类似RUP 4个阶段的迭代递增、架构优先过程。它不仅按进度和预算交付了大型关键任务系统，而且还使用户获得了超出预想的功能，在生产率和质量方面取得了2倍的增长。

在整个项目过程中， CCPDS-R承受了大量需求的变化，甚至包括开发后期的一个合同范围变更。同等程度的需求变化扼杀了大部分采用传统管理方法的项目，而CCPDS-R却由于采用了风险管理、设计阶段架构的不断集成以及基于演示的评审方法，有效控制和稳定了变更成本，取得了超乎寻常的成功。CCPDS-R在注重个人互动、可用的软件、客户协作和响应变化等方面都做得非常出色，可以说完全实现了敏捷价值观和目标。

不过因为IVAR还未公布SMART方法的具体实现细节以及相关流程，所以对于外界看来光凭那个PPT还是有些‘盲人摸象’，但必定其指定了一个方向就是‘分久必合’，当下软件方法论中RUP,AGILE等各自占据一片江山，而存在即合理，所以与其排斥不如包容。针对合适的场合，合适的团队，使用“全适的开发方法“。当然无论是UP还是AGILE，都对开发者提出了较高的要求，就是对OO设计方法和技能的掌握。即：

XP要求开发团队具备熟练的OO编码、测试和重构等技能，RUP也对OO需求分析、架构设计提出了较高要求。没有真正理解OO范式与传统结构化方法的本质区别，缺乏OO技能，那就玩不转了。

而国内的开发者的水平又摆在这，所以最后还是应了老杜之前说的那句话：

所谓‘根据公司团队实际情况采用相应的方法’只是一种奢谈。在国内来看，这类方式论的普及和理解层次远没到国外的水平，对于咨询公司而言相应的培训市场也并没理解中那样有利可图。我更认为TDD,这类敏捷实践在国内‘水土不服’。