RUP的反模式（转）

http://www.sawin.com.cn/doc/SE/RUP/antirup.htm

RUP的反模式

Julia Filho 著，沙萌、于宏光 译
转自UMLChina
导言
反模式就是不做什么：有些行为、习惯或者方法似乎很有价值，但对于准备完成的事情来说却没有帮助。本文讨论了多种RUP反模式，收集来自Black Diamond Software指导RUP使用者在各种不同大小，人员组成技术环境和工业项目中的经验。本文讨论了每一种反模式的本质，以及怎样才能避免的措施。

反模式
1. 瀑布RUP

“我们目前的迭代是需求，下一次迭代才是设计”

对那些一直遵循严格的瀑布开发过程的人们而言，瀑布RUP是最容易犯的错误之一。瀑布RUP是反模式的原因很简单：它不能帮助降低风险程度，而降低风险是基本的RUP原则之一。RUP迭代式开发要求每次迭代应该是一个应用程序的“小型发布版”。每次迭代有小型的需求，设计，开发和测试环节，并且交出应用程序的一个可运行部分。使用这种方式，需求、设计、实施和测试的问题在每一次迭代中都得到“冲刷”，要求问题越早解决越好（问题越早解决其消耗的代价就越小）。

如果瀑布阶段没有转换成迭代，会怎样呢？功能块就会成为迭代，用例成为功能“片”的基础。通常RUP表明了用例的优先性，同时也说明了内在的风险决定用例怎样被划分到迭代中。

2. 准备-设置-RUP

“公司说每一个人都应该遵循RUP，所以让我们开始吧”

决定采纳RUP作为方法学通常源于高层领导。CIO、CTO或者其它的高层的技术领导决定所有新的项目必须遵循RUP。然后每一个部门决定怎样将RUP应用到他们的项目中，于是他们购买该方法学，并且相信他们已经做好准备。第一个项目组在接受某些RUP培训后热火朝天的开始实施。他们尽可能的严格执行该方法学的要求，但是这好像有些难以容忍－RUP太庞大了以至于他们深陷在disciplines, artifacts, milestones之中而迷失了。如果项目的完成日期迫近，而他们仍然陷入方法学的泥潭中，他们就会绝望，就会退回到他们原来知道的但是不是RUP的方式来解决问题。这个项目组从前有很好的意图，但是为了能够在最后日期前完成任务，最终退回到他们原来了解的最好的方式。

RUP是一种相当大的方法，而且独自解决它是项艰难的任务。对于已经适应不同于RUP方法学的组织，例如瀑布模型，第一个RUP项目是一个巨大的挑战，超出典型的项目挑战。当它被完全贯彻下来，你就会发现采纳RUP的原因，才会发现RUP的功效，所以退回到原来的处理的方法是不能被接受的。

那下一步应该做什么呢？下一步要做的就是在整个组织范围内贯彻RUP。尽力建立一个支持结构，目的是使项目组成员不要经常偏离他们努力的目标。你也许会发现你需要其他具有丰富RUP经验人的帮助，这意味着招聘一个具有RUP背景的雇员或者有从外部获取RUP帮助的渠道。其实你真正所需要的是决定怎样将RUP应用到特定的项目中，和怎样使用RUP的相关技术，例如用例开发等。有时一点指导会帮你少走很多弯路。

3. RUP－全部工具的总和

“我们拥有Rational的工具，所以我们已经做好开始的准备”

这是另一种“准备－设置－RUP”，是对工具的扭曲认识。在这种反模式里，项目组拥有RUP方法学和Rational的工具，他们已经准备好开始一个RUP的项目。问题是RUP不是所有工具的和。这些工具可以帮助方便实施RUP的很多活动，但是利用这些工具不能确保能够有效的实施RUP。你知道准备应用的这些工具是做什么的吗？你知道你怎样做才能适合软件开发过程吗？举一个例子，如果你使用Requisite ProTM来进行需求管理，那么你知道怎样保证需求信息被整个项目组共享吗？怎样将Requisite ProTM正在收集的需求信息反馈给用户呢？知道怎样利用Rational工具是很重要的，但是理解这些工具所支持的活动以及这些活动之间的相关性也是必须的。简单的说，实施RUP可能会驱使你使用这些工具，而不是因为有了工具而使用工具。

要熟悉RUP的理念。要思考这些理念与你以前熟悉的方法学的理念有什么相似和不同之处。要熟悉Rational Tool Mentor，这些指导为你使用Rational 工具来实施RUP提供很多宝贵建议。

4. IT是一座孤岛

“IT遵循了RUP，这就足够了，对吗？”

