業務驅動開發的關鍵原則

本文內容包括:

• 提高過程的適應性
• 平衡有競爭的涉眾優先級
• 跨團隊協作
• 迭代地證明價值
• 提高抽象層次
• 持續關注質量
• 總結

來自 Rational Edge：作為IBM Rational的六個最佳軟件開發實踐的主要更新，本文闡述了一組新的原則，可用來刻畫構建，部署和演化軟件密集系統的成熟方法。

　在線討論這一主題！在你讀完本文后，點擊這里訪問RUP論壇，在那里你可以提出問題和發表評論。

從1983年——現在的IBM Rational，那時叫做Rational軟件——組織成立起之時，我們關于各種軟件開發過程和技術的知識一直在增長——通過與客戶和合作伙伴的廣泛合作。多年來，他們中的很多人加入了我們的組織，并在我們學習哪些方法是有效的，哪些是無效的，以及為什么軟件開發始終是一個充滿挑戰性的工作的過程中，不斷塑造著我們對軟件開發實踐的理解。

正如我們的客戶，合作伙伴和雇員多次聽我們說到的那樣，軟件開發是一項團隊工作。理想化地，軟件開發活動涉及了良好協調的團隊在各種涵蓋了整個軟件生命周期的規則約束下的工作。但是它不是科學，也不是精確的工程——至少從基于事實的可計量原則的觀點看不是。那些假設你可以計劃并建立分離的軟件部分然后把它們組裝起來，就像你造橋或宇宙飛船那樣的軟件開發活動總是不能按時完成，不能在預算范圍內完成，也不能讓客戶滿意。

因此，在缺乏嚴密論據的情況下，Rational組織依賴于我們稱之為最佳實踐的軟件開發技術，這些技術的價值在我們為客戶進行的服務中反復得到了證實。它們描述了一個迭代的，遞增的，引導開發團隊實現結果的過程，而不是為一個軟件項目指示一個計劃-建立-組裝的活動序列。

十多年以來，我們的六個經檢驗正確的最佳實踐一直是我們的工具和過程改進的基礎。今天，我們有更多公司把軟件開發作為核心業務能力來進行研究，于是我們也就看到了這些最佳實踐在更廣泛的業務驅動開發的環境下的不斷成熟。我們認為現在需要對不斷演化的系統的更長生命周期（在這個周期中主要演化的元素是軟件）重新闡釋我們的最佳實踐了。

本文闡釋了一組原則，我們認為這些原則描述了構建，部署和改進軟件密集型系統的工業最佳實踐的特征：

• 提高過程的適應性。
• 平衡有競爭的涉眾的優先級。
• 跨團隊協作。
• 迭代地證明價值。
• 提高抽象層次。
• 持續關注質量。

我們將按順序解釋上述這些原則，描述最好地體現了每條原則的行為模式，以及最常見的對軟件開發項目造成破壞的“反面典型”。

提高過程的適應性

好處：生命周期的效率，開放或誠實的風險溝通

模式：隨著項目生命周期中不確定因素的消減，精確性和形式化程度不斷加深。使過程適應于項目團隊的規模和分布，適應應用的復雜性，以及靈活性需要。不斷改進你的過程。

反模式：精確地計劃或估計，遵循靜態計劃管理方式。過程越多越好。在整個生命周期中不分輕重地使用過程。

更多的過程，比如使用更多工件，產生更詳細的文檔，開發和維護更多需要進行同步的模型，進行更多形式化評論，并不一定有好處。實際上，你需要根據項目需要正確裁減過程的大小。隨著項目規模的不斷增長，分布范圍變得更廣，使用更復雜的技術，擁有更多數量的涉眾，需要遵循更嚴格的標準，過程也就需要更多地遵守原則。但是，對于小型的，團隊在同一地點工作的，使用廣為人知的技術的項目來說，過程應該是較為輕量級的。這些依賴關系如圖1所示。

第二，項目應當使過程適應整個生命周期的各個階段。在項目的開始，你有很多不確定因素，你希望有更多創造性來開發一種明確業務需求的應用程序。更多的過程往往導致較少的創造性，而不是更多，因此你應當在項目初始，不確定性是最常見因素之時使用較少的過程。另一方面，在項目后期，你往往想要引入更多控制，比如變更控制板，來消除不想要的創造性和相關風險，以免在晚期引入缺陷。這就意味著在項目晚期使用較多過程。

