| 作者 |
内容 |
| sunrise518 |
 那位大侠公司在使用RUP或者XP，效果如何？
Rational Unified Process详细的讲解了软件开发过程中的阶段、工作流、角色，可是如何在一个软件能力不太成熟的公司，真正实施下去，我看很难。不知各位又何高见？倒是在RUP的思路之下，应用XP(eXtreme
Programming)的一些原则，还比较现实。 |
| 02/04/01 12:35 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
 实施RUP主要看你理解了多少，理解的越多，使用的灵活性就越大。
其实RUP不是很死板的东西，在具体实施的时候，首先要理解整个流程，再根据自己的实际情况做裁剪，切忌一窝蜂全部使用，先使用一小部分，再逐步的完善，当然这个过程需要一定的培训和成员的认同，最好有一个领军人物指导完成。
我们现在的策略就是从小做起，已经实施了一部分，效果还是不错的哟！ |
| 02/04/01 14:23 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
 回复:
那位大侠公司在使用RUP或者XP，效果如何？
不然，XP比RUP掌握起来更难，因为所能得到的都是“原则”、“价值体系”之类的东西。这类东西需要参与者的水平较高。现在的项目团队，哪找这种人去？ |
| 02/04/01 14:58 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
 不对，不对！
|
| 02/04/01 15:01 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
回复:
那位大侠公司在使用RUP或者XP，效果如何？
其实RUP更好把握一些，关键的是要学会“化繁为简”的方法：
(1)在时间轴上安排好开发流程和活动(迭代和增量式)。
(2)在流程中安排好角色。
(3)计划每一流程中的要产出的artifacts。
(4)注意复审。
(5)考虑增加一些软件工程的“best pratices"
That's OK! |
| 02/04/01 15:05 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
回复:
不对，不对！
您到是讲出道理来啊？ |
| 02/04/01 15:07 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
 考虑，考虑？
理论上是没什么错，实际中会有很多问题，当项目组有5人时可能看不出来，当有10人时，就会发现？？？，当有再多人时就感觉一头雾水。
举个简单的例子，项目中的角色很多，当项目组中的成员较多时，他们之间的关系如何协调呢？如：项目中有分析员、美工、网页制作、程序员，他们在协同工作的过程中，怎么做才能使他们尽量可以并行工作，而不至于互相等待浪费资源呢？
项目组成员多起来的时候，你的artifacts怎样管理才有效呢？是写出来就完了吗，怎么迭代呢？版本怎么控制呢？怎么并行工作呢？
又怎么进行复审呢？检查一下就完了吗？
考虑，考虑？ |
| 02/04/01 15:24 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
这时项目经理该出场了
项目经理在其中起到关键的作用。在第一次迭代开始时，他将安排一个细致的迭代计划，细致到每一个角色的活动的日程安排。然后开始下达任务。在各位成员完成各自的任务时，进行日程的追踪和协调。迭代结束时，进行复审，总结经验，做下一个迭代的迭代计划。就这样一个迭代一个迭代做下去。。。。。 |
| 02/04/01 15:33 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
道理很简单！
无论是XP、RUP还是其他的一些什么方法，不要把他们看得是彼此孤立的，XP中的一些原则你可以在RUP中用，而RUP中的很多东西你也可以用在XP的实施过程中。
举个简单的例子：
XP提倡要经常的进行集成，在RUP中根据规模你也可以经常做，只是XP中没有明确的说你要用什么工具进行集成，而在RUP中你可以明确的看到可以使用CLEARCASE进行这些工作。
在XP中提倡要经常跟客户进行交流，要按客户的优先级做，在RUP中其实也包含这些东西，只是RUP明确的告诉你可以使用REQUISITEPRO进行管理，可以定义优先级等等，而XP没有。
这些东西都告诉我们在很多方面，他们的核心思想是一致的，只是根据自己的具体情况可以做裁剪，使用不同的工具。所以等你真正理解，并且真正在实际中使用过之后你会发现，所有这些东西的本质是一样的。
不知对否？ |
| 02/04/01 15:40 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
不是这么简单的！
这里牵涉到很多管理和技术的问题，不是单单的“细致到每一个角色的活动的日程安排”就可以解决的，当你安排的很细、很好的时候，用户的要求做了一些调整，你会又重新的做一遍细致的安排吗？迭代周期的划分也要好好考虑哟，多长时间，如何执行，风险怎样，资源怎样利用？
哥们，这个可不容易哟！ |
| 02/04/01 15:52 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| sunrise518 |
 流程、角色分配好了，这个过程中如何充分利用人力资源呢？
如何让每个人都充分利用自己的工作时间，当然一个人可以有多个角色。我的意思是讲，从项目的效益来看，如何降低人力资源成本呢？ |
| 02/04/01 16:31 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
回复:
不是这么简单的！
哥们儿，事情总是从可控制的方面做起的。对于我们所选用的流程模式也是如此。如果我们所选用的东西不是我们可控制的，那么我们注定是要失败的。所以，我们要从可控制的方式出发。我们承认唯一不变的就是变化，所以我们以可控的方式恰当地选择迭代时间的长度。在该迭代期内，我们假定我们要解决的问题是平稳的。这样，当迭代期结束时，我们才考虑在下一个迭代期引入变化。
复杂的东西总是可以分解为简单的东西加以解决。新型的软件开发的生命周期模型正是发挥这样的作用：把复杂的东西分解到各个迭代期内去解决，由简单做起，不断精化，引入变化，不断升华，最终接近用户想要的样子。 |
| 02/04/01 16:49 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
回复:
流程、角色分配好了，这个过程中如何充分利用人力资源呢？
项目经理事先就该对项目有一个“预测”。这个“预测”事实上放在了项目的先启阶段(一个典型的迭代周期)来做。项目经理将通过一个迭代期的工作，来考察项目的一些关键点：项目的目标是什么、风险是什么、工作量大概有多大、计划该如何安排、资源该如何配置。。。。等等。这个期间可以先投入项目经理认为合适的两三个人(分析员级别)，以协助其工作。待这些工作搞定了，你的问题才算是搞定了。这时需要有一个“软件开发计划”把这些问题规范下来。项目经理可据此与老板就时间问题、资源问题等开始计价还价了。 |
| 02/04/01 16:56 |
酷帖！ 臭帖！ 回复 |
酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
真正做过了吗？实际效果怎么样呢？
|
| 02/04/01 17:01 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
回复:
道理很简单！
是啊， 我们可以互相借鉴，取长补短。
然而，就可操作性而言，我们在工作中可是不能简单停留在“原则”、“规则”、“原理”。。。。上面，我们还需要可以拿来就用的东西。例如“模板”、“指南”等等。这在XP是很难的。
当然，对于没有用UML来建模的公司，如果采用RUP就会显得不伦不类。不过，我想，现在不建模的公司可能会越来越少了吧？ |
| 02/04/01 17:03 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
回复:
真正做过了吗？实际效果怎么样呢？
效果真的不错!只要能够学会“由简入繁”这一绝招。 |
| 02/04/01 17:05 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
 但愿如此！希望国内有更多的人能“真正”进入到RUP中去。
|
| 02/04/01 17:16 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
不一定的哟，很多东西都可以自己定制。不使用UML也可以套用RUP的，关键在于是否真正理解。
|
| 02/04/01 17:24 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
大虾说得极是。
|
| 02/04/01 17:28 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
 大虾说得极是。
|
| 02/04/01 17:30 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