你所在的IT组织已经决定使用RUP实施一些项目了。项目组的成员都接受RUP的培训，而且拥有必需的工具，并且聘请了一位具有丰富RUP经验的专家，所以现在准备实施了，对吗？你是否考虑过IT外部因素对RUP实施的影响呢？RUP的每一步，系统需求都是利用用例来描述的，最好是根据直接用户提供的资料得到的。但是你的用户做好准备花费时间来建立和审查用例了吗？他们知道什么是用例吗？你的DBA曾经接受过RUP的培训吗？他们准备好用迭代的方法接受数据模型/表变化请求吗？所以要让所有相关的成员知道RUP是怎样影响他们，知道RUP怎样利于项目成功，是很重要的。

5. 我们什么时候开始编码

“用例太耗费时间了，所以我们马上编码吧”

用例是花费时间的。的确。但通过不停的编码，编码，再编码找到“隐藏”的需求的办法就不花时间吗？在开发中出现的需求问题的频率又怎样呢？虽然建立用例也不能确保所有的需求被覆盖，也未必能满足所有用户的需求，但是使用这种方法比起“得到一点需求就进行编码”要高效的多，因为毕竟这种方法是在开发前进行需求分析的，而在开发中调整需求的代价则是巨大的。

项目经理比开发人员更渴望结束用例并开始编码，这并不奇怪。通常开发人员会说“现在已经拥有很多的信息了”，而此时项目经理则会检查他的日程，关心是否能够按时间完成项目。在建立完用例后，完成用户业务目标的用户/系统的迭代模式就存在了。这种用例模型除了可以作开发者的系统需求外，还可以是测试计划和培训材料的重要的输入材料。

6. 什么时候完全做好呢？

“我们要在开始时为所有的迭代做一个项目评估并且坚持将评估贯穿整个项目”

有多少次你被要求对你的项目做大致正确的评估，假设这种有漏洞的评估是基于非常有限的信息并且可能在项目的进行中发生巨大的变化，然后无论他们是多么的不正确，这些评估总会被保留下来？保守地说，在某种程度上，我们大家都是如此。

RUP的目的是消灭这种做法，它要求项目要做初始的全局性评估，要求每个迭代应该在被执行前进行评估。开始当信息了解还比较少时，可以做一个“低分辨率”的项目评估，随着项目信息的了解深入，它可以进行修改。从每一次迭代评估中得到的知识都被输入到下一次迭代评估或者整体评估中。另外“时间盒”（time-boxing）可以用管理范围。这种方法提倡在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。

这种方法行得通吗？答案是，这种方法只有公司高层领导和用户都赞成RUP时才能实施，因为他们决定批准或者否决项目的预算、项目完成日期的延迟和项目的应用范围的变动。我们再次强调“IT是孤岛”反模式，外部因素对项目组的成功影响巨大。

7. 食谱RUP

“RUP的规则在那里？我需要手把手的指导”

RUP提供象食谱一样的方法了吗，“RUP食谱”中每一个烹饪法都对应一个不同的项目？答案是没有。RUP只是提供了指导，并没有需要遵循的固定不变的规则，因为任何一个项目都是不同的。特定的用户群，以及与目前存在问题相关的项目组的核心能力都是动态的，甚至是项目成员物理位置的变化范围都不是任何一本食谱能够完全描述清楚的。所以根本就不可能存在这样一本万能的食谱。

那么你怎样实施你的项目呢？第一步你需要花一些时间为你特定的项目定制RUP，下一步为你的项目建立开发案例。这个工件在初始阶段建立，描述了怎样定制RUP以满足项目的具体需要。

8. RUP是万能的

“我们遵循RUP，所以所有项目管理、团队和组织的问题都会被解决”

RUP为管理和实施项目提供了有价值的指导，但是它不是万能的。它可以告诉怎样才能成为高效的管理者、好的程序员、有用的团队成员或者高效的组织。例如，RUP的项目管理向导可以根据RUP方法学解释怎样进行组织、计划和实施一个项目，但是项目经理需要知道怎样管理他们的职责，成员、完成日期等。RUP提供设计和构建的向导，但是程序员需要知道怎样进行编程。对于已经采纳RUP的组织需要知道怎样整合和支持新的方法学。不是所有的组织、项目和团队成员都具有这样的能力。但是这并不意味RUP不能被采纳，而是意味着需要面临一个曲折痛苦的学习过程，或者说需要额外的帮助。

9. 过分的-强制的RUP

“我们必须完美和彻底地建立所有的RUP工件”

这样做的后果是你永远不可能完成你的项目。

