2023年06月22日 22:41:00
rup與xp的平衡之道
人有過什麼經驗，遇到過什麼恐懼的事，就會形成設法避免這種事情的方法學。研究重型方法學的人可能一直以來的經驗就是組織上千人的開發隊伍進行開發，比如說大型電信系統的開發、軍事航天系統的開發......這種專案嚴格強調過程執行的規範，注重文件規範、評審及過程度量。而發明xp的人可能一直是在小團隊裡做專案，專案團隊只有3、5個人，專案總是會因為沒有滿足使用者價值而被cancel，開發公司也蒙受損失，因此注重與使用者的交流、反饋，強調快速、靈活。
每種軟體方法產生的背景不同、特點不同、適用的領域亦不相同。那麼對於軟體專案來說，是否可以使用同一種軟體開發方法來對不同型別、規模、複雜度的專案來進行開發呢，顯然是不合理的。
前不久，恰巧和國內一位資深的軟體工程諮詢顧問做過一些交流，他本人熱衷於rup的過程改進，倡導針對不同型別專案進行適當的裁剪，實際上這也是一種靈活適應的方式、隨需而變的思想。我對此是理解並贊同的，但是我對rup卻一直保持一種相對謹慎的態度。
對於rup來說，首先，我認為它過於理想化和理論化，rup 是過程元件、方法以及技術的框架，你可以將其應用於任何特定的軟體專案，由使用者自己限定 rup 的使用範圍。對於各種型別的軟體專案，rup並未給出具體的自身裁減及實施策略，總有些無依據可循的感覺。你既可以說它能解決任何問題，也可以說它什麼都不是；其次，rup從本質來說還是乙個強調設計和規範的軟體方法，從這個角度來講，與傳統的瀑布模型沒有太大差別，它的靈活性較之敏捷方法還是相對較弱的。在一些小型軟體專案、特別是不可**的軟體專案開發中，面臨著各種緊急需求、面臨著時間壓力，沿用rup是很難應付自如的。但是在另一方面，rup強調對知識的收集、整理和加工定義，強調在軟體開發的時候要有好的體系結構。所以它還是很有利於知識的積累和共享的。
相比rup ，敏捷方法如xp則更為靈活，倡導盡早的、持續的交付有價值的軟體滿足使用者需要。用交流溝通取代詳盡的文件，強調團隊的主動、自律、自我組織和自發管理。而xp也是以**為核心的一種方法，這裡有很多的東西是未知的，知識只存在於兩個地方：開發者的頭腦和最後的**。對於專案管理者來說，他們會認為敏捷開發方法弱化了知識管理的概念，而實際上敏捷開發注重的是最有價值的知識的積累和沉澱。
如何靈活應對各種專案風險、如何最大化優先滿足使用者價值、又如何能夠有效的控制專案開發過程、如果做好專案過程中的知識管理，是每乙個軟體專案管理者都需要深入思考的問題。rup的倡導者一直強調rup裁剪，實際上我認為rup不僅僅是需要自身的裁剪，還需要學會融合。在rup裁剪的同時，適宜的融合敏捷開發的各種實踐。不要認為rup與xp是矛盾的，其實不然，它們具有不同的原理、具有不同的應用領域。在 rup 中融合了 xp 技術時，才會得到過程的正確量，既滿足了專案所有成員的需要，又解決了所有主要的專案風險問題。對於乙個工作於高信任環境中的小型專案團隊，其中使用者是團隊的一部分，那麼 xp 完全可以勝任。對於團隊越來越分散，**量越來越大，或者構架沒有很好定義的情況，您需要做一些其他工作。在使用者互動具有"契約"風格的專案中，僅有 xp 是不夠的。rup 是乙個框架，可以從 rup 出發，在必要時以一組更健壯的技術來擴充套件 xp。
rup最佳實踐包括：
1． 迭代開發
2． 管理需求
3． 使用基於元件的構架
4． 可視建模
5． 持續的質量驗證
6． 控制變更
12 個 xp 實踐包括：
有計畫的開發：通過結合使用優先順序"故事"和技術估算，確定下一版本的功能
小版本：以小的增量版本經常向客戶發布軟體
隱喻：隱喻是乙個簡單、共享的"故事"或描述，說明系統如何工作
簡單設計：通過保持**簡單從而保證設計簡單。不斷的在**中尋找複雜點並且立刻進行移除
測試驅動開發：使用者編寫測試內容以對"故事"進行測試。程式設計師編寫測試內容來發現**中的任何問題。在編寫**前先編寫測試內容
重構：這是一項簡化技術，用來移除**中的重複內容和複雜之處
結對程式設計：團隊中的兩個成員使用同一臺計算機開發所有的**。乙個人編寫**或者驅動，另乙個人同時審查**的正確性和可理解性
集體**所有權：任何人都擁有所有的**。這就意味這每個人都可以在任何時候變更任何**
持續整合：每天多次建立和整合系統，只要任何實現任務完成就要進行
每週 40 個小時：程式設計師在疲勞時無法保證最高效率。連續兩周加班是絕對不允許的
現場客戶：一名真實的客戶全時工作於開發環境中，幫助定義系統、編寫測試內容並回答問題
編碼標準：程式設計師採用一致的編碼標準證
rup與xp的融合，是各自特點的相互補充，也是軟體開發方法的平衡之道。而對軟體技術平衡的思考也可以說是技術成熟的開始吧。
最後，再闡明我對軟體專案開發的理解。在軟體專案開發過程中，應該能夠識別、分析不同軟體專案的特點，採用相對適合的開發實踐來適應軟體開發過程，保證對軟體開發的有效支援，以便能夠創造出"足夠好的"軟體。而這個足夠就是對 進度、成本、質量之間的平衡，最大化滿足客戶需要的實現。
《在小型專案中使用rup: 極限程式設計剖析》gary pollice
方法學之RUP與XP
一般我們可以採用rup的方式來進行開發，即從需求，到分析，到設計，到實現，到測試，rup從最容易理解的需求開始，然後通過需求匯出設計，由設計指導實現 因此，在使用rup時，最困難的步驟是需求，只有需求分析清楚了，後面的設計和實現就自然的水到渠成。但是rup的乙個缺點是需求要相對固定，因為需求的改變會...
伊萬，關於XP和RUP的論述
xp 的方法是以 為核心的一種方法，而且這種方法裡更多的是不管你腦袋裡有什麼東西就去實用它，更多的這種方法是不加定義的，而且很多的東西是未知的一種方法，那麼，只要有這種想法就去使用它。但是 rup是一種統一的方法，這種方法更多的是有知識的收集 知識的表現和知識的定義過程。只有經過這個過程，知識才是可...
RUP概述與實際應用的例子
了解rup的人都知道，rup主要是強調軟體工程中的方法學。也就具體用什麼樣的方法 生命週期，關注點 來實現乙個公司的產品開發的管理規範與有效。rup方法中強調的是用況驅動，以架構為中心，迭代開發的原理。一，用況驅動 也就盡量以用況來描述使用者的可描述需求。這樣一來可以更好理解使用者需求，二來使用者可...