作者：江南白衣，最终版本见：http://blog.csdn.net/calvinxiu/archive/2007/03/19/1533825.aspx，转载请保留。--- last update 2007.4.14

    剪裁，在RUP里和迭代一样，都是属于喋喋不休了一百遍的东西，但攻击RUP笨重的人总是习惯性的直接无视。

    其实在《The Rational Unified Process Made Easy - A Practitioner's Guide--Rational 统一过程实践者指南》里有一个极致的，一人一星期完成的超小型项目RUP过程示例，描述了创世的5天里,最关键的活动与工件。

    我们的头，在初始阶段拜完二哥、切完烧猪后，就会召集核心办事人来作一次过程定义。大家根据项目情况，从RUP的过程集、工件集中抽取出最简单的、刚好够用的部分，在如何做这件事，产出什么工件，工件的格式内容取得共识，记成一份Development Case，再以此来制订项目的总计划和第一次迭代计划，比以前拍脑袋的WBS好了很多。

    RUP里的剪刀手学名叫Process Engineer，在RUP 7.0的文档中(从IBM下载Rational Method Composer 7.0的试用版)，列在Production & Support的RoleSet里面(在RUP2003列在Manager里)。他只作一件事情，就是Tailor the Development Process for the Project，属于环境Disicipline，产出Development Process工件。

    RUP建议一切的中间工件都不要太正式，能简就简。在剪裁时，最重要的参考源是每个Discipline下的Important Decisions Guideline，如《Important Decisions in Requirements 》、《Important Decisions in Analysis & Design》 ....还有《Classifying Work Products》表明了哪些是RUP最根本的，只建议化简不建议取消的工件。另外，每个工件的Tailoring部分给出了工件内容的剪裁建议。

    Development Process可以有很多定义方式比如Rational Method Composer，但简单的用word文档也就够了，Development Case文档的template连example共三种样式。
    普通情况下，建议以Disicipline为纲，每个Disicipline用一个表格指明了有哪些工件、活动和制作工件的模版和指南(这些模版和指南通常是Project-Specific的)。  但如果结构性的大剪裁，剪得太厉害了，直接以阶段为纲来表达活动和工件，比如我们在再工程过程就剪得很厉害。

    在大剪特剪的时候发现RUP的方法定义框架本身就是一个好东西，除了XP这种极端的兵无常势只有最佳实践没有过程定义的之外，其他的过程如果不止于方法论与最佳实践，还想有一个完整的开发生命周期定义的话，众多大师就开始头痛如何去表述自己的过程了。而  "Unified Method Architecture" (UMA)的元模型就是一个完备而明确的过程定义框架，你可以很省事的使用它的表述模式来定义自己的过程。

    RUP7.0 自己已经分开了Large Project 和 Small Project 两个部分，另外Scott. Ambler的Agile UP也值得参考：http://www.ambysoft.com/unifiedprocess/agileUP.html。

发表于 @ 2007年03月19日 15:58:00|评论(loading...)|编辑