RUP是瑞理（Rational）公司经过不断的实践和理论总结发展出来的一套软件开发统一过程（Unified Process）的思想集和方法集。还记得我们在第一章的那张图吗，那就是RUP的核心图。RUP把软件开发过程分成4个阶段（Phases）和9个核心工作流程（Core Workflows），通过一次次的迭代（Iterations），完成整个的软件生命周期。RUP可以把软件开发过程分到非常细小的单位，每个角色（Workers）都参与活动（Activities），产生出工件（Artifacts）。由于精密的控制，所以RUP可以胜任于超大型的项目开发。虽然RUP定义了很多微小的活动，但是由于CASE工具的使用，它并不会像传统瀑布模型那样陷入文档的海洋中。RUP通过适当的剪裁，同样可以试用于较小型的项目。
　
　　XP（Extreme Programming），极端编程。不过好像并没有这样翻译的（听上去像是计算机领域的极右组织）。它是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。
　
　　制定了大量的规则的RUP方法被称为重量级（Heavyweight）的方法，而像XP这样只制定少量的规则来规范行为的方法被称为轻量级（Lightweight）的方法（实际上，现在有一种倾向称这种方法为Agile方法的）。近来，也看到一些文章在讨论两种方法孰优孰劣。例如：XP兴起，RUP不适合中国国情等。我想，这和以前大家讨论C++和Java谁好的性质是一样的。方法都有两面性，只有最适合的方法，没有最好的方法。我在实践中也感觉到，国外的理论确实不能照搬于中国，毕竟中国人的人文环境和国外相差太大了。不过，RUP不适合的，我想，XP也未必会适合。如果说，有人把RUP的一整套东西生搬硬套，导致了最后项目失败的结果的话。这种行为无异于刻舟求剑。
　
　　在我看来，RUP就像是一个软件工程思想和方法的大百科全书。在其中，你可以看到诸子百家的论调，可以了解软件工程的整个演化过程。RUP是很值得你投入大量时间去研究的东西的。一个武林高手走进了少林寺的藏经阁，你可以想想，那是一种什么景象。XP，更强调团队的充分交流，最大限度的发挥人的创造力。它并不制定大量的规则来限制人的行动（必要的规范是必须遵守的），开发的团队中的每一个人都能自由的发挥想象力，毕竟，软件是创造性的劳动（这听起来像是共产主义实现了一般）。至少，国内的公司都应该学习XP的一条规则：一周只工作40小时。相比较之下，RUP比较适合大企业、大项目，因为大的团队往往需要法制；XP适合于小团队，比较能够发挥小团队的创造力。但是在实际中，也有例外的情况。例如XP方法的第一个项目就是克莱斯勒公司的一个名为C3的大型项目。
　
　　在现实中，RUP和XP应用于目前中国的软件企业都有一定的难度。有一些来信来问我，RUP真的适合中国的企业吗？我会直接告诉他们肯定不适合。对RUP这个庞然大物来说，很难去评定它的优和劣。关键在于它裁减以后的样子。我看到过一篇文章，是讨论如何将RUP裁减适合XP思想的方法的。所以RUP的使用要很小心。一个高明的铁匠用铁锤可能可以打出一把好兵器，如果是普通人搞不好就会砸到脚。
　
　　提升企业的内力值并不是一两天的事情，这需要长期的投入和锲而不舍的努力。大刀阔斧的引进一整套流程并不是不行，只是猛药伤身这个道理大家也应该懂得。很多年轻有为的软件界人士希望在自己公司中引入先进的开发理念，但是在真正实施时，往往会被碰得头破血流，也有这方面的原因存在。对他们，我是很佩服的。
　
　　2.6、结语虽然该章的名称为需求过程，其中却花了一些篇幅来讨论软件工程中的概念。主要的目的是为了大家能够从整体的角度来理解需求过程，而不要把需求过程孤立的对待，否则，必然是见木不见林。
　

上一页  [1] [2] [3] [4] [5] [6] 

【责编:Lili】