RUP的反模式
Julia Filho 著，沙萌、于宏光 译
转自UMLChina
导言
MILY: 宋体; mso-bidi-font-family: Tahoma; mso-hansi-font-family: Tahoma; mso-ascii-font-family: Tahoma">反模式就是不做什么：有些行为、习惯或者方法似乎很有价值，但对于准备完成的事情来说却没有帮助。本文讨论了多种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，从中学习经验并且将其与它人分享
文章来源于领测软件测试网 https://www.ltesting.net/