RUP与敏捷开发之比较

RUP与敏捷开发之比较RUP（RationalUnifiedProcess）是由原Rational公司（现为IBM收购）推出的一种完整而且近乎完美的软件过程。RUP总结了经过多年商业化验证的6条最有效的软件开发经验，这些经验被称为“最佳实践”。分别为：迭代式开发，管理需求，使用基于构件的体系结构，可视化建模，验证软件质量，控制软件变更。在RUP中有9个核心工作流，分别为①业务建模，②需求，③分析与设计，④实现，⑤测试，⑥部署，⑦配置与变更管理，⑧项目管理，⑨环境。其中前6个为核心过程工作流程，后3个为核心支持工作流程。RUP把软件生命周期划分为4个阶段：初始阶段，细化阶段，构建阶段，移交阶段。每个阶段都有明确的目标，并且定义了用来评估是否达到这些目标的里程碑，在每个阶段结束前都有一个里程碑评估该阶段的工作成果。所以RUP的计划性是很强的。事实上，RUP重复一系列组成软件生命周期的循环。每次循环都经历一个完整的生命周期，她的文档也是非常丰富的。从针对领域建模的类图（classdiagram），系统顺序图SSD（systemsequencediagram），和做需求的用例（usecase），用例图（usecasediagram），到做设计的顺序图（sequencediagram），通讯图（communicationdiagram），以及描述体系结构的包图（packagediagram）,部署图（deploymentdiagram）等等。不可否认，RUP作为中大型软件的开发过程是很合适的。因而便有以下的问题，RUP对于小型软件开发是否完美呢？答案是否定的，严格的计划，复杂的文档对于小的团队简直就是噩梦。因为几乎没人愿意花大把的时间在生成文档上。所以对RUP进行适当的裁剪以适应小项目，小团队的需求变得迫切起来。于是在2001年2月，众多软件专家联合起草了敏捷开发宣言。旨在使软件开发团队具有高效工作和快速响应变化的能力。个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户需求胜过合同谈判；响应变化胜过遵循计划。以上便是敏捷宣言的4个基本价值观。敏捷实际上是轻量级的软件开发方法，敏捷开发的最佳实践有极限编程(XP)SCRUM方法，DSDM方法等。敏捷开发作为一种TSP团队软件过程，她和RUP一样，非常注重了解团队每个成员的优点，缺点。发挥队员的长处，帮助队员客服弱点，互相帮助，共同成长，最终整个团队的能力得到提高。我们重点看看敏捷过程中最负盛名的一个——极限编程（XP）。由此比较RUP与敏捷过程的异同。首先，项目组针对客户代表提出的“用户故事”（类似于用例，但比用例简单，通常仅描述功能需求）进行讨论，提出隐喻，在此项活动中可能需要对体系结构进行“试探”（所谓试探就是提出相关技术难点的试探性解决方案）。然后，项目组在隐喻和用户故事的基础上，根据客户设定的优先级制订交付计划（为了制订出切实可行的交付计划，可能需要对某些技术难点进行试探）。接下来开始多个迭代过程（通常，每个迭代历时1~3周），在迭代期内产生的新用户故事不在本次迭代内解决，以保证本次迭代开发过程不受干扰。开发出的新版本软件通过测试之后交付客户使用。综上所述，以极限编程为杰出代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特征，而且在快速的同时任然能够保持可持续的开发速度。上述这些特点使得敏捷过程能够很好的适应商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束。由此我们可以知道，敏捷开发与RUP相比裁剪了很多内容。这些内容主要集中在每次迭代的流程。在RUP中，每个迭代都严格遵循着9个工作流。而敏捷开发则是“能用则用，能不用则不用”。即对我有用的工作，我会做，对我无用的工作，可以跳过。另外，敏捷过程中客户的位置与作用是重要的，不可替代。可以说客户也是软件开发团队中的一员，更是软件的最终验收人。因为有了客户的参与，所以软件开发变得简单、清晰。在RUP中大量使用了UML建模，所以团队人员得先熟悉UML，否则除了RUP模型图之外你基本上看不懂细节内容。可是在普通企业里，大部分人（尤其是领导和管理人员）不熟悉UML。所以在敏捷过程中，我们不提倡面面俱到的文档。敏捷建模才是开发人员应该重点掌握的，所谓敏捷建模就是不依赖于专业的建模工具（如RationalRose，MicrosoftVisio），而是大量使用白板（也可以是白纸，黑板等等）画草图。而且草图也不一定完全遵循UML文法，只要是方便团队成员之间的沟通和理解均可。举一实例，在我去年暑假所做的一个基于Android平台的定向运动游戏项目中，我们小组就大量使用了UML草图，直接手工画，方便快捷。一般来说，对于小型项目，硬件要求和系统复杂度都相对较低。所以很多团队都省去了配置与变更管理这项工作流，而且效果很好。在敏捷钟我们主张快速交付原型软件，这就意味着我们必须对设计过程进行适当的简化，越是简单的设计就越容易开始项目。事实上，项目的需求是不可能一蹴而就的。迭代式的发现需求，响应需求是RUP和敏捷过程共同包含的。说到这里有些人可能会想：那是不是敏捷过程就不需要文档呢？答案依然是不是。敏捷过程仍然需要文档，比如，软件测试。这些测试代码真实的反应了客户的需求以及系统API的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。如果用书面文档或者注释，某天代码变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，代码才会变化，测试是真实反应代码的。好了，我们现在知道敏捷过程是需要文档的，那这些文档和RUP文档有什么差异吗？差异是明显的！在敏捷过程中，为了节省成本，我们不再事先编写大量的相关文档去记录随时变化的信息，取而代之的做法是缩减文档数量，只生产一些必要的文档资料（在敏捷的世界里，很多工件都是可选的），并且我们精简这些文档内容。一段注释,一张流程图,一张照片等，与那些将来束之高阁做足表面功夫的文档相比，这种形式更加简练，内容更加突出的轻量级文档，更适合小团队开发。而且本人在上文也提到了敏捷是对RUP的裁剪，注意是裁剪而不是彻底的抛弃！在敏捷过程中对于文档生成的方法，也是和RUP不同的。轻量级文档，轻量级生成，即是通过优化文档的更新方式，使文档更新工作变得智能化、自动化。这种解决方案的目标就是把文档的组织和更新工作交给软件系统，从而降低人工成本，节省资源。如何实现呢?根据许多软件开发机构的调查，文档之间存在一定的相似性，譬如一些文档来源于相同的数据源，文档内容的组织方式固定不变，文档的格式确定等等。于是他们提出一个想法，对于具有相似性的文档，不妨通过一个模板来统一生成。该模板规定了以下内容：从哪些数据源中取数据，从数据中提取哪些内容，这些内容如何排版，生成怎样格式的文档。通过模板的使用，可以圈定文档内容的范围，文档内容的层次，以及文档的风格，避免了内容的丢失及格式的混乱，并且通过这种方案我们能实现生成文档自动化。所需要做的，是抽象出文档的共性来构造一系列模板，然后通过模板的套用来生成文档，类似于活字印刷术。一次构造，多次使用，从而使文档更新流程化，便捷化，达到轻量级的效果。高兴的是现在已经有类似的工具了，如微软的REP。最后我在此说一说我所在项目团队中关于敏捷过程文档的生成。我们今年的项目名称为PHS（PersonalHealthSolutions）个人健康解决方案。软件的开发将会使用IBM公司的软件开发协作平台Jazz。作为学生来说，我们必须学习。所以最后的文档应该比正常的敏捷过程多（比RUP要简化），我初步是这样估计的。在软件开始规划阶段，即软件开发的第一个迭代中，我们只是要开发出一个系统愿景，了解配置开发环境。定义系统的用户，通过用户进一步细化我们的需求。而在此时我们暂不考虑体系结构的问题。完成这一个迭代，我们就直接进入开发，根据上一个迭代找到的用户需求，按功能点分成多个用户故事。快速完成最重要也是最困难的功能，交付用户看是否与客户设想的一致。完成存档记录，并根据用户的反馈调整随后的开发计划。所以在这里我们简化了精化阶段的工作，而且生成的文档也只有粗粒度的需求文档，软件开发愿景，细粒度的用户故事，还有客户反馈的意见文档，规划下一次迭代。在RUP中很注重软件过程的管理，开发的监视和控制。所以会产生很多的相关文档，而在我们敏捷项目中，我们团队每个成员都是积极主动的参与者。集体目标是一致的，所以我们更多的是引导和帮助，而不是管理与监控。我们在软件开发中将采用开发与集成同步的方式，不等系统集成开始，开发出的每个功能点，每一段代码都会马上集成到系统中，并立刻测试验证。所以我们最后的集成文档是可以略掉的。同时我们还避免了很多监控和测试的文档。