第三，一個組織應當努力地 不斷改進過程。在每次迭代和每個項目最后作一個評估來獲得學到的經驗，并把這些知識用于改進過程。鼓勵所有團隊成員不斷尋找改進的機會。

第四，在項目的不確定性和項目計劃以及相關估計中取得平衡。這意味著在項目的早期，不確定性很大的時候，計劃和相關的估計應集中于全景的計劃和估計，而不是著眼于在什么都沒有的情況下提供精確到五位的數據。早期開發活動的目標應是找出不確定性來逐漸在計劃中提高精確性。

圖1：驅動過程原則的數量因素很多因素，包括項目規模，團隊分布，技術復雜度，涉眾數量，靈活性需求，以及你在項目生命周期中所處的位置，指出了你需要何種規范程度的過程。

這一原則的反模式是永遠認為更多過程和更詳細的前景計劃是更好的。強制進行早期估計，并依賴于這些估計。

平衡有競爭的涉眾優先級

好處：使應用程序與業務和用戶需求連接起來，減小客戶開發，使業務價值最優

模式：定義并理解業務過程和用戶需求；區分項目，需求與軟件能力的優先次序；理解你可以使用哪些資產；并平衡用戶需求與資產復用。

反模式：在項目工作開始前實現精確和詳細的需求。需求是達到客戶解決方案的焦點。

這一原則闡述了平衡業務和涉眾需要的重要性，兩者往往是沖突的。作為例子，多數涉眾希望應用程序可以完全實現他們想要的功能，同時最小化應用程序的開發成本和時間表。但是這些優先權經常是沖突的。例如，如果你使用一個包裝好的應用程序，你可能能夠更快，并以更低的價格發布方案，但是你不得不犧牲很多需求。另一方面，如果一個公司決定從底層構建一個應用程序，它可能可以實現所有需求，但是預算和項目完成需要的時間將同時超過它們可行的極限。

我們要做的不是叫我們的程序設計團隊攻克需求清單中每一個元素；我們要做的第一件事是理解并排列業務和涉眾需要的優先次序。這意味著掌握業務過程并把它們同項目和軟件功能聯系起來，這使得我們能夠有效地排列出正確的項目和正確的需求，并隨著我們對應用程序和涉眾需要理解的深入修改我們的優先次序。優先級的排列還意味著我們需要在項目中加入客戶或客戶代表，來保證我們理解了他們的需要。

第二，我們需要圍繞涉眾需要開展開發活動。比如，通過利用用例開發和以用戶為中心的設計，我們可以接受這樣一個事實：隨著業務的變化，以及我們對哪些功能對業務和終端用戶更為重要的更好理解，在項目的持續過程中涉眾的需要會發生演化。我們的開發過程需要適應這些變化。

第三，我們需要理解哪些資產是可用的，然后平衡資產復用和涉眾需要。資產的例子包括繼承應用程序，服務，可復用組件，和模式。在很多情況下資產的復用導致更低的項目成本；而對經過驗證的資產，對它們的復用通常意味著新應用程序的更高質量。缺點是，在很多情況下，你需要犧牲資產復用而精確地實現終端用戶的需要。對一個具體功能，復用一個組件可以降低開發成本達80%，但是它可能只能實現75%的需求。因此，有效的復用需要你不斷地平衡資產復用和發展中的涉眾需要。

圖2：平衡需求處理組件的使用。使用一個組件可以從根本上降低成本和發布一組特定功能的時間。在很多情況下它可能還需要你犧牲一些功能或技術需求，比如平臺支持，性能，或覆蓋區（應用程序的大�。�。

遵循這一原則的反模式是在項目開始詳細記錄精確的需求，強制涉眾接受需求，然后對需求的變更進行協商，而需求的每一點變更都將增加項目的成本或持續時間。由于你一開始就鎖定了需求，你降低了使用已有資產的能力，于是迫使你進行定制化的開發。另一個反模式是構建一個只能滿足最強勢的涉眾的需求的系統。

跨團隊協作

好處：團隊生產力，更好地結合商業需求與軟件系統的開發和運作。

模式：鼓勵人們拿出最好的表現。分析師，開發人員和測試員的跨職能合作。在集成化的環境中管理演化中的工件和任務來加強協作和進度/質量洞察力。確保業務，開發和運作團隊作為一個集成的整體高效地工作。

反模式：培養英雄個體并為他們配備強大的工具。

