51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2133|回复: 0
打印 上一主题 下一主题

[讨论] RUP与XP的平衡之道

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2018-6-21 17:23:14 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
人有过什么经验,遇到过什么恐惧的事,就会形成设法避免这种事情的方法学。研究重型方法学的人可能
一直以来的经验就是组织上千人的开发队伍进行开发,比如说大型电信系统的开发、军事航天系统的开发
......这种项目严格强调过程执行的规范,注重文档规范、评审及过程度量。而发明XP的人可能一直是在小
团队里做项目,项目团队只有3、5个人,项目总是会因为没有满足用户价值而被Cancel,开发公司也蒙受
损失,因此注重与用户的交流、反馈,强调快速、灵活。

每种软件方法产生的背景不同、特点不同、适用的领域亦不相同。那么对于软件项目来说,是否可以使用
同一种软件开发方法来对不同类型、规模、复杂度的项目来进行开发呢,显然是不合理的。

前不久,恰巧和国内一位资深的软件工程咨询顾问做过一些交流,他本人热衷于RUP的过程改进,倡导针
对不同类型项目进行适当的裁剪,实际上这也是一种灵活适应的方式、随需而变的思想。我对此是理解并
赞同的,但是我对RUP却一直保持一种相对谨慎的态度。

对于RUP来说,首先,我认为它过于理想化和理论化,RUP 是过程组件、方法以及技术的框架,你可以将
其应用于任何特定的软件项目,由用户自己限定 RUP 的使用范围。对于各种类型的软件项目,RUP并未
给出具体的自身裁减及实施策略,总有些无依据可循的感觉。你既可以说它能解决任何问题,也可以说它
什么都不是;其次,RUP从本质来说还是一个强调设计和规范的软件方法,从这个角度来讲,与传统的瀑
布模型没有太大差别,它的灵活性较之敏捷方法还是相对较弱的。在一些小型软件项目、特别是不可预
测的软件项目开发中,面临着各种紧急需求、面临着时间压力,沿用RUP是很难应付自如的。但是在另一
方面,RUP强调对知识的收集、整理和加工定义,强调在软件开发的时候要有好的体系结构。所以它还是
很有利于知识的积累和共享的。

相比RUP ,敏捷方法如XP则更为灵活,倡导尽早的、持续的交付有价值的软件满足用户需要。用交流沟
通取代详尽的文档,强调团队的主动、自律、自我组织和自发管理。而XP也是以代码为核心的一种方法,
这里有很多的东西是未知的,知识只存在于两个地方:开发者的头脑和最后的代码。对于项目管理者来说
,他们会认为敏捷开发方法弱化了知识管理的概念,而实际上敏捷开发注重的是最有价值的知识的积累和
沉淀。

如何灵活应对各种项目风险、如何最大化优先满足用户价值、又如何能够有效的控制项目开发过程、如果
做好项目过程中的知识管理,是每一个软件项目管理者都需要深入思考的问题。RUP的倡导者一直强调R
UP裁剪,实际上我认为RUP不仅仅是需要自身的裁剪,还需要学会融合。在RUP裁剪的同时,适宜的融合
敏捷开发的各种实践。不要认为RUP与XP是矛盾的,其实不然,它们具有不同的原理、具有不同的应用领
域。在 RUP 中融合了 XP 技术时,才会得到过程的正确量,既满足了项目所有成员的需要,又解决了所有
主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队,其中用户是团队的一部分,那么 X
P 完全可以胜任。对于团队越来越分散,代码量越来越大,或者构架没有很好定义的情况,您需要做一些
其他工作。在用户交互具有"契约"风格的项目中,仅有 XP 是不够的。RUP 是一个框架,可以从 RUP 出发
,在必要时以一组更健壮的技术来扩展 XP。

RUP最佳实践包括:

1. 迭代开发
  2. 管理需求
  3. 使用基于组件的构架
  4. 可视建模
  5. 持续的质量验证
  6. 控制变更

 12 个 XP 实践包括:

 ◆有计划的开发:通过结合使用优先级"故事"和技术估算,确定下一版本的功能
  ◆小版本:以小的增量版本经常向客户发布软件
  ◆隐喻:隐喻是一个简单、共享的"故事"或描述,说明系统如何工作
  ◆简单设计:通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立刻进行移除
  ◆测试驱动开发:用户编写测试内容以对"故事"进行测试。程序员编写测试内容来发现代码中的任何
问题。在编写代码前先编写测试内容
  ◆重构:这是一项简化技术,用来移除代码中的重复内容和复杂之处
  ◆结对编程:团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动,另一
个人同时审查代码的正确性和可理解性
  ◆集体代码所有权:任何人都拥有所有的代码。这就意味这每个人都可以在任何时候变更任何代码
  ◆持续集成:每天多次创建和集成系统,只要任何实现任务完成就要进行
  ◆每周 40 个小时:程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的
  ◆现场客户:一名真实的客户全时工作于开发环境中,帮助定义系统、编写测试内容并回答问题
  ◆编码标准:程序员采用一致的编码标准证

RUP与XP的融合,是各自特点的相互补充,也是软件开发方法的平衡之道。而对软件技术平衡的思考也
可以说是技术成熟的开始吧。

最后,再阐明我对软件项目开发的理解。在软件项目开发过程中,应该能够识别、分析不同软件项目的
特点,采用相对适合的开发实践来适应软件开发过程,保证对软件开发的有效支持,以便能够创造出“足
够好的”软件。而这个足够就是对 进度、成本、质量之间的平衡,最大化满足客户需要的实现。

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-16 14:11 , Processed in 0.065349 second(s), 24 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表