目前UP或RUP软件开发过程已经被很多企业所采用，敏捷方法也逐渐被很多公司使用，究竟是采用UP(RUP)还是敏捷方法呢？哪个更有效呢？

最有效的方法其实是根据企业自身的实际情况，来综合采用这两种方法，选择最适合你的最佳实践。

所谓最佳实践，是指人们在多年的实践过程中总结出来的最佳的开发软件的一些方法。

RUP中的最佳实践有：迭代式的开发、管理需求、使用构件架构、可视化建模、检验质量、控制变更，和使用Rational工具等。

敏捷方法以XP为例：

四大价值有：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）。

五个原则：提供快速反馈、简单假设、制造增量式的变化、包容变化、质保工作。

十二个实践原则：计划的制定、小版本、简单设计、测试、持续整合、重构、配对编程、代码共享、每周只工作４０小时、现场客户、隐喻、编码标准。

从文字上看两种方法中一致的有：迭代式开发、质量保证工作（检验质量，质保工作）。

下面就来分析一下这些最佳实践。

1. 可视化建模

XP虽然没有明确指出，需要进行可视化建模，但在实施过程中，编码之前，一般会在纸上划出要实现部分的草图，而且也使用UML，尽管是简单设计，但无论简单设计与否，这实际上就是在进行可视化建模。所以，在这点上与RUP是一致的。

2. 使用构件架构

RUP提倡利用构件提高可重用性。

XP提倡重构、配对编程，这实际上是利用这些手段来提高代码的质量，而提高可重用性，进行可重用的构件的设计，实际上是最主要的工作，包括设计模式的使用等等。

所以，在这一点上，两种方法的观点是一致的。

3. 控制变更

变更控制工具在软件开发企业中已经广泛使用，这一点不存在争议。尽管XP没有把它明确提出来。

4. 管理需求

XP没有管理需求的说法，但事实上对于关乎软件项目的全局的重要的功能需求，和非功能需求，是一定需要控制的，否则，如果项目进行到一半，然后推倒重来，即便是神仙恐怕也没办法让项目成功；至于对全局影响不大的变化，自然可以灵活处理，拥抱也好，放到下一个版本发布都是可行的。

所以，在这一点上两种方法也并不矛盾。

5. CASE工具的使用

RUP当然想让你是用他们RATIONAL的工具了。

XP拥护者中有人认为用纸和笔是最好的方法，但是如果用CASE工具可以提高效率的话，为什么要拒绝使用呢？

建议根据企业中员工都习惯的方式来决定是否使用，以及使用什么工具。

6. 简单设计

这恐怕是争议较多的一点，RUP提倡先进行系统分析，设计，然后再进行编码；XP则觉得只要画张草图，就可以编码了，之后就重构，拥抱变化吧。

其实我们要根据项目的复杂情况来决定设计工作要进行的程度。如果项目很复杂，一张草图恐怕真的没有办法阐述清楚，也没有办法成为涉众之间进行交流的工作产品。这样就必须对这个复杂的问题进行抽象，提取，简化复杂程度，直到简化到可以被人们容易理解，这个过程就是系统分析设计。

对于简单问题自然不需要进行详细的分析设计。

7. 重构

重构是提高代码质量的有效手段，因为迫于进度压力等原因，通常一次就写出优秀的代码确实不太可能，因此，重构可以发挥很好的促进作用。

RUP中的代码审查，走查等手段从检验的角度来进行代码质量保证，当然这都是事后的手段，如果代码质量不合格，自然需要修改，这可以算作一种促进重构的推动力。

8. 配对编程

两个人的智慧胜一人，在这一条上得到了充分的体现，但对人员素质要求还是较高的，如果人员素质参差不齐，可能就变成一个人指导另一个人，或者两个人没办法达成一致意见。

所以，通过代码审查，走查等手段同样可以起到对代码质量进行监督，检验的目的。

9. 测试

XP中提倡的测试先行，的确可以在没有良好的设计模型的情况下，起到一个明确思路的作用。但如果有设计模型，在功能和接口都已经明确设计好了的情况下，测试先行或后行区别可能并不大，但一定要有测试程序，这有利于进行回归测试。

10. 持续整合

持续整合是检验工作成果的有效手段，在不影响正常工作进度的情况下，整合工作做得越早越好，这样可以及时发现整合过程中的问题。

11. 小版本发布

RUP也提倡每个迭代周期发布一个可以运行的版本，当然这个迭代周期是多长时间，可以根据项目的具体情况来决定。

总之，要灵活使用这些最佳实践，任何方法都不是简单的教条，一定要具体问题具体分析，这样才能保证软件项目的成功。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号