用户操作
[即时聊天] [发私信] [加为好友]
袁琳ID:testwin
175574次访问,排名430好友2人,关注者34
敏捷测试的探索者
testwin的文章
原创 45 篇
翻译 0 篇
转载 84 篇
评论 89 篇
TestWin的公告

About me
Who am I?SpiderMan

QQ点击这里给我发消息 8646328
MSN: testwin@sohu.com

友情链接
段念-关河测试网
汪浩-BeyondTest
王东刚-FastPoint'Blog
陈雷-jackei 的测试生活
崔启亮-软件测试新观察
陈绍英-探索中国软件测试之道
oldsidney-学习笔记
李丽君-小蚂蚁测试历程
李默-敏捷需求分析
徐昊-桃之夭夭
Roger-敏捷开发、web2.0 Franky视频网站
... ...

最近评论
样子:不知道楼主是不愿意把经验给大家分享出来还是设计原则就这么简单,上面说的是没有错,但是目前国内大多数公司的流程完全不具备设计的条件,很多适合测试已经被遗忘到某一个角落,或者说发版前两天全体动员开始紧张的测试,到最后回归测试都不知道该如何去做,只能简单的跟踪一下是不是还能重现,放出去的东西心里真的很没底!
sogo_226:j_vicky 说的好,以上才是国内大多数公司普遍存在的问题,如何把这些问题解决掉更值得推敲。
j_vicky:这些方法几乎在测试改进的文章中都能看到。同其他的文章一样,没有针对目前国内公司的内部情况,提出具体的实施方案。在我看来以上的提出的方法没有多少实际意义。
1、对于小型的项目开发团队,同一个人会参与项目开发过程的多个或每个阶段,某个功能模块的需求、设计、编码和测试都是由一个人负责,试问这样的作坊式开发又怎能做到“BA和开发团队紧密协作”?
对于开发产品的大项目,编码阶段,B……
cqg1220:机柜
shixiaobing:不容易呢,居然找到你这里来了。。。。。
文章分类
收藏
相册
测试过程管理图(一)
test
存档
订阅我的博客
XML聚合  FeedSky
订阅到鲜果
订阅到Google
订阅到抓虾
订阅到BlogLines
订阅到Yahoo
订阅到GouGou
订阅到飞鸽
订阅到Rojo
订阅到newsgator
订阅到netvibes

原创 RUP与XP的平衡之道收藏

新一篇: 微软EPG老大让秘书发给大家的邮件 | 旧一篇: 世界杯收看计划

RUP与XP的平衡之道

Author:SpiderMan(ShenZhen)
From
http://blog.csdn.net/testwin
Emailtestwin@sohu.com

 

    人有过什么经验,遇到过什么恐惧的事,就会形成设法避免这种事情的方法学。研究重型方法学的人可能一直以来的经验就是组织上千人的开发队伍进行开发,比如说大型电信系统的开发、军事航天系统的开发......这种项目严格强调过程执行的规范,注重文档规范、评审及过程度量。而发明XP的人可能一直是在小团队里做项目,项目团队只有3、5个人,项目总是会因为没有满足用户价值而被Cancel,开发公司也蒙受损失,因此注重与用户的交流、反馈,强调快速、灵活。

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

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

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

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

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

 

RUP最佳实践包括:

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

 

12 个 XP 实践包括:

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

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

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

 

参考文献:

《在小型项目中使用RUP: 极限编程剖析》Gary Pollice

发表于 @ 2006年06月22日 22:41:00|评论(loading...)|编辑

新一篇: 微软EPG老大让秘书发给大家的邮件 | 旧一篇: 世界杯收看计划

评论

#路人甲 发表于2006-06-23 16:36:00  IP: 218.249.71.*
看了您的文章,我有些想法,想和您交流一下。RUP也好,XP也罢,其实我都不懂,只是有些皮毛。我觉得二者还是有些共性的:1。都强调迭代开发,不断的产生出一个可以让客户评价的版本,及时的修正。
2。尽量降低代码重复率,从而更有效的维护代码,降低出错的可能性。
3。强调测试环节。

这两个理论的区别就是,RUP更像是大公司的产品,理论化、系统化,和CMM一样,一切事情落实到纸上。XP像是小公司的产品,以人(客户和程序员)为核心,多数事情是嘴上的。

不知道我的理解是否正确,希望能您讨论一下。
#疯子阿虹 发表于2006-06-23 17:26:00  IP: 219.142.252.*
楼上的说得不对,
楼主的我也不敢苟同。

RUP与XP的融合,是各自特点的相互补充,
我觉得RUP和XP之间的设计理念相差很大,XP讲求源代码就是设计,最快速的交付软件,大量的沟通。

而这些在RUP中都被严格的系统化,包括设计文档,交付周期,和专业的沟通人员,测试人员。

另外,RUP注重产品,XP注重团队。
太多的不一样充斥着这两种设计理念之间,从哪里融合呢???

而且,
从任何方面来看,RUP的确比XP正式,但并不意味着它就更适合大型项目。RUP会带来重复性以及复杂性。

具体怎么说,看看kent beck的文章吧:)
#SpiderMan 发表于2006-06-23 18:18:00  IP: 219.133.51.*
首先RUP是一个比较灵活的框架,使用RUP带来的复杂性问题本身就是一个实际应用层面的问题。

RUP提供的迭代开发的方式本身就是具有灵活性的,只不过RUP的灵活是建立在一种显性的规范之上的、被动变化的灵活策略,主体还是依据前期的计划、分析、建模设计,因此会有类似较多评审之类的活动。

而敏捷方法更多的是一种自适应的灵活,是以一种主动的方式拥抱变化,它的很多实践 比如:Daily Meet、Daily Build、持续集成等等原则上也是一种主动的尽早发现、解决问题和风险,而这与RUP是并不冲突的。

可以说 在总体上可以依据RUP的框架 进行阶段的控制、把握总体迭代、规范过程,具体的迭代过程中可以引入敏捷实践保证开发的快速、灵活,并提高团队的主动性。
#木匠 发表于2006-07-02 14:01:00  IP: 202.116.76.*
把RUP比作大象,XP比作猴子是很确切的
发表评论  


登录
Csdn Blog version 3.1a
Copyright © TestWin