和很多其它的方法学一样，RUP也包含很多的活动和工件，这些活动和工件在合理的时间范围内不可能被完成。RUP并不是要求项目必须遵循它所定义的所有的活动和工件。实际上对于新项目，RUP最初的任务是建立开发案例－用于确定所有需要建立的工件。这里可以根据项目组织情况，技能水平等不同的因素确定哪些工件是重要的，例如当进行设计的时候，你需要创建序列图，协作图，类图和状态转换图吗？也许没必要。也许你在每一个用例开发中真正需要的是类图和用来表示复杂逻辑的序列图；也许你正在开发一个工作流项目，描述状态转换的信息就是很重要的，这时候你需要状态转换图。总之，也就是说每一个项目都有自己侧重的工件需求。

决定在某一科目（disciplines）中选择或者排除哪些工件也许是很困难的。这里的关键是你要理解项目组织的需求，工件的阅读对象和全面的项目任务；另外需要理解工件需要的、能够作为迭代过程的因素。项目组在进行一次或者多次迭代后，需要考虑增加一些在初始阶段认为并不重要但是现在看起来十分必需的工件。

另外，创建工件虽然有些苦头但是并不是很困难的。每一个工件的细节层次以及信息数量都要和工件要解决的问题的复杂性相适应。例如，对一个需要花费2个月时间完成的项目，其业务用例不可能象企业范围的项目那么全面－如SAP。

我们已经讨论了一些RUP的反模式，在遵循RUP方法时试图避免它们。我们已经讨论了克服或避免产生这些反模式的做法。需要记住的是采用新方法需要时间，同时尝试与出错往往是学习的最佳途径。可以在一些不是很重要的项目中实施RUP，从中学习经验并且将其与它人分享。

But why must RUP?  Why not other things, such as XP, FDD, ASD, Crystal?

1. 瀑布RUP
这一段阐述有些问题。首先不能认为所有的迭代都会提供一个可以运行的程序，比如在最初的迭代中主要是确定需求和风险，制定迭代计划。这些工作提供的工件是需求说明和开发计划，而不是具体的代码和程序。基本上所有的方法都会支持你这么做，而不是仅仅RUP才如此。而同时在后面的迭代中会提交一些小的版本，但是这些版本未必就是用来发布的。特别是测试往往不会和开发采取同一的迭代频率，而且我认为也没有必要采取同一的频率，它完全可以慢一些，充分一些。而只有经过一定的测试才可以发布，并且很多达到发布的标准中就有必须经过多少多少时间运行不崩溃等等这些需要时间的测试。

2. 准备-设置-RUP
我看阐述中的人并没有遵照RUP去执行，因为他们没有裁减。虽然一个笑话说：“RUP必须经过裁减才可以实施，当然只有RATIONAL才知道怎么裁减。”但是如果你不知道然后裁减就去实施RUP而出了问题，恰恰不是说明RUP有什么问题，而是实施的人不理解RUP出的问题。
RUP不是一种复杂而庞大的方法（注意这个方法是严格意义上的方法，不是方法学上的方法），它的分析和设计技术都相当的简单，至少比我熟悉的FDD简单的多，也小的多。它只是包括一个怎么写usecase，如何使用名词法确定类，然后就是给usecase确定所谓的边界类、控制类、数据类，而说RUP会告诉你怎么得到framework我看都不可能，就不要说architecture了。而真正的复杂也只是对工件和工具的使用上出现的情况，而如果你完全理解OOA&D就会觉得没有太多的困难。
而当那些人不能很好的掌握RUP的技巧，从而返回原来的方法绝对是一种应该被支持的做法，而不是去反对他们。方法还是一种工具，如果不能完成任务，就去选择可以完成的来。这如果也是一种反模式，那么还有什么可以被认为是正模式呢？

3. RUP－全部工具的总和
这里我倒是要从另外一个方面去问个问题：没有那些昂贵的工具，你能说你准备好了实施RUP了吗？
这里还是有一个裁减的问题，你究竟是不是把你支持的工件裁减为轻型而足够了吗？而如果你不去裁减那些东西，没有RATIONAL的工具去实施RUP，肯定就是一场灾难。没有这些工具，你就无法保持这些工件的同步和可维护、可管理。
所以这里还有一个反模式－－没有工具去实施RUP。

