MILY: 黑體; mso-ascii-font-family: Arial">導言反模式就是不做什么：有些行為、習慣或者方法似乎很有價值，但對于準備完成的事情來說卻沒有幫助。本文討論了多種RUP反模式，收集來自Black Diamond Software指導RUP使用者在各種不同大小，人員組成技術環境和工業項目中的經驗。本文討論了每一種反模式的本質，以及怎樣才能避免的措施。 反模式
1. 瀑布RUP “我們目前的迭代是需求，下一次迭代才是設計” 對那些一直遵循嚴格的瀑布開發過程的人們而言，瀑布RUP是最容易犯的錯誤之一。瀑布RUP是反模式的原因很簡單：它不能幫助降低風險程度，而降低風險是基本的RUP原則之一。RUP迭代式開發要求每次迭代應該是一個應用程序的“小型發布版”。每次迭代有小型的需求，設計，開發和測試環節，并且交出應用程序的一個可運行部分。使用這種方式，需求、設計、實施和測試的問題在每一次迭代中都得到“沖刷”，要求問題越早解決越好（問題越早解決其消耗的代價就越�。�。 如果瀑布階段沒有轉換成迭代，會怎樣呢？功能塊就會成為迭代，用例成為功能“片”的基礎。通常RUP表明了用例的優先性，同時也說明了內在的風險決定用例怎樣被劃分到迭代中。 2. 準備-設置-RUP “公司說每一個人都應該遵循RUP，所以讓我們開始吧” 決定采納RUP作為方法學通常源于高層領導。CIO、CTO或者其它的高層的技術領導決定所有新的項目必須遵循RUP。然后每一個部門決定怎樣將RUP應用到他們的項目中，于是他們購買該方法學，并且相信他們已經做好準備。第一個項目組在接受某些RUP培訓后熱火朝天的開始實施。他們盡可能的嚴格執行該方法學的要求，但是這好像有些難以容忍－RUP太龐大了以至于他們深陷在disciplines, artifacts, milestones之中而迷失了。如果項目的完成日期迫近，而他們仍然陷入方法學的泥潭中，他們就會絕望，就會退回到他們原來知道的但是不是RUP的方式來解決問題。這個項目組從前有很好的意圖，但是為了能夠在最后日期前完成任務，最終退回到他們原來了解的最好的方式。 RUP是一種相當大的方法，而且獨自解決它是項艱難的任務。對于已經適應不同于RUP方法學的組織，例如瀑布模型，第一個RUP項目是一個巨大的挑戰，超出典型的項目挑戰。當它被完全貫徹下來，你就會發現采納RUP的原因，才會發現RUP的功效，所以退回到原來的處理的方法是不能被接受的。 那下一步應該做什么呢？下一步要做的就是在整個組織范圍內貫徹RUP。盡力建立一個支持結構，目的是使項目組成員不要經常偏離他們努力的目標。你也許會發現你需要其他具有豐富RUP經驗人的幫助，這意味著招聘一個具有RUP背景的雇員或者有從外部獲取RUP幫助的渠道。其實你真正所需要的是決定怎樣將RUP應用到特定的項目中，和怎樣使用RUP的相關技術，例如用例開發等。有時一點指導會幫你少走很多彎路。 3. RUP－全部工具的總和 “我們擁有Rational的工具，所以我們已經做好開始的準備” 這是另一種“準備－設置－RUP”，是對工具的扭曲認識。在這種反模式里，項目組擁有RUP方法學和Rational的工具，他們已經準備好開始一個RUP的項目。問題是RUP不是所有工具的和。這些工具可以幫助方便實施RUP的很多活動，但是利用這些工具不能確保能夠有效的實施RUP。你知道準備應用的這些工具是做什么的嗎？你知道你怎樣做才能適合軟件開發過程嗎？舉一個例子，如果你使用Requisite ProTM來進行需求管理，那么你知道怎樣保證需求信息被整個項目組共享嗎？怎樣將Requisite ProTM正在收集的需求信息反饋給用戶呢？知道怎樣利用Rational工具是很重要的，但是理解這些工具所支持的活動以及這些活動之間的相關性也是必須的。簡單的說，實施RUP可能會驅使你使用這些工具，而不是因為有了工具而使用工具。 要熟悉RUP的理念。要思考這些理念與你以前熟悉的方法學的理念有什么相似和不同之處。要熟悉Rational Tool Mentor，這些指導為你使用Rational 工具來實施RUP提供很多寶貴建議。 4. IT是一座孤島 “IT遵循了RUP，這就足夠了，對嗎？” 你所在的IT組織已經決定使用RUP實施一些項目了。項目組的成員都接受RUP的培訓，而且擁有必需的工具，并且聘請了一位具有豐富RUP經驗的專家，所以現在準備實施了，對嗎？你是否考慮過IT外部因素對RUP實施的影響呢？RUP的每一步，系統需求都是利用用例來描述的，最好是根據直接用戶提供的資料得到的。但是你的用戶做好準備花費時間來建立和審查用例了嗎？他們知道什么是用例嗎？你的DBA曾經接受過RUP的培訓嗎？他們準備好用迭代的方法接受數據模型/表變化請求嗎？所以要讓所有相關的成員知道RUP是怎樣影響他們，知道RUP怎樣利于項目成功，是很重要的。 5. 我們什么時候開始編碼 “用例太耗費時間了，所以我們馬上編碼吧” 用例是花費時間的。的確。但通過不停的編碼，編碼，再編碼找到“隱藏”的需求的辦法就不花時間嗎？在開發中出現的需求問題的頻率又怎樣呢？雖然建立用例也不能確保所有的需求被覆蓋，也未必能滿足所有用戶的需求，但是使用這種方法比起“得到一點需求就進行編碼”要高效的多，因為畢竟這種方法是在開發前進行需求分析的，而在開發中調整需求的代價則是巨大的。 項目經理比開發人員更渴望結束用例并開始編碼，這并不奇怪。通常開發人員會說“現在已經擁有很多的信息了”，而此時項目經理則會檢查他的日程，關心是否能夠按時間完成項目。在建立完用例后，完成用戶業務目標的用戶/系統的迭代模式就存在了。這種用例模型除了可以作開發者的系統需求外，還可以是測試計劃和培訓材料的重要的輸入材料。 6. 什么時候完全做好呢？ “我們要在開始時為所有的迭代做一個項目評估并且堅持將評估貫穿整個項目” 有多少次你被要求對你的項目做大致正確的評估，假設這種有漏洞的評估是基于非常有限的信息并且可能在項目的進行中發生巨大的變化，然后無論他們是多么的不正確，這些評估總會被保留下來？保守地說，在某種程度上，我們大家都是如此。 RUP的目的是消滅這種做法，它要求項目要做初始的全局性評估，要求每個迭代應該在被執行前進行評估。開始當信息了解還比較少時，可以做一個“低分辨率”的項目評估，隨著項目信息的了解深入，它可以進行修改。從每一次迭代評估中得到的知識都被輸入到下一次迭代評估或者整體評估中。另外“時間盒”（time-boxing）可以用管理范圍。這種方法提倡在預算時間內對完不成的功能進行刪減或者延遲，而不是拖延預算的時間。 這種方法行得通嗎？答案是，這種方法只有公司高層領導和用戶都贊成RUP時才能實施，因為他們決定批準或者否決項目的預算、項目完成日期的延遲和項目的應用范圍的變動。我們再次強調“IT是孤島”反模式，外部因素對項目組的成功影響巨大。 7. 食譜RUP “RUP的規則在那里？我需要手把手的指導” RUP提供象食譜一樣的方法了嗎，“RUP食譜”中每一個烹飪法都對應一個不同的項目？答案是沒有。RUP只是提供了指導，并沒有需要遵循的固定不變的規則，因為任何一個項目都是不同的。特定的用戶群，以及與目前存在問題相關的項目組的核心能力都是動態的，甚至是項目成員物理位置的變化范圍都不是任何一本食譜能夠完全描述清楚的。所以根本就不可能存在這樣一本萬能的食譜。 那么你怎樣實施你的項目呢？第一步你需要花一些時間為你特定的項目定制RUP，下一步為你的項目建立開發案例。這個工件在初始階段建立，描述了怎樣定制RUP以滿足項目的具體需要。 8. RUP是萬能的 “我們遵循RUP，所以所有項目管理、團隊和組織的問題都會被解決” RUP為管理和實施項目提供了有價值的指導，但是它不是萬能的。它可以告訴怎樣才能成為高效的管理者、好的程序員、有用的團隊成員或者高效的組織。例如，RUP的項目管理向導可以根據RUP方法學解釋怎樣進行組織、計劃和實施一個項目，但是項目經理需要知道怎樣管理他們的職責，成員、完成日期等。RUP提供設計和構建的向導，但是程序員需要知道怎樣進行編程。對于已經采納RUP的組織需要知道怎樣整合和支持新的方法學。不是所有的組織、項目和團隊成員都具有這樣的能力。但是這并不意味RUP不能被采納，而是意味著需要面臨一個曲折痛苦的學習過程，或者說需要額外的幫助。 9. 過分的-強制的RUP “我們必須完美和徹底地建立所有的RUP工件” 這樣做的后果是你永遠不可能完成你的項目。 和很多其它的方法學一樣，RUP也包含很多的活動和工件，這些活動和工件在合理的時間范圍內不可能被完成。RUP并不是要求項目必須遵循它所定義的所有的活動和工件。實際上對于新項目，RUP最初的任務是建立開發案例－用于確定所有需要建立的工件。這里可以根據項目組織情況，技能水平等不同的因素確定哪些工件是重要的，例如當進行設計的時候，你需要創建序列圖，協作圖，類圖和狀態轉換圖嗎？也許沒必要。也許你在每一個用例開發中真正需要的是類圖和用來表示復雜邏輯的序列圖；也許你正在開發一個工作流項目，描述狀態轉換的信息就是很重要的，這時候你需要狀態轉換圖�？傊�，也就是說每一個項目都有自己側重的工件需求。 決定在某一科目（disciplines）中選擇或者排除哪些工件也許是很困難的。這里的關鍵是你要理解項目組織的需求，工件的閱讀對象和全面的項目任務；另外需要理解工件需要的、能夠作為迭代過程的因素。項目組在進行一次或者多次迭代后，需要考慮增加一些在初始階段認為并不重要但是現在看起來十分必需的工件。 另外，創建工件雖然有些苦頭但是并不是很困難的。每一個工件的細節層次以及信息數量都要和工件要解決的問題的復雜性相適應。例如，對一個需要花費2個月時間完成的項目，其業務用例不可能象企業范圍的項目那么全面－如SAP。 我們已經討論了一些RUP的反模式，在遵循RUP方法時試圖避免它們。我們已經討論了克服或避免產生這些反模式的做法。需要記住的是采用新方法需要時間，同時嘗試與出錯往往是學習的最佳途徑�？梢栽谝恍┎皇呛苤匾捻椖恐袑嵤�RUP，從中學習經驗并且將其與它人分享 |
文章來源于領測軟件測試網 http://www.kjueaiud.com/