軟件是由有才能，有動力，并緊密合作的人制造的。很多復雜的系統需要一定數量的有不同技能的涉眾的活動，而最大的項目常�？缭降乩砗蜁r間的界限，進一步增加了開發過程的復雜度。這就是人的問題和協作——稱之為軟件開發的“軟”元素——成為了靈活開發的主要焦點的原因。1 這一原則指出了很多問題，包括：你如何激勵人們，使他們的表現最好？在一個在同一地點的軟件團隊內，在一個分布式團隊內，在共同參與一個業務活動，軟件開發，和IT運作的不同團隊之間，你如何與人合作？

有效合作的第一步是激勵團隊中個人的最好表現。自我管理團隊的概念2 在靈活性目標中正在受到越來越多的關注；它是基于使一個團隊專注于他們要發布的產品，然后為他們提供決定所有直接影響結果的問題的權力的。當人們感到他們真正要對最終產品負責的時候，他們被激勵去很好地完成工作。正如靈活性宣言陳述的：“在被激勵的個體周圍建立項目。給他們需要的環境和支持，并相信他們將會完成任務�！�

第二步是鼓勵跨職能的合作。很多年前我們就指出，“軟件開發是一項團隊工作�！币粋�迭代的方法增加了作為一個團隊緊密工作的需要。我們經常需要打破建立于分析師，開發者和測試者之間的阻隔，并拓寬成員的角色職責以保證迅速變化的環境下的有效合作。每一個成員需要理解項目的任務和遠景。

隨著我們的團隊的增長，我們需要提供有效的合作環境。這些環境方便了度量收集和狀態報告，并使圍繞配置管理的構建管理和日志自動化。這一有效性使得更少的會議成為可能，這樣團隊成員可以花更多時間在生產和創造性活動上。這些環境還應通過簡化交流，溝通不同團隊成員在時間和地域上的阻隔來實現更有效的合作。這種環境的例子包括了從共享項目房間到網絡或基于網絡的方案，比如Wikis或集成開發環境和配置及變更管理環境。

在這個原則下我們的最終目標是集成化的跨業務，軟件和運作團隊間的合作。隨著軟件在我們如何運作我們的業務中變得越來越重要，我們需要與1）決定如何運作我們現有的和將來的業務的團隊，2）開發支持軟件系統的團隊，以及3）運作我們的IT業務的團隊進行緊密的合作。

圖3：跨業務、開發和運作團隊協作。隨著軟件在我們如何運作我們的業務中變得越來越重要，我們需要與負責如何運行業務，如何開發應用程序，以及如何運行應用程序的周圍團隊更緊密地合作。在多數公司中，這三個小組的交流很糟糕。

這一原則的反模式是培養英雄式的開發者，他們愿意超長時間工作，包括周末。一個相關的反模式是培養高度專業的人，并為他們的工作配備有強大工具，他們與其它團隊成員的合作很有限，而且不同工具間的集成也很有限。這里的假設是如果每個人都做好他自己的工作，最終結果就會是好的。

迭代地證明價值

好處：早期風險消減，更高的可預測性，涉眾的信任

模式：使用一個迭代過程進行自適應的管理。首先解決主要技術，業務和風險。通過在每次迭代發布遞增的用戶價值獲得反饋。

反模式：詳細計劃整個生命周期，用計劃記錄變數。詳細計劃是更好的計劃。通過評審規格來評估狀態。

這一原則下有若干隱含規則。首先，你想要交付增量價值來獲得早期的和連續的反饋。這是通過把我們的項目劃分為一組迭代過程實來現的。在每次迭代中，你完成一些需求，設計，實現，和對你的應用程序的測試，因此產生了一個距最終方案更進一步的發布。這使得你能夠向終端用戶和其它涉眾演示應用程序，或讓他們直接使用應用程序，使他們能夠對你的工作做出快速的反饋。你進行的方向正確嗎？涉眾對你到目前為止的工作滿意嗎？你需要改變已經實現的特性嗎？還有哪些特性需要被實現以增加業務價值？通過對這些問題做出令人滿意的答復，你將會因發布實現涉眾需要的系統在涉眾中建立信任。同時你也不大會把工作做過頭，加入對終端用戶沒有用處的功能3。

第二條規則是利用演示和反饋來調整你的計劃。你需要做的不是依賴于評估規范，比如需求規范，設計模型，或者計劃，你需要評估的是已經開發出來的代碼的實際工作情況。這意味著你集中于測試結果并向不同涉眾演示工作代碼，使他們可以評估你的進展。這為你提供了一種良好理解，包括你在何處，在你的開發環境下團隊可以以什么樣的速度取得進展，以及為了成功完成項目你是否需要對過程進行校正。你使用這些信息來更新項目計劃并為下一次迭代開發更詳細的計劃。

