RUP中的剪刀手

作者：江南白衣，最終版本見：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。