德璋PK Martin：“RUP是楷书，XP是草书”对吗？
在6月6日上海交大举办的“敏捷技术专家论坛上”，软件技术大师Martin Fowler神采奕奕。在1个多小时的精彩演讲和现场编程后，Martin和来自业界的几位敏捷技术专家就诸多敏捷技术的相关话题进行了交流，掌声、笑声、还有观众的频频举手提问，连绵不断，气氛异常火爆。现场共搜集到了观众递交的问题大约3、40条，当然，因为时间的原因，Martin没有在现场一一作答。不过，这些问题将作为Martin的家庭作业。大家不要忘了登陆他的Blog检查他的作业完成情况哦！
Martin的中文博客地址：http://blog.csdn.net/mfowler/
敏捷技术专家：
上海交通大学软件学院 副院长：林德璋 教授
Java视线?站长：范凯
Ajax中国网站?站长：李锟
UMLChina网站 技术专家：王海鹏
Jaction Group 技术专家：杨戈
J2EE技术专家：庄表伟
以下是专家对话的一些精彩片断。（现场大部分用英文交流，以下内容由韩锴翻译整理）
林德璋PK Martin：“RUP是楷书，XP是草书”对吗？
熊节：我这里有一个来自下面观众朋友的问题，而且这个问题很有趣，还跟林教授有关。据说林教授说过这么一句话：“UP是正楷,XP是草书，先用XP再用UP就会乱套。”我们先请林教授来解释一下。
林教授：我先用英文来翻译一下(speak in English)。欢迎您，你被我们称作教父。我们等你这次演讲足足等了一年。我们非常遗憾地错过你一年之久。
Martin：我保证，我那天非常希望能在酒店里面进行那一次的演说。
林教授：有趣的是“教父”说要一遍一遍地思考它。我们在软件行业已经工作了很多年了。我们从C++,到Java……所有这些语言都经历了比较长的时间。教父介绍给我们不同的语言。但是从我的这类接受传统教育的软件业者来看，我们接受的是UML和CMM，来自于RUP。人们都希望能非常严格的执行，并且实现起来并不容易。有一些人就在想，为什么大多数方法论都来自于美国。很多人从传统的方法学，转到敏捷，转到极限编程，原因是什么呢？这个我要问问您。
Martin：我不认为现在大多数的这样的转化，和改变都来自于美国。为什么敏捷真正的得到了重视？我想是因为学习的过程。当人们拿到一个大型繁重的方法的时候，他们不愿意去使用。当你去到IBM全球服务部门时，他们会给你看很多的文档，但是并没有看到任何真正的产品。另外，我们发现，工程仍然会存在失控的问题。有的时候，我们很晚才会意识到项目要延期了。重型方法论的另一个特点在于它吸引传统工程的开发，认为软件开发是需很准确的预计的。告诉开发者你需要的是什么，之后花几年时间得到一个产品。处于理想状态的时候，这样做是可以的。然而事情并不像想象的那样。因此，我们得到了学习。重型方法中指导的一些方法和实践，实际上不应该被采用。所以我们需要寻找新的方法。在你去探索的时候，你并不知道你走到了哪里，是不是接近了终点，我们就在这样探索着敏捷过程的方法论。我非常幸运的处在一个采用敏捷方法的一个公司。但是现在我们还看不到很多的改变。我现在仍然处在这样的研究过程，我们现在做项目的方式已经和三年前不同了。我相信，再过几年，又会有一个不一样的变化。有的时候，人们会谈起几年前的一个项目，然后会说到那是多么可怕的一个项目，他们的工作是多么糟糕。我想这是很好的一件事情，因为你可以看到你已经学会了很多。你可以看看你五年前写的代码。如果已经不能理解了，这不是一件好的事情。
林教授：非常好。我曾经在美国工作了很多年，当时我们有大概75%的项目都失败了，尤其是c++的。你同意么？
Martin：因为很多人对“失败”这个词有着非常不同的定义,我如果这样回答就太狡猾（tricky）了。软件有很多不一样的分工, 很多人在传统的计划驱动的项目里面失败了，是因为他们超过了预算。在敏捷方法里面，我们用不同的方法看待失败。如果项目没有（向客户）交付价值，那么它是失败的。所以一个项目可能是被延期，超过预算，但是它向客户交付了价值；也可能是按时，在预算内完成，但是却没有向客户交付价值。这两个定义是不一样的。大部分的项目都是令人失望的，我们可以做得更好。大部分的项目我们可以进行一些我们正在进行的实践，使它变得更好。我们这在致力于软件这个行业，希望能促进它的发展。
林教授：还有什么问题么？(开始回答关于正楷与草书的问题)现在Martin Fowler来这里是一个很重要的时刻。我总是感觉到我们软件学院的同学们可以思考一个问题，为什么这些人早年时受过严格的训练，写的书也是关于UML的，你不能批评他们不懂UML这些很严格的东西，他们本身就是UML的专家。但是，现在整个的思潮像钟摆一样转向了XP这一边，这一点值得我们深思。当然跟他们的环境有关系，还有一点，他们这些人，我们接触多了就发现，他们的反思能力特别强。不固执于认为自己对的一方面，他们始终在前进，去调整自己，所以他们发散性的思维和反思能力是值得我们去学习的。但是，问题是，我说过的那句话，中国软件业的现状，2006年，就成熟度讲，大概相当于美国的1986年，整整20年的落差。我们的起步是从一个农民的国家，一个完全手工作坊的时代，要改变到大工业，符合世界软件业的水平，有很多事情要做。正如现在有人开车，中国人开车和美国人开车完全不一样。我们最主要的，在这个时候，软件学院的教育更应该倾向于正规化，倾向于讲rules，讲严格的东西。这不像美国的工业。美国的工业从1986年以后，20年的发展，走过了一段很痛苦的时期。它走过一些很复杂的，非常讲究，而且可以说是教条主义。所以人们对于从DoD（美国国防部）发展出来的，像CMM这些东西，或者是UP这些东西，在美国有时他们进行反抗，他们进行叛变，这是完全可以理解的。但是，回到我们国家现有的情况，我觉得我们现在好像学习“正楷”还是非常重要的，至于现在他们的倾向，他(Martin)刚才也说了，他们也在摸索，他甚至于，回答我那个问题，他觉得他们所理解的感受和我们的感受还是有些差别的。他们认为他们也在这几年，现在做出来和去年比的话，他觉得他们也许会用另一种方法来做。所以他们的很多想法也在改变中。现在看来，这两个极端的东西都对我们有好处，我们可以从中学到一些他们长处的地方，特别是XP，像JUnit这样的软件，在没有code以前就先test，这个我看在软件工程界是已经承认了的。我回答已经完毕，有什么意见可以讨论。
Martin：如果我的理解正确的话，我刚才提到中国需要经历一段走向理论化的过程阶段，之后在走向敏捷过程，像XP这样的方法，因为美国经历过这样的一个过程。我不同意这样的观点，包括这在美国也是个必须一个过程，很多人确实经历过这样的过程。我认为在美国，很多项目需要花费很多资金用于表面工作，当你认真去观察事实上的工作的时候，你会发现它完全处于混乱状态。你看到的是他们已经掩饰好的一个表现，在事实上却完全不同。 Alistair Cockburn在他很早研究方法论的时候就已经揭示了这个问题。他研究了一些方法论，去采访了一些项目，询问他们的工作情况。他的做法是很聪明的，他找到项目领导和架构师，询问过程是怎么样的。做了记录。之后，他去找那些真正的分析人员，开发人员，并且询问过程是怎么样的。他对这两个方面进行比较，发现答案根本就不一样。Official Story看起来还不错，但是Real Story却完全不同，显得比较混乱。很多企业并没有采取这种重型的开发过程，我们也没有这样做。XP可以帮助项目解决这样无序的问题，他并没有看到RUP具有有竞争力，这个是在无序性方面的竞争。我们希望公司能够潜移默化，自然而然的使用方法，并且使它向前发展。虽然在一开始使用的时候也是混乱的。在美国可以使用的这些方法，我想在中国一定也是可以推广的。所以我不认为你需要重型的方法，你可以直接跳过这一步。我想说的第二点是，这里对于UML和统一过程有一个不明确的地方。这是两个完全不同的东西，但是通常被混在一起。人们发明UML的初衷是，当你使用UML的时候，可以使你避免使用那些重型的方法。我现在使用UML的频率和十年前是一样的。我所写的书里面也有很多很多UML，特别是关于模式方面的书。UML使沟通变得非常方便。不要认为你可以通过UML对于一个系统进行完整的分析和设计，这也不是UML唯一的用途。我在白板上画UML图，在书中用来解释一些问题，UML具有非常重要的价值。UML有很多应用的方式。在敏捷过程里，UML就具有很重要的作用，当然它也可以被用于重型过程。但是不要把这两个概念混淆在一起。UML是非常重要的工具，有着不同的应用方式。
王海鹏：刚才林老师讲的那一句名言给我一点感触，实际上就是说如果把它比作楷书或者草书的话，我们不能说楷书优于草书或者草书优于楷书，只能说是谁写出来的。如果我没练过的话，那无论是写草书或者楷书都不能拿到台面上的。实际上，就我知道的，在敏捷和建模这两方面实际上是不冲突的，而且有人会把它组合在一起用的很好，比如用feature driven development（FDD），就是由Peter Codd他们一些人做出来的，他非常强调在前端有一个domain的一个设计，做出一些domain的class，然后再进行一次一次的迭代来进行一种敏捷的开发。我想这可能就是说，如果是草书或者楷书的话，那它可能就是介于其中，行书，的一种做法。另外，林教授说Martin先练楷书，再转到草书，我想到中国书法家有一个人物，也是走过了这样的道路，就是八大山人。他早期的书法都是很规矩的一板一眼的有侧锋入笔，再提按，再折…练的是颜体。但是在他的晚期之后，他的所有的转折都已经圆滑了，已经变成草书那种写法了。我想这个可能和Martin先生的经历有一点点类似。提到这个比喻，是我刚才听到林老师的比喻之后想到的一些问题。
