去北京前，跟阿阮家的David 聊起RUP，David是IBM SCM的认证专家，常常会被邀请了去客户那里解决他们的配置管理问题，英文特帮，跟Ivar 非常熟悉。他忽然问我，是否有EUP的资料，我拍脑门说有，忙找给他，却发现，此EUP非彼EUP。

我的EUP，是2005年，scott ambler等人写的，主要目的，是作为RUP的补充，提供一个tailoring的框架（里面有若干的新的discipline）；而David说的EUP，是Ivar 感觉UP太复杂，提出的一个精简的版本 （Essential UP）。这是Ivar在本次软件大会上的发言内容，据说，为了在中国推广，他甚至挖到了rational 中国的原总经理。。。

联想到Martin 的敏捷行，我们不难看出，越来越多的国外公司，看好中国的软件开发管理市场。这也从一个侧面，反映出我们的开发过程和方法还存在这样或者那样的问题。

partech说RUP不实用，我个人不是非常赞同，看一下RUP的定义就知道了，RUP是一个框架，这就意味着，RUP就是一个半成品（因为框架是一个半成品）。现在，我们可以找到很多RUP的plug-in ，这些Plug-in 包括 agile，xp，FDD。。。 因此，我还是比较倾向将RUP做为我们思考起点。

人们对RUP的垢病，大多聚集在产生太多的工件上，那么，让我们来看一下RUP自己怎么说：

economy of artifact

• 1 只创建有用的artifact
• 2 最好有工具支持
• 3 使用工具创建形成snapshot －－report
• 4 将重点放在可以形成产品部分的工件上。

记得在DDD中，有一章，提出释意接口，梁问我，难点把类或者方法名字写得长点自然点，就可以做好交流工作吗？我想，这个问题，首先要从环境上来思考：在英语国度中，把类和方法写成自然语言的方式，当然可以促进交流了。在国内的环境中，这种交流效果是要打折扣的。如果，从代码上进行交流，效果打了折扣，那么，我们应该用什么来保证或者增强交流的效果呢？什么才是有用的工件呢？

我想这个问题，只能根据具体情况来回答了。因此，对RUP进行裁减，势在必行。

此EUP非彼EUP，但是殊途同归。经过tailoring 后的UP，会根植在中国广大开发团队中。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=777946