现在开发软件的人员说到开发流程，基本上都是rup\xp，xp没使用过，不敢说，这里说一说我对rup的使用经验。 根据我的使用经验（1.5 years），rup并不是一种强方法论，更多的是包括了大量的关于软件开发的流程和设计指南，没有谁会直接使用rup的流程，实际上只有理解好rup的活动思想，自己剪裁、组织合适的流程，才可能使用比较有效，但这需要很长的学习曲线和昂贵的学习费用（包括OOAD/RUP，不是一个人而是一个团队），当然自学也是没有问题，如果本身有很多软件开发的经验。 所有我同Rational的人交谈的时候说，虽然RUP号称适合于小项目，但那是在忽略了学习周期和成本的前提下，也就是说，如果你的团队或组长很熟悉RUP，那么它当然适合小项目（可以有效地剪裁并向成员培训），否则在实际的项目中使用就要小心了。但无论怎样，都可以把它看作关于OOAD的设计指南和流程的一般性建议，就像XP的很多原则也可以适合于其它环境，不过话又说回来，软件开发经验的本来就是怎样，不一定非要属于某种方法。 关于软件流程和CMM 过去我觉得正规的软件企业应当有一套完整的开发过程，现在我更倾向于认为软件开发的最佳实践对项目更有价值，包括开发方法、管理的，如有效的计划、需求方法、同行评审、团队的面向对象的经验。主要我觉得国内软件企业不太可能建立真正有效的角色清晰的资源结构和成熟有效的过程框架，国内软件企业热衷于CMM而不太关注于其具体效果（我参与了我们公司CMM3的评估，评估小组成员）；关注于纸质的规范，而不关注约定对质量的提高；盲目追求一套流程，而忽视流程是否真正有用。 作了这么长时间的过程改进和软件开发，我觉得对于国内的企业来说，xp或者其它最佳实践方法更容易给开发团队带来实际的价值，因为这些由一线经理和开发人员参与和实践，CMM不过是高层管理的招牌，他们大部分人实际上不懂软件开发，或者没有参与/不愿参与完整的软件开发过程，谁又会期望他们给开发团队带来的是开发的利器。
http://www.iconixsw.com/方法比较适合小型项目。这是一套基于RUP的方法，侧重于分析设计，弱于复杂的分工和组织。
臭帖评价：