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，从中学习经验并且将其与它人分享。