4. IT是一座孤岛
这里的情况可以说你使用任何方法都会失败，这不是RUP的反模式，而是软件开发的反模式。
用户不去评审他们的需求，你认为你的项目会成功吗？而用例已经足够简单，足够直接了。我实在找不到比这个工具还简单的正式手段了。当然你说你可以使用直接沟通的那些手段，比如CRC和USERSTORY，但是这样客户付出的资源更大，他们都不接受usecase，会接受这样的进一步要求？？
“所以要让所有相关的成员知道RUP是怎样影响他们，知道RUP怎样利于项目成功，是很重要的。”似乎说的很对，但是为什么不去说说RUP可能也会失败，并且失败的会很惨呢？这样的信息是全面的吗？这样的信息就不是孤岛了吗？
5. 我们什么时候开始编码
这一条是怎么写上去的，他们是写第一条的那些人吗？

6. 什么时候完全做好呢？
又是一个第四条的逻辑重演。我要反问一句，管理者和客户不支持RUP，那情况会怎么样呢？是不是因为他们不支持，项目就会按照他们开始的时间表进行下去呢？如果他们不支持RUP，你能有什么方法做到比RUP所提供的更好的方案吗？是不是加班和减少测试时间来满足那些对于工期的不合理要求呢？
这不是一个孤岛的问题，而是一个态度的问题。就好像我不能要求你在5秒内跑100米，你也不要要求我在我不可能完成的时候完成那些东西。这个上面是不是可以讲价钱呢？
7. 食谱RUP
这里好不容易开始说裁减了，不过说得太不成功了。
“第一步你需要花一些时间为你特定的项目定制RUP，下一步为你的项目建立开发案例。这个工件在初始阶段建立，描述了怎样定制RUP以满足项目的具体需要。”
其实定制的工作在项目还不知道在什么地方的时候就已经开始了，他面对的是你的组织和你的行业。只不过面对具体的问题的时候你还是需要作出局部的调整。而完全只依靠在项目中去制定这样一个定制化的RUP，我实在看不出成功的可能。而所谓的开发案例就更加莫名其妙，它告诉了你然后定制，但是却是在定制结束之后才产生。其实这个东西是一种确定RUP裁减的策略，应该在最早的还没有具体的项目的时候就去确定了。

8. RUP是万能的
“RUP为管理和实施项目提供了有价值的指导，但是它不是万能的。它可以告诉怎样才能成为高效的管理者、好的程序员、有用的团队成员或者高效的组织。”
RUP似乎没有这样的能力吧？高效的管理者如果只是学习RUP，似乎还做不到高效。别的也一样，都需要通过专门的培训和学习，而且RUP所要求的未必就是那些通用的素质。比如这里没有涉及重构和持续集成，也没有要求TDD，这样的东西可以认为就是好的吗？
9. 过分的-强制的RUP
又是裁减的问题，没有裁减的RUP，肯定不能称为过分和强制的RUP，倒是可以称为稀里糊涂、莫名其妙、不知就里的RUP。而且工件也不是裁减的唯一重点，还要对活动进行裁减，对工作流进行合理布置，还要进行迭代结合过程改进的计划。这些东西都是要做的工作，而不是仅仅去考虑工件是不是有效的这一个问题。

这里就是有一个问题，Rational 把 RUP 控制的太严了，以至于 Open Source 根本无法实现 RUP。而 XP 的工具全部都是 Open Source 的。
对于过程这类东西，我们很多时候需要的并不是一个 meta process，而是适合我们的很快就可以采用的 instance process（我生造的一个词，不好意思）。我们不需要买了一大堆工具，然后还要再请一个有 20 多年业界经验的咨询专家来帮我们实施开发过程。我们希望能够自己动手解决我们的问题。

RUP 的缺点是很容易造成歧义，正因为它是 meta process，太灵活，不同的人有不同的解释。XP 则不一样，XP 的那本小书说得那样直白，如果你还是不明白我简直要怀疑你如何从大学毕业的了？XP 对于增强过程的可理解性做了很多有益的尝试，但是 XP 还缺少一些内容，把这些内容补充起来我觉得就很好了。国内的很多项目也就不到 10 人的规模，如果大家都能增强自己的能力，XP 一类的过程已经足够了。当然 XP、RUP、CMM 都有适用的场合，我并没有否定 RUP、CMM 在某些场合是适用的。

软件开发最重要的是代码和人，而不是过程，这是我一贯的观点。生搬硬套任何过程都是会吃亏的，区别是吃亏的大小，XP、RUP 吃亏比 CMM 还要小得多（用 CMM 你会吃大亏，看看你有多少钱，一个亿，没问题，CMM 折腾不死你。你只有一百万？那还是别送死了）。我一直反感的就是企图无所不包的“大方法论”一类的东西。

看2位评论，小弟我汗颜


这个问题问得好，什么时候开始编码呢？2位老大谈谈呢？