隱含的第三條規則是包含并管理變更�，F在的應用程序太過復雜，以致你無法一次很好地排列需求，設計，實現，和測試。取而代之地是，最有效的應用程序開發方法包含了不可避免的變更。通過早期和連續的反饋，我們了解了如何改進應用程序，而迭代的方法為我們提供了逐漸實現這些變更的機會。所有這些變更需要通過合適的過程和工具來管理，這樣我們就可以有效地管理變更而不影響我們的創造性。

這一原則隱含的第四條規則是在生命周期盡早發現關鍵風險4，如圖1所示。你必須盡可能早地指出主要技術，業務和編程風險，而不是把風險的解決推遲到項目的最后。這是通過不斷評估你面對的風險，并在下一次迭代中解決剩余風險中最重要的一個來實現的。在成功的項目中，早期的迭代包含涉眾確定一個遠景買進和高級需求，包括架構設計，實現，和用以減輕技術風險的測試。有一些信息需要被用來決定使用哪些可復用的主要資產或非銷售（COTS）軟件，保留這些信息也是很重要的。

圖4：瀑布和迭代開發項目的風險消減一覽圖。迭代開發的一個主要目標是在早期消減風險。這是通過分析，排列優先級，和在每次迭代過程中解決最大風險來實現的。

一個典型的反模式（即，過去的導致項目失敗的軟件開發實踐）是在整個生命周期開始前制定詳細的計劃，然后通過計劃跟蹤變化。另一個反模式是依賴于評審規格來在項目的前三分之二處評價項目狀態，而不是評估測試結果和工作軟件的演示情況。

提高抽象層次

好處：生產力，降低的復雜度

模式：復用已有資產，減少人類通過高級工具和語言產生的東西的數量，構建良好的彈性，質量，可理解性，和復雜度控制。

反模式：直接從模糊的高級需求發展出定制的代碼構思。

在軟件開發中我們面對的一個主要問題是復雜度。我們知道降低復雜度對生產力有很大影響。5在更高的抽象層次工作降低了復雜度并使交流變得容易。

一種有效降低復雜度的方法是復用已有資產，比如可復用的組件，繼承系統，已有業務過程，模式，或者公開源碼軟件。兩個關于復用的很好的例子在上一個十年對軟件工業產生了巨大影響，它們是對中間件的復用，比如數據庫，Web服務器和入口，以及后來的對公開源碼軟件的復用，它們提供了或大或小的可利用的組件。今后，Web服務可能會對復用產生主要影響，因為它們提供了在完全不同的平臺上，以及客戶和服務的提供者之間只有松散耦合的情況下復用主要的大塊功能的簡單方式，如圖6所示。這意味著你可以更容易地采用不同的服務組合來實現業務需要。公開標準，比如RAS，UDDI，SOAP，WSDL，XML和UML，也方便了復用。

圖5：通過面向服務的架構復用已有資產。 復用的問題之一是在開發時兩個組件需要知道對方的存在。面向服務的架構通過提供所謂的“松散耦合”減輕了這個問題，在圖中由黑色雙箭頭指示。某服務的客戶可以動態地找到一個服務的提供者。因此你可以把已有的組件或繼承系統包裝起來，允許其它組件或應用程序通過一個基于標準的接口動態地訪問它們的功能，并且這種訪問是獨立于平臺和實現技術的。

另一種降低復雜度和改善交流的方法是利用高級工具，框架和語言。標準語言，比如統一建模語言（UML），和快速應用語言比如EGL6提供了表達高層構建，比如業務過程和服務組件，方便了其周圍的高級構件的合作而同時隱藏了不必要的細節。設計和構建工具可以通過提供自動化設計，構建，和測試任務的向導來自動化從高級構件到工作代碼的轉移，而向導的自動化功能是通過產生代碼和允許代碼片段的使用，以及把集成和測試通過集成化開發，構建，和測試環境轉變為無縫開發任務實現的。另一個例子是項目和證券管理工具，它們使你能夠把多個項目的金融和其它方面作為一個實體來管理，而不是作為一組分離的實體來管理。

