1、Attack major risks early and continuously ...or they will arrack you
为什么要在早期处理最大风险呢？未被处理的风险往往会导致你潜在的投入更多的精力在有缺陷的框架或者不理想的需求上。实际上风险的数量往往与项目完成时间估算的上下限有关系。为了得到准确的估算，你必须首先着眼于识别和处理风险。
迭代模型和瀑布模型的比较差别：

出自文章：The Sprit of thr RUP
那么如何才能尽早的处理风险呢？在每一个迭代的开始，RUP建议你建立或修订一个重大风险列表，然后决定你应该如何处理这些风险，通常你需要找出最重要的三个或五个风险。比如风险列表可能看上去会是这个样子：
Risk 1：让我们担心的是，基于过去的经验，X部门并不会理解我们计划满足什么需求，这有可能会导致他们要求在软件的beta版本提交时候提出变更。
Risk 2：我们还不明确如何才能与老系统Y集成。
Risk 3：我们没有在.Net平台下开发或使用Rational Rose的习惯。
Risk 4：...etc。
好了，现在如何来使用这个风险列表呢？处理风险是项目组中每个人都应该考虑的事情。看看哪些应该是你一贯应该解决的，然后稍微调整计划来表明你确实要对这些风险进行处理。通常，风险的处理应该从多个角度入手考虑，比如需求、设计和测试。在每一个角度中，先拟定一个粗放的解决方案，然后持续不断的细化它，进而缩减这些风险。比如采用下面的这些手段来一一对应的解决上面的风险：
Risk1：当有关X部门的用例被制订出来的时候，使用UI原型进行补充。与X部门召开会议，然后与他们一起遍历这些用例，使用UI原型作为指导。在需求文档中获取X部门的正式签名确认。让X部门的参与贯穿项目周期，不断地为他们提供早期原型和alpha版软件。
Risk 2：挑选一两名开发能手成立“飞虎队”来构建一个实实在在的原型，来展示如何与老系统Y集成。之后集成的工作可能会告一段落，但是原型会证明与老系统集成的有效性。在整个项目中，确保有有效的测试涵盖对于老系统Y的集成部分。
......
Risk 3：派遣一些人去进行有关.net方面和Rational Rose的培训......
有很多项目风险与所选框架有关。这就是为什么RUP在精化阶段的主要目标是确保框架的正确性。为了做到这一点，你不能仅仅设计框架，还要实现并测试它。
时刻注意风险列表是不停变化的。与风险的斗争是一场持久战--每一次迭代都会减少或除去一些风险，与此同时，其他一些风险又会成长，新的风险也会出现。
2、Ensure that you deliver value of your customer
向客户提交有价值的东西显然是很重要的。那么如何才能做到这一点呢？我们的建议就是：把迭代和用例驱动方法密切的结合。
什么是用例？用例是一种捕获功能需求的途径。一旦一个用例能够清楚地描述一个用户如何与系统进行交互，那么相关的业务人员也能够描述清楚。一旦用例能够说清楚交互在时间上的先后顺序，相关的业务人员、分析人员就能识别用例中的任意的“hole（什么意思？）”。一个用例几乎可以被认为是未来用户手册的一部分，而它在被写出来的时候基本不用考虑特别的用户接口。不要想着在用例中写下用户接口（这里的接口也许是指输入、输出等）；作为替代，你可以以UI原型作为用例的补充，以截图的方式。
用例通常被很多人用来向掌管钱的客户展现他们的系统会做什么。但这并不是用例的主要益处。用例的主要益处就是能够让团队的成员更加贴近于需求，并以此指导他们的设计、实现、测试还有最终用户手册的编写。用例强迫你保持对于用户视角的客观性，并且它们使你能够验证设计和实现是否真正切合了用户的需求。它们甚至使你在为项目做计划和管理边界的时候能够小心谨慎的考虑用户的需要。

出自文章：The Sprit of thr RUP
时序图、协作图展现了这些与系统的交互如何被你的设计所实现。你同样可以根据用例来编写测试case。你可以选择要实现哪些用例，并以此划定你的系统边界。正如上面所强调的，用例会让你从始至终都围绕着需求进行工作。

读后感：

这篇文章看上去有些空泛，它曾经被刊登在ibm上，现在却再也找不到了。作者真正阐述清楚了RUP的Spirit了吗，还是他自己也是一知半解呢？