1,268
社区成员
发帖
与我相关
我的任务
分享XP vs RUP
1.在XP的体系中，版本计划和迭代计划是以用户故事的优先级排序的，而在RUP中，迭代是以风险排序的，似乎XP的方法更加合理，因为一个优先级别很低的需求可能具有很高的风险，对于这样的风险是不值得花费很多资源去解决的。
2.XP的测试先行是有道理的，单元测试代码的编写看似浪费时间，其实并非如此：测试代码起到了详细设计的作用，它规定了模块的契约，提供了可回归的自动化测试手段，这也是进行代码重构的基础，而重构是XP中以代码代替详细设计的手段之一，只有拥有描述了代码契约关系的测试代码，才能保证重构后的结果是与预期一致的，否则重构是很危险的，尤其是对别人的代码进行重构的时候。RUP中是传统的编码-测试过程，但是在其中并没有确定详细设计的方法和程度，在缺少详细设计的情况下，先编码后进行单元测试是错误的，因为这时你的测试用例是根据代码制定的，这样是没有意义的。
3.XP中涉及了任务分配的具体方法：由开发人员自己估算、自己选择任务，这是很好的方法。而RUP中没有具体描述任务如何分派。
4.在XP中现场客户是非常重要的，他可以避免开发人员对需求无谓的争论和猜测，同时对需求的排序是由他负责的，而在RUP中这个工作是由架构设计师负责的，这是由于RUP更加重视架构的概念造成的。
5.XP中指出代码是集体所有的，任何人都拥有所有代码，并列举出种种好处，但是这种做法的可操作性不高，需要开发人员具有高度的责任感和主动性，这是一种理想情况，实际工作中，如果操作不善，很可能会带来很多麻烦。
6.关于XP中的结对编程，同样存在可操作性的问题，首先这样需要会造成资源的浪费，另外如何保证那个不操作键盘的程序员进入状态也是个问题。
7.RUP和XP都是用例驱动的迭代式开发，但二者在对架构的重视方面有所不同，RUP中架构是非常重要的，而在XP中没有明确的架构的概念，隐喻是个类似的概念，但二者并不完全相同，隐喻更象是领域对象的集合以及关于它们如何交互的一个描述，而不完全是架构的概念，在这点上RUP似乎更加周密一些。
总之，虽然印象中RUP是庞大的，而XP是敏捷的，但其实二者是有很多相似之处的，完全可以将其结合起来形成适合于自己的软件开发过程。
以上是抛砖引玉，欢迎各位同行探讨。
2.XP的测试先行是有道理的，单元测试代码的编写看似浪费时间，其实并非如此：测试代码起到了详细设计的作用，它规定了模块的契约，提供了可回归的自动化测试手段，这也是进行代码重构的基础，而重构是XP中以代码代替详细设计的手段之一，只有拥有描述了代码契约关系的测试代码，才能保证重构后的结果是与预期一致的，否则重构是很危险的，尤其是对别人的代码进行重构的时候。RUP中是传统的编码-测试过程，但是在其中并没有确定详细设计的方法和程度，在缺少详细设计的情况下，先编码后进行单元测试是错误的，因为这时你的测试用例是根据代码制定的，这样是没有意义的。
3.XP中涉及了任务分配的具体方法：由开发人员自己估算、自己选择任务，这是很好的方法。而RUP中没有具体描述任务如何分派。
4.在XP中现场客户是非常重要的，他可以避免开发人员对需求无谓的争论和猜测，同时对需求的排序是由他负责的，而在RUP中这个工作是由架构设计师负责的，这是由于RUP更加重视架构的概念造成的。
5.XP中指出代码是集体所有的，任何人都拥有所有代码，并列举出种种好处，但是这种做法的可操作性不高，需要开发人员具有高度的责任感和主动性，这是一种理想情况，实际工作中，如果操作不善，很可能会带来很多麻烦。
6.关于XP中的结对编程，同样存在可操作性的问题，首先这样需要会造成资源的浪费，另外如何保证那个不操作键盘的程序员进入状态也是个问题。
7.RUP和XP都是用例驱动的迭代式开发，但二者在对架构的重视方面有所不同，RUP中架构是非常重要的，而在XP中没有明确的架构的概念，隐喻是个类似的概念，但二者并不完全相同，隐喻更象是领域对象的集合以及关于它们如何交互的一个描述，而不完全是架构的概念，在这点上RUP似乎更加周密一些。
总之，虽然印象中RUP是庞大的，而XP是敏捷的，但其实二者是有很多相似之处的，完全可以将其结合起来形成适合于自己的软件开发过程。
以上是抛砖引玉，欢迎各位同行探讨。
...全文
请发表友善的回复…
发表回复
mach 2003-04-22
- 打赏
- 举报
to lynxliu(lynx)
说的有道理。
说的有道理。
lynxliu 2003-04-22
- 打赏
- 举报
其实，每一个开发组织都有自己的开发方法，达到自己的目的，让客户满意掏钱。我觉得我们无需过于追求什么过程，只要掌握了，适合了就不需要轻易的改变，每一个过程其实都包含了自我调整和改进的部分在里面，一成不变的反复的过程并不存在。（这也是我喜欢CMM的原因）。initora(学习数学,准备考研) 一点感想就归结为整个的行业是不是健康，未免太过了，一个行业无所谓是否健康的。你说的情况，在软件公司存在的，老板的做法和你不一样的关键在于看问题的角度不同。他也许就是需要经常更换和使用廉价的程序员，那也是没有错的。程序员自己要学习，也是合理的。不存在什么道德，明智的问题。世界并不为着某个人而存在,我们不过是需要争取自己的利益。这里面还有长期利益和短期利益的不同，个人的情况不一样，都会有不同的看法。所以，道德约束基本无效，而且无端增加内耗，还是好好的和单位制定一份详细的合同，执行你的义务，得到你的利益的好。很多人不注意合同，只希望别人是好人，结果就会到处寻找所谓的问题的根源，看似居高临下的评论，却难以解决问题。还是好好的想好自己的责权利的好。另外，对于老板，你只要看着他是否履行了他的职责就好了，要记住在你成为企业的大股东以前，那个企业永远不是你的，最多你是一个司机而已。关注合同是核心，它让你知道自己要付出的有限责任和要的道的相应利益。最后，提醒一句，不要忽略自己的价值和作用，即使在一个跨国公司里面；也不要把自己看得太重要，即使面对的仅仅是你养的一只猫：）
hotay 2003-04-22
- 打赏
- 举报
小弟初学“叉P”，我觉的它对程序员的要求很高。关键是它的REFACTOR，在一般的开发过程中很少有人能把REFACTOR作的完美。
initora 2003-04-22
- 打赏
- 举报
to lynxliu(lynx) 有道理！
mach 2003-04-16
- 打赏
- 举报
其实国内很多软件开发企业，还谈不上什么RUP、XP，但是他们也有自己的开发方法和过程，比如手工作坊式的开发，虽然不正规，问题多多，但是多少也还是能用来勉强完成任务的。
如果不考虑自己的情况，为了实施XP/RUP而改变自己的过程，难免会邯郸学步，画虎类犬。
比较现实的办法是根据自己的具体情况，具体分析，找出当前最头疼的地方，有针对地使用一些业界经过验证的方法来进行改进，这个改进也是渐进的，要从最简单的任务开始实践，避免过快的改变带来的风险和由于改变失败带来的挫折和抵触。
如果不考虑自己的情况，为了实施XP/RUP而改变自己的过程，难免会邯郸学步，画虎类犬。
比较现实的办法是根据自己的具体情况，具体分析，找出当前最头疼的地方，有针对地使用一些业界经过验证的方法来进行改进，这个改进也是渐进的，要从最简单的任务开始实践，避免过快的改变带来的风险和由于改变失败带来的挫折和抵触。
initora 2003-04-11
- 打赏
- 举报
今天突然发现上面的话是白说了，细细地想，不是说对谁错，谁好谁坏的问题，而是整个环境，整个产业的不健康，算了，好好看看书，明眼！
initora 2003-04-07
- 打赏
- 举报
作为管理极其低下国内软件企业，引进CMM有它积极的意义，但过分的迷信就太可笑了，智能不等同于传统的manufucture，一样的管理方法带来的只会是损害。
进一步抨击rup的严格文档，在我看来，即便连framework这样重要的架构设计也只需在白板上画几个交互图，一般的技能低下的国内软件企业的设计师画上耗时巨多的未必全对一堆UML图放入管理库有多大的意义，积累错误？有必要吗－－我看他们自己都未必知道这些是错误模板，有这些投资，不如请个业界公认的导师顾问回来指导一两个项目。
进一步抨击rup的严格文档，在我看来，即便连framework这样重要的架构设计也只需在白板上画几个交互图，一般的技能低下的国内软件企业的设计师画上耗时巨多的未必全对一堆UML图放入管理库有多大的意义，积累错误？有必要吗－－我看他们自己都未必知道这些是错误模板，有这些投资，不如请个业界公认的导师顾问回来指导一两个项目。
initora 2003-04-07
- 打赏
- 举报
我上一个公司使用rup的方法，但我更喜欢XP，举个简单的例子：自上而下的RUP的架构师如果比较不开放，那designer、coder的家伙如何学习呢？不管用的哪种方法，talent是最重要的，不要指望拿2K的毕业生（指大部分水平）能和7～10K的经验丰富能写framework的程序员有同一水平，问题是，别人也渴望学习啊，一个idea能够复制无数份而转播，无数人的idea是多么丰富的知识库?为什么不组织起来呢？作为人事资源管理的公司，有没有一个责任来提供一个和谐的交流平台，这么多程序员流失了，到底是谁的损失？
我爱XP，我爱它的文化！
我爱XP，我爱它的文化！
hnzsy 2003-03-31
- 打赏
- 举报
本人认为分析设计阶段采用RUP，编码测试阶段采用XP。其实RUP并不比XP麻烦，关键是有相当一部分人没意识到RUP中工具的运用是很关键的，如果你大量采用手工的方式进行分析设计，你当然会感到累赘。
shenhao1123 2003-03-26
- 打赏
- 举报
同意楼上的观点，采用RUP，也必须做适当的裁减，应该以公司的实际情况出发
warrior 2003-03-25
- 打赏
- 举报
同意mach(照猫画虎）的观点。
不管是XP还是RUP，No silver bullet.
方法是用来实现目标的，不能本末倒置。
在分析用例时强调以用户的目的（goal)为导向，而不是某种实现的方法。在软件工程实践中也应该以实际需求为目的，寻求较好的方法。
RUP中提供了很多方法和设计文档的规范，不过并没有要求全部使用。
不管是XP还是RUP，No silver bullet.
方法是用来实现目标的，不能本末倒置。
在分析用例时强调以用户的目的（goal)为导向，而不是某种实现的方法。在软件工程实践中也应该以实际需求为目的，寻求较好的方法。
RUP中提供了很多方法和设计文档的规范，不过并没有要求全部使用。
mach 2003-03-21
- 打赏
- 举报
charles_hhb(mustang)
能否介绍一下你们实践XP的经验？
能否介绍一下你们实践XP的经验？
mach 2003-03-21
- 打赏
- 举报
》要自己建立一套自己的方法是好,但是会不会落入画虎不成反类犬的悲哀呢?
》在中国软件和其工程思想跟国外比是差远了
究竟什么样的过程和方法才是最有效的呢？其实不在于它的科学性和完备性，而在于是否已经被你的团队掌握或能被掌握，只有你真正掌握的方法才是有效的，因此说你正在使用的方法/过程就是最有效的（对你自己的团队来说），只不过可能需要对它进行改进。没错中国软件工程的思想的确不如国外那样有积淀，但是正因为如此，我们才不可能靠直接引进RUP等一口吃成个胖子，可行的办法是通过我们学习他们的先进思想，然后结合自己的实际，对现有过程和方法进行逐步改进。
》在中国软件和其工程思想跟国外比是差远了
究竟什么样的过程和方法才是最有效的呢？其实不在于它的科学性和完备性，而在于是否已经被你的团队掌握或能被掌握，只有你真正掌握的方法才是有效的，因此说你正在使用的方法/过程就是最有效的（对你自己的团队来说），只不过可能需要对它进行改进。没错中国软件工程的思想的确不如国外那样有积淀，但是正因为如此，我们才不可能靠直接引进RUP等一口吃成个胖子，可行的办法是通过我们学习他们的先进思想，然后结合自己的实际，对现有过程和方法进行逐步改进。
charles_hhb 2003-03-21
- 打赏
- 举报
>总之，虽然印象中RUP是庞大的，而XP是敏捷的，但其实二者是有很多相似之处的，完全可以>将其结合起来形成适合于自己的软件开发过程。
RUP也敏捷，RUP是被误用了才不敏捷（当然这是RUP的说法，hehehe ），毕竟agile比RUP要晚出,看看RUP如何敏捷
http://www.chinaxp.org/forum/viewThread.go?parentId=1047226337364&forum=1
RUP也敏捷，RUP是被误用了才不敏捷（当然这是RUP的说法，hehehe ），毕竟agile比RUP要晚出,看看RUP如何敏捷
http://www.chinaxp.org/forum/viewThread.go?parentId=1047226337364&forum=1
cchzf_02 2003-03-20
- 打赏
- 举报
studying
yestoall 2003-03-20
- 打赏
- 举报
搬张凳子来学习！
metalbreeze 2003-03-20
- 打赏
- 举报
xp是由下至上的
rup是由上至下的
但并不是xp不经过任何分析
rup做出合适的裁减才好,否则的话,会陷入泥
xp在国内是不是boss许可认同成对开发
rup在国内改变传统的管理方式,变成文档管理,公司是不是能完成这转折,
都是未知数,
要自己建立一套自己的方法是好,但是会不会落入画虎不成反类犬的悲哀呢?
在中国软件和其工程思想跟国外比是差远了
rup是由上至下的
但并不是xp不经过任何分析
rup做出合适的裁减才好,否则的话,会陷入泥
xp在国内是不是boss许可认同成对开发
rup在国内改变传统的管理方式,变成文档管理,公司是不是能完成这转折,
都是未知数,
要自己建立一套自己的方法是好,但是会不会落入画虎不成反类犬的悲哀呢?
在中国软件和其工程思想跟国外比是差远了
BluePenguin 2003-03-17
- 打赏
- 举报
关注
twinsant124 2003-03-17
- 打赏
- 举报
:)
tanzhen 2003-03-15
- 打赏
- 举报
我很同意你的说法：完全可以结合RUP和XP，来形成自己的软件过程。
XP对程序员的要求很高。对于架构设计，XP有它自己的一套东西。
我自己个人认为，在实践中，其实这个设计是由资深而有经验的程序员提出（毕竟目前已经有大量的架构和模式可供参考），通过隐喻的方式传达给大家，使大家达成共识，然后再通过不断的重构提高设计的质量或者修补缺陷。
另外，关于结对编程，我认为这是一种非常好的方法。最大的优点是能够加强团队建设、促进知识的交流和共享、并彼此监督XP方法的实施。当然，最大的问题就是可操作性。毕竟没个人都需要一些私有的空间（我需要收email，我需要上QQ），另外，并不是所有的程序员都有足够开放的精神乐意分享自己的心得经验。
因为我认为具体实践的时候，每个人都还是有自己的PC，有独自使用PC的时间；但是编程的时候必须两人同时进行。这要看leader如何组织了……
XP对程序员的要求很高。对于架构设计，XP有它自己的一套东西。
我自己个人认为，在实践中，其实这个设计是由资深而有经验的程序员提出（毕竟目前已经有大量的架构和模式可供参考），通过隐喻的方式传达给大家，使大家达成共识，然后再通过不断的重构提高设计的质量或者修补缺陷。
另外，关于结对编程，我认为这是一种非常好的方法。最大的优点是能够加强团队建设、促进知识的交流和共享、并彼此监督XP方法的实施。当然，最大的问题就是可操作性。毕竟没个人都需要一些私有的空间（我需要收email，我需要上QQ），另外，并不是所有的程序员都有足够开放的精神乐意分享自己的心得经验。
因为我认为具体实践的时候，每个人都还是有自己的PC，有独自使用PC的时间；但是编程的时候必须两人同时进行。这要看leader如何组织了……
加载更多回复（11）