管理復雜度的第三種方法是集中于架構，無論你正試圖定義一個業務還是開發一個系統或應用程序。在軟件開發中，我們的目標是設計一個架構，實現它，并在項目的早期就進行測試。這意味著在項目的早期我們要定義高級構建模塊和最重要的組件，它們的功能和接口。我們定義和實現系統機制，也就是對常見問題的現成解答，比如如何處理一致性和碎片收集。通過盡早正確建立架構，我們為系統定義了一個骨架，使得當我們向項目中加入更多的人，組件，功能和代碼的時候管理復雜度比較容易。我們還認識到我們可以利用哪些可復用資產，以及系統的哪些方面需要定制。

這一原則的反模式是直接從模糊的高級需求發展出定制的代碼構思。由于基本沒有進行抽象，在代碼級而不是一個更概念化的級別上進行了很多討論，這就失去了很多復用等的機會。掌握的非形式化的需求和其它信息需要很多決定和規范來不斷重新訪問，而對架構的有限的強調造成了在項目后期的主要返工。

好處：更高的質量和更早的進度/質量洞察

模式：團隊對最終產品負責。如果有可證明能力的持續集成，測試變得擁有更高的優先級。逐漸地建立測試自動化。

反模式：推遲集成測試直到所有代碼都完成并且單元測試也已完成。詳細檢查所有工件以發現問題，但同時不進行部分實現和測試。

提高質量不是簡單的“滿足需求”，或是生產一種滿足用戶需要和期望的產品。質量還包括了確定展示產品的成果的量度和標準，以及一個保證團隊創造的產品實現了期望的質量水平的過程的實現——這一過程可以被重復和管理。

保證高質量不只需要測試團隊的參與；它需要整個團隊關注質量。這涉及了所有團隊成員以及生命周期的所有部分。分析師對確定需求的可測試性負責，而且我們還要明確對測試的需求。開發人員需要在設計過程中考慮到測試，并必須對測試他們的代碼負責。管理人員需要保證正確的測試計劃在正確地實施，正確的資源在適當地用于建立測試件并進行需要的測試。測試員是質量專家。他們指導團隊的其余成員理解軟件質量問題，他們對功能，系統和性能級的測試等等負責。當我們經歷一個質量問題時，每一個團隊成員都應積極參與闡述這個問題。

迭代開發的主要優勢之一是它使一種盡早地并且不斷地測試方法成為可能，如圖2所示。由于最重要的功能在項目的早期就被實現了，在你達到末期時，本質的軟件可能已經成型并運行幾個月了，而且可能已經經過了幾個月的測試。多數采用迭代開發方法的項目聲稱改進過程帶來的主要結果之一是質量的提高，這也就是意料之中的了。

在我們逐步建立我們的應用程序的同時，我們還應該逐步建立測試自動化來及早發現缺陷，同時使前期投資最小化。在你設計你的系統時，考慮到它將如何被測試。做出正確的設計決定可以在很大程度上提高你的自動化測試能力。你還可以直接從設計模型中產生測試代碼。這節省了時間，為早期測試提供了動力，并通過最小化測試軟件中的缺陷提高了測試的質量。自動化測試已經成為靈活性關注的焦點，而靈活性的目標是使所有代碼的測試自動化，并且測試是在代碼編寫前編寫的（所謂的測試先行的設計）。

圖6：測試在早期被啟動并在每一次迭代中被擴展。迭代開發使早期測試成為可能。軟件在每次迭代中被建立起來，并且在建立過程中就經過了測試�；赝藴y試保證了當新的迭代添加了功能時沒有引入新的缺陷。

這一原則的反模式涉及對所有中間工件進行深入詳細的回顧分析，這對生產效率是不利的，因為它延遲了應用測試，也就延遲了主要問題的識別。另一個反模式是在進行整體測試前完成所有單元測試，援引同樣是延遲了主要問題的識別。

總結

正如我們開始時注意到的，這些原則是從十余年前它們的原型演化而來的，那時軟件開發者的工作環境基本上是更為有限的。我們關于軟件開發的知識，以及項目成功的整體條件，都逐漸成熟并不斷擴展。今天的業務驅動的軟件開發組織需要眼界更為廣闊的指導，這包括了地理分布開發，IT管理和規則服從需要，面向服務架構，等等。

正如軟件開發不是嚴密的科學，我們相信這些原則不應當被當作絕對的條款，或永恒的真理，而是作為一種改進軟件項目結果的指導。這些原則還將繼續演化——不是以很快的速度，但是逐漸的，隨著我們掌握更多關于哪些方法有效，哪些無效等等的經驗。不變的一點是Rational幫助客戶（他們的業務依賴于開發和部署軟件）取得成功的長期不懈的努力。