l????????
Develop Iteratively
l????????
Manage Requirement
l????????
Use Component Architectures
l????????
Model Visually(UML)
l????????
Continuously Verify Quality
l????????
Manage Change
做為
RUP
工具和過程的基礎，
best practices
的影響了業界至少有十年。但是，時過境遷，如今，軟件開發已經成為一個關鍵的業務能力或者說是商業能力。因此也就越發的強調
business-driven development
。在這樣的背景下，發布不久的
RUP7.0
當中對于
best practices
進行了重新闡述，代之以
key principles
，這樣來適應日益發展的系統和軟件開發。
那么讓我們來看看
key principles
都有哪些：
l????????
Adapt The Process
l????????
Balance Competing Stakeholder Priorities
l????????
Collaborate Across Teams
l????????
Demonstrate Value Iteratively
l????????
Elevate Level Of Abstraction
l????????
Focus Continuously On Quality
那么每一項key principles都是什么含意呢？
Adapt The Process
：
項目應該有適當的過程，太大的過程和過于簡化的過程都是不好的。要根據項目的活動、控制程度、大小、所處于的階段、團隊的分布等等一系列因素來進行過程剪裁以便采用合適的過程。
過多的過程有的時候并不是好事情，需要因地制宜，因為它意味著更多的文檔、要同步更多的模型、更多正式的評審等等；對于一些小型的項目組，成員對技術非常熟悉，人員少而且都坐在一起工作，這時候往往考慮使用輕量化的過程，比如比較流行的敏捷過程。當然隨著項目逐步增大，對于過程的紀律性要求也會逐步升高。另外，過程需要被持續的改進，并且還需要根據未知項的級別和多少來平衡計劃與估計。
Balance Competing Stakeholder Priorities
：
我沒有查到這個key principle的本源，不知平衡利益相關方的優先級是否也從咱們中國文化中的平衡哲學中（陰陽）有所借鑒。在項目中我們常常見到的就是業務需要與各個相關方可能發生的沖突，以及客戶化的開發與軟件資產復用所產生的矛盾。
另外，還需要不斷的更新優先級列表，因為隨著對項目理解的深入，這是一個動態的過程。
因此，要做好這個法則，進行有效的需求管理是基礎。真正做好需求分析和管理才可以有效的識別和排列各個需求的優先級，平衡好業務和客戶的需求。對于開發來講就要有一定的技術內功作為基礎，具有一定的架構和封裝能力，管理好已有的軟件資產，并充分了解其商業價值，以便在恰當的時間和地方進行復用，既照顧了客戶需求又復用了已有資產降低了成本。
Collaborate Across Teams
：
這個法則主要是強調整個項目范圍內的溝通、協作，要通過恰當的團隊組織以及有效的合作大環境建立而產生協作的土壤。最終形成有戰斗力的團隊。
要實現良好的團隊協作，需要激發團隊成員的斗志，讓大家都表現出自己的最佳狀態。要建立起一個能夠“自管理”的團隊，要鼓勵團隊成員跨職責的協作；當然，要有一個有效的協作環境作為基礎（比如工具平臺、通訊平臺、組織氛圍），通過對工件和任務進行管理來加強協作、過程和質量。另外，不要忘記根本，項目是需要盈利的，這就需要將商業團隊、軟件團隊、和執行團隊進行有機的集成。
Demonstrate Value Iteratively
：
迭代仍然是一個關鍵問題，軟件開發需要采用迭代的過程來更好的適應變更、得到反饋、加入新的條件、更早的降低風險并動態的調整所采用的軟件過程。
迭代是一個老生常談的問題，關鍵的不是形式而是內容，好的迭代需要明確進入和結束準則，應該增量的實現用戶價值，并實時的收集反饋，根據項目各方的動態狀況作出調整。那種僅僅將項目從形式上劃分成幾個階段或者release的方式其實只是加入了檢查點（checkpoint），并不是真正意義上的迭代。
Elevate Level Of Abstraction
：
提升抽象層次。如果說是技術的發展使我們提升了抽象層次，到不如說是復雜度的增加迫使我們不得不發展技術來提升抽象層次，以便解決復雜的開發設計問題。現在軟件項目的復雜度越來越要求我們在早期能夠形成一個穩定的架構，以之成為應對變更、復用、甚至是減少文檔化工作的基礎。一個好的架構必須是有彈性的、高質量的、易懂的、并且是復雜度可控的。另外一點就是一個架構應該在早期進行測試，而不是在實現后才去驗證。
我們可以回首看看中間件、SOA等的發展，無不是在抽象層次上做了大量文章。對了，還有大家廣泛使用的UML，例子舉不勝舉。
Focus Continuously On Quality
：
這一條非常像best practices里面的Continuously Verify Quality。作為迭代的軟件過程來說，它可以提供更多的機會來度量和驗證。
質量的保證是需要從兩個方面努力，一個是過程質量，這就需要建立一個良好的，適用的過程；另一個是軟件過程產物質量，這就需要盡早的持續的進行集成和測試。
posted on 2007-08-30 16:36
Robin's Programming World 閱讀(956)
評論(0) 編輯 收藏 所屬分類:
轉載