本文是由兩部分組成的系列文章的第 1 部分，闡述了普遍接受的方法學（例如 Scrum、極限編程（Extreme Programming，XP）、Crystal、動態系統開發方法（Dynamic Systems Development Method，DSDM）和主要研究精益軟件開發（Lean Software Development，LSD）的其他方法學）內包含的敏捷開發的基本原則。當今，必須提高業務的靈活性和速度，以應對不斷變化的客戶需求、市場機會和外部競爭對手的威脅。為使這些業務得以成功，可以采用面向服務的體系結構 (SOA) 的開發方法來設計以適應性（對變化和需求做出響應的能力）為目標的 IT 系統。本系列的第 2 部分詳細描述了它們用于開發 SOA 的適應性。
引言
面向服務的體系結構 (SOA) 由 Mark Colan 等受人尊敬的思想領袖定義和闡述（請參閱“Service-Oriented Architecture expands the vision of Web services, Part 1”），作為普遍接受的用于設計可適應的、企業級 IT 系統的新興風格，它已經得到了很大的發展。雖然目標十分明確，但實現目標的方法卻并非如此，因為還沒有受到廣泛接受的 SOA 方法學。不過，在這方面還是進行了一些研究（請參見 SOA 的方法學）的。
負責設計 SOA 的每個人都會面對兩個主要挑戰：1) 如何設計一個系統來很好地適應業務流程、業務目標和 IT 體系結構，2) 如何構建一個能對將來的變化做出響應的體系結構？第二個挑戰與敏捷性相關，通常在敏捷軟件開發方法的背景下進行討論。在本文中，我們將介紹如何將此方法的思想擴展到 SOA 的設計。我們先回顧一些最常見的敏捷開發方法，然后再研究“精益軟件開發”(LSD) 的原則。最后，我們討論在構建 SOA 的過程中對 LSD 的初步分析。
SOA 入門
什么是 SOA？
在構建 IT 體系結構（特別是企業級體系結構）時，我們的目標始終是：支持業務流程并對業務變化做出響應。在最近幾年中，出現了一些構建系統體系結構的新方法，這些方法主要圍繞功能單元（稱為服務）來構建復雜的系統。
最新的理解是，服務包含 4 個主要方面：
Web 服務也對以上這幾個方面提供基于系統和標準的支持。因此，Web 服務具有無與倫比的敏捷性這一優點。例如，使用 Web 服務基礎設施可以在運行時更改服務提供者，而不影響使用者。
某個系統本身要被稱為基于 SOA 的系統，應具備以下特性：
- 業務流程映射到軟件服務；因此，業務可通過軟件進行跟蹤。
- 存在一種基礎結構，支持上述服務的 4 個不同方面。這樣服務級別就具有高度的敏捷性。
- 服務是監視和管理單元。因此，一個人可以跟蹤業務流程的操作屬性和問題。
SOA 應用程序
圖 1 從應用程序角度展示了企業級 SOA 所包含的元素。業務流程 由用戶界面應用程序 和服務應用程序 進行部分和完全支持。業務流程中的一個步驟或者通過人工執行，或者得到用戶界面應用程序的支持。用戶界面應用程序實現了許多宏工作流，而且它們還使用實現業務功能的服務。
在服務編排 層，組合服務 是通過編排語言（例如業務流程執行語言（Business Process Execution Language，BPEL））定義的。組合服務的編排通過基本服務 定義其流程和組成。編排層應由支持圖形規范的編排工具提供支持，例如 IBM WebSphere? Business Integration Modeler 和 IBM Rational? Application Developer。
基本服務（由服務編排層使用，也由用戶界面應用程序使用）通過服務應用程序實現。而服務實現又可以調用其他服務，這些服務通常來自另外的服務應用程序。
圖 1. SOA 的元素
SOA 的方法學
構建一個合理的 SOA 應采用何種開發方法？從前面的部分可以看出，有業務流程、應用程序和服務。顯然，對服務建模是此類方法必須支持的主要任務。另一個重要的方面是確保業務流程和服務之間的鏈接（請參見什么是 SOA）。
文章“Elements of Service-Oriented Analysis and Design”說明了現有的模型（例如面向對象的分析和設計（Object-Oriented Analysis and Design，OOAD）、企業體系結構框架和業務流程建模技術）對 SOA 設計的作用。本文還指出，您需要將其他方法元素用于 SOA，例如用于服務標識和聚合的方法和技術、業務跟蹤能力、現有資產的集成和重用。
在另一篇 IBM developerWorks 文章“Service-oriented modeling and architecture”中描述了一種方法，回答了上述許多問題。本文主要介紹服務的建模，它是在域分解、現有系統分析和目標服務建模之類的技術支持下實現的。
引用的這兩篇文章提出了許多問題，我們仍需要回答這些問題——例如，SOA 控制問題。我們要提出的另一個問題是：在 SOA 開發中應采用哪些規則和實踐來確保服務模型能對將來的變化做出響應？在這里，我們可以求助于各種敏捷軟件開發方法。
敏捷軟件開發
敏捷軟件開發是自上世紀 90 年代 Kent Beck 提出極限編程 (XP) 時開始興起的，這種編程方法用一組價值標準、原則和實踐來規劃、編碼、設計和測試軟件。（有關對 XP 的介紹，請參見 Extreme Programming: A gentle introduction。）
所有敏捷軟件開發方法都具有以下幾個共同價值標準，例如
- 頻繁檢查和改寫
- 頻繁交付
- 協作和密切溝通
- 深思熟慮的改進
- 突出需求（遞增）、技術和團隊能力
- 授權和自我組織
- 基于事實而非假象進行處理
- 勇氣和尊重
從這些價值標準可以看出，現在使用的各種敏捷方法都注重不同的實踐。
2001 年 2 月定義了 Agile Manifesto，它在流程和工具的基礎上評價個體和交互操作，在綜合性文檔的基礎上使用軟件，在合共協商的基礎上進行客戶合作，并在遵循計劃的基礎上對變更做出響應。它是現今使用的所有敏捷方法的基礎。
為了使本文的闡述更加清楚，我們簡要介紹了最常用的敏捷方法，因為在開發 SOA 時它們中的許多都是非常有用的。我們知道，SOA 不僅與軟件開發有關，而且還與業務和 IT 體系結構有關。因此，如果我們了解軟件開發實踐，則我們必須始終評估它們是否適合 SOA。在本系列文章的第 2 部分中完成此評估。
Scrum
Scrum 似乎是很簡單的，但仍有一些實踐會對工作體驗產生深遠的影響，并獲得重要的適應性和敏捷性。在這些方法中，Scrum 與眾不同的特點是對自我指導團隊、每日團隊評估和避免說明性流程進行了極大的提升。Scrum 的一些關鍵實踐包括：
- 自我指導和自我組織團隊
- 每日就特殊問題（您做了什么、您將做什么和您遇到哪些問題）開站立會議
- 通常采用 30 天的日歷循環
- 在每個循環的開始，制訂客戶驅動的適應計劃
- 向參與者演示功能（在每個循環結束時）
對于企業級活動，了解和管理項目間的依賴項非常重要。在 Scrum 中使用“Global Backlog”就可以很好地做到這一點，Global Backlog 是對用戶有價值的功能和非功能需求的企業視圖。Global Backlog 在全局區分優先級。每個項目從 Global Backlog 獲得項目范圍內的最重要的部分。“Scrum of Scrums”還涉及項目間的同步，這是一個每兩天（或每周）一次的會議，來自每個團隊的代表參加這個會議，以便在團隊之間同步。
XP
XP（http://www.extremeprogramming.org 和 http://www.xprogramming.com）注重協作、快速和早期軟件創建以及有技巧的開發實踐。它由一組主要實踐（坐在一起、整個團隊、信息工作空間、成對編程、每周循環、放松、10 分鐘構建、持續集成、測試優先編程、增量設計等等）和一組與之對應的實踐（實際客戶參與、增量和每日部署、根源分析、共享代碼、單獨的代碼庫、協商的范圍合同、根據使用情況計費等）組成。
Crystal
Crystal 是具有以下共同特征的一系列方法學：注重頻繁交付、密切溝通和深思熟慮的改進。Crystal 的這些特征包括：
Crystal 系列通用優先級可以保證項目的最終成果，提高開發效率，并且符合常規習慣（換句話說，開發人員可以接受它們）。項目團隊可以采用 7 個安全特性（前 3 個是 Crystal 的核心，而其余的可以按任何順序添加，以增加安全性）：
- 頻繁交付
- 深思熟慮的改進
- 密切溝通；個人安全（信任的第一步）
- 聚焦
- 易于訪問專家用戶
- 帶自動測試的技術環境
- 配置管理
- 頻繁集成
動態系統開發方法
動態系統開發方法 (DSDM) 提供了一個用于構建和維護系統的控件框架，該框架滿足緊急時間限制的要求，而且是成功進行可重復快速應用程序開發 (RAD) 的一劑藥方。該方法不僅涉及開發人員對 RAD 的看法，而且還涉及對有效系統開發感興趣的所有其他相關各方（包括用戶、項目經理和質量保證人員）對 RAD 的看法。下面列出了 DSDM 的控制原則：
- 活動用戶必須參與。
- 必須授權 DSDM 團隊進行決策。
- 注重頻繁交付產品。
- 判斷產品是否可接受的一個基本標準是要符合業務目的。
- 對準確的業務解決方案需要采用循環和增量開發。
- 開發期間的所有更改都是可逆的。
- 基本要求是高層次的并區分優先級（以在低優先級的項目上獲得一定的靈活性）。
- 在整個生命周期集成測試。
- 在所有參與者之間采用協作和合作方法是一項基本要求。
精益生產
制造業已經意識到存在兩種生產問題——“可預測的生產”和“新產品開發”。前者的特征是確保具有提前了解需求的能力，因而可以制訂確定性計劃。后者的特征是沒有事先明確了解需求的能力，因而需要隨項目的進展不斷地調整適應和重新評估。
Craig Larman 在他所著的 Agile and Iterative Development一書中對這些問題做了比較，得出以下結論：
表 1. 可預測的生產和新產品開發的比較
| 可預測的生產 | 新產品開發 |
| 可以首先完成規范，然后再構建。 | 幾乎不可能創建提前的、不變的和詳細的規范。 |
| 在即將開始時，可以可靠地評估所投入的精力和成本。 | 在即將開始時這是不可能的。隨著經驗數據的不斷出現，進行計劃和評估的可能性越來越大。 |
| 可以對所有詳細活動進行標識、定義、安排和排序。 | 在即將開始時這是不可能的。需要采用通過構建反饋循環驅動的適應性步驟。 |
| 適應不可預測的變更不是標準要求，而且變更速度相對較慢。 | 創造性地適應不可預測的變更是標準要求。變更速度較快。 |
例如，Toyota 在上世紀 80 年代使用“精益生產”方法對其汽車工業進行大規模改革，目的是消除浪費，精簡價值鏈（甚至跨所有企業），按需求生產（實時生產），并注重增值人員。
LSD
Mary 和 Tom Poppendieck 已將這些原則和實踐從生產環境轉用到開發環境（有關詳細信息，請參見他們的網站），目標是在整個持續改進期間確定和消除浪費，并減少缺陷和循環時間，而同時穩定地增加商業價值。LSD 的基礎就在于諸如 Toyota、Dell 和 Wal-Mart 這些組織所采用的一組“精益生產”標準。
需要注意的重要一點是，像 XP、DSDM、SCRUM 等其他方法一樣，LSD 在本質上并不是一種開發方法，而是提供許多應該應用于改進軟件開發的基本原則，不考慮使用的開發方法和項目方法。本文的其余部分將快速回顧 LSD 的七個原則和一些工具（例如，下文中用斜體列出的思想）。
原則 1：消除浪費
消除浪費是最基本的精益原則。它是所有其他原則應遵循的原則。實現精益開發的第一步是了解浪費（沒有提高代碼質量，沒有減少生產代碼所需的時間和精力，或沒有向顧客提供商業價值的任何東西）。第二步是公開最大的浪費源并消除它們。大量研究表明，在早期規范定義的功能中，最多有 45% 的功能在解決方案完成和交付后從未使用過。
原則 2：加強學習
在組織面對軟件開發挑戰時，往往在組織中安排一個用紀律強加約束的流程，這個流程有更嚴格的順序關系。控制理論指出，這種做法會使情況變得更糟。當問題出現時，要做的第一件事是確保反饋循環都各司其職。要做的第二件事是在問題領域增加反饋循環的頻率，因為短反饋循環將增強控制能力。
只要有幾個人正在做同一件事，就需要進行“同步”。對同步的要求是任何復雜開發流程的基礎。“循環”是同步的關鍵點（團隊和客戶將了解完成的任務）并強制做出決策。
原則 3：盡可能推遲做出決定
在開發開始前確定需求是防止出現嚴重問題的一種通常的做法。順序開發（例如瀑布開發模式）的問題是，它強制設計人員采用深度優先而非廣度優先方法。最容易犯大錯誤的方式是深入研究細節的速度太快。
對于并行開發（例如，所有工作都在循環——即分析、設計、編程和測試——中完成），只要高級概念設計一確定，您就開始對具有最高價值的功能進行編程，甚至此時詳細需求還在調查之中。這種探索性方法允許嘗試各種選擇，然后即可確定限制實現較不重要功能的做法（“選擇思考”）。但并行開發要求開發人員在領域內具有足夠的專門知識（以預期新興設計可能的發展方向），并與客戶和分析人員（他們設計系統如何解決現有的業務問題）進行密切合作。
原則 4. 盡快交付
客戶喜歡快速交付，這常常轉化為業務靈活性的提高。對軟件開發而言，快速交付是一種選擇友好的方法。它允許您暫時不做出選擇，直到您減少了不確定性，然后可以做出更明智的基于事實的決策。
所有人都必須始終明白，她或他應如何做才能對業務做出最有效的貢獻。您可以告訴他們要做什么（“命令和控制”），也可以搭建一個舞臺，讓他們自己發揮（“自我組織”）。在快速變化的環境中，只有第二種選擇行得通。為了有效地進行自組織，必須開發本地通信和委托方法（例如使用信息發射器）以拉系統 的方式協調工作。在具有適度可變性的復雜環境中，沒有任何計劃可以做出有效的細粒度工作分配。提早創建詳細計劃意味著將您的一些決定刻到石頭上。進行計劃和預期絕非壞事，但要避免根據推測做出不可更改的決定。
快速開發的好處通常大于您的預期。為下幾年推出的某種新產品創建簡單的經濟模型（基本上為損益表 (P&L)），并使用該經濟模型推動開發決策。根據市場情況很好地評估哪些延遲將對銷售量（例如，早期的高定價損失）和市場份額（例如，市場份額的長期損失）產生影響。該模型將顯示在收入和市場份額之間哪種差異將對收益產生影響。
原則 5：向團隊授權
通常，改進計劃其實并未改變完成工作的方式。這些計劃增加了導致工作滿意度下降的因素（策略、監督和管理）而沒有增加導致工作滿意度提高的因素（成績、認同和責任）。精益思想利用一線工人的聰明才智，相信他們是有能力決定和繼續改進其工作方式的人。要是沒有遵守紀律、受到激勵的人員，軟件開發就不能成功，而實驗和反饋往往比一次將事情做成更有效。
原則 6：構建完整性
一個產品如果它的各個組件互相匹配并協調工作得很好，則這個產品就具有概念上的完整性；體系結構將在下列各項之間獲得有效的平衡：
要獲得概念上的完整性，請降低控制機制的重要性，這有利于：
不是從一開始就嘗試預測將來的趨勢，而是采用寬度優先的方法并保證基本要素正確。然后，讓細節浮現出來并對定期重構制訂計劃，以讓體系結構保持健康狀態。重構意味著在檢測到“異味”時停止工作（例如停止添加新功能），然后在繼續開發前，花時間查找和修復問題的根源。
重構只能在測試具有嚴格的安全保證時才能進行。測試應盡可能自動完成，并作為每日構建和持續構建的一部分運行。請在系統的整個生命周期維護一組綜合性測試。這樣，系統即可在其有用的生命周期中安全地進行修復和重構。如果沒有足夠的時間來進行測試，則首先要重新分配在需求文檔中編寫客戶測試所投入的精力。
原則 7：眼觀全局
系統越復雜，就越傾向于將系統分為幾部分并在本地管理這些部分。本地管理傾向于創建本地性能度量。這些本地度量經常產生導致整體性能降低的系統級結果（局部優化）。雖然 Lance Armstrong 贏得 1999 到 2005 的環法自行車賽的冠軍，但他只贏得幾次每日登臺領獎的機會。就像環法自行車賽，優化每個任務通常是一個很糟糕的策略。
通過知識工作 (knowledge work)，很難度量每件事情是否重要，特別是在每次努力都是唯一性和不確定性占優勢時。如果您不能度量每件事情的重要性，則部分度量就很有可能轉為本地管理。如果您不能度量優化整體業務目標所需的每件事情，則在沒有采用局部優化度量的情況下，最好停止度量。
從項目經理的角度看，在管理項目時，可以調整 4 個變量：時間、成本、質量和范圍。在這 4 個變量中，可以修改時間、成本和質量——但范圍除外。對功能區分優先級，但不在合同中指定要交付的固定功能集合。從固定范圍移到可協商范圍的方法：先交付高優先級功能，這樣就可以早在完全滿足客戶的一系列期望前交付具有商業價值的大部分產品。
敏捷體系結構
不預先進行任何宏大設計
軟件開發方法采用不同的方法來開發項目的體系結構：Rational Unified Process (RUP) 解決了早期的體系結構風險問題（“如果您沒有主動解決風險，則這些風險將會傷及您”），而 XP 要求“不預先進行任何宏大設計”。Scrum 只預先定義足夠用的體系結構，但之后以增量的方式交付體系結構——區分優先級的方式與其余的功能相同。
從敏捷的角度看，以下這些做法是不明智的：在項目開始時了解所有需求，分析這些需求，然后為整個系統開發體系結構，就像在瀑布模型中一樣。重要的是要平衡早期體系結構穩定性和更改的實現之間的需求。當然，一次又一次地修改重要的體系結構成本非常高。另一方面，如果決策很糟糕且不適合已變化的需求，則越早而非越遲改變決策就越好。
確認而非驗證
不論您在開發體系結構時使用何種方法 (approach)，都需要根據用戶的期望（而不根據需求）確認體系結構。這種確認只能通過開發部分解決方案（“骨架”、“衍生應用程序”和“曳光彈”）來演示體系結構是可行的。然后，逐步用細節充實體系結構骨架。
何時開展體系結構工作
傳統上，在早期項目階段，體系結構工作進展到何種程度是由開發團隊來決定的。某些敏捷開發方法（例如 XP 和 Scrum）將功能需求和非功能需求放在公共 backlog 中，然后讓客戶優先選擇需求。在客戶根據商業價值和關鍵程度對需求進行優先選擇后，開發團隊評估投入的精力和成本，然后引入可能帶來體系結構風險的專門知識。因此，體系結構是隨著需求而逐步開發完成的。
最近，有關何時開展體系結構工作的決定已進行合理處理，該決定不僅是技術決定，而且也是商業和財務決定。增量基金方法將需求細分成最小可市場化功能（ Minimum Marketable Features，MMF），并將體系結構細分為體系結構元素（Architecture Elements，AE）。基于啟發式方法，MMF 和 AE 按次序來優化各個財務目標（例如最大程度增加 ROI、最大程度減少現金投入、獲得較早的回報等）。客戶可以了解和評估各個體系結構選項及其財務負擔。開發團隊將了解提前開發所有體系結構和逐步交付體系結構的財務因素。
傳統方法和早期的敏捷方法都是一種“貪婪的方法”：傳統方法先“攻擊”最具風險的部分，而早期的敏捷方法先“攻擊”最有價值的部分。IFM 允許客戶和開發團隊選擇最有益的方法。
服務的持續重構
在 SOA 上下文中，一個應用程序決不會作為單獨的應用程序出現。就像我們在 SOA 應用程序中所講述的那樣，服務應用程序有多種用戶，因而存在各種應用程序之間的依賴關系，這一點作為服務模型中的服務依賴性清楚描述過。任何服務都應被考慮是否有可能被其他應用程序重用。因此，服務應用程序必須被認為是可重用的產品。實際上，這意味著敏捷性無可置疑地變得更重要了，因為應用程序使用者的數量增加了。這些使用者不僅有最終用戶，而且也有成為應用程序的使用者/客戶的其他應用程序。隨著客戶數量的增加，更改的數量當然也會增加，因為并非所有的用戶都有預見能力。
在驅動敏捷開發的 SOA 中存在一個中心因素：服務模型，即服務、服務的依賴性、組織和流程的模型。在第一個訂單交付后，服務模型就隨著時間及服務接口的定義而發展。公司將認識到其服務模型的當前版本具有弱點，因為沒有采用正確的方法定義服務的責任。它們不得不將責任從一個服務（或服務的一個版本）移到另一個服務，并更改服務接口。服務模型的重構是無法避免的，并且在敏捷軟件開發中，我們鼓勵進行持續重構。
重構服務意味著通過將責任從一個服務轉移到另一個服務來更改接口。這可以使用服務模型有控制地完成。服務模型成為 SOA 中進行敏捷開發的基本工具，因為沒有該工具，就很難控制服務重構。因為我們采用了服務模型，我們準備將敏捷軟件開發擴展到 SOA 級別！
從敏捷 SOA 前沿傳來一個好消息：敏捷性還變得較容易管理了。通過更改組合服務的服務編排，您可以捕獲業務流程中的更改。編排中的更改比基本服務實現中的更改更簡單。
結束語
在這個由兩部分組成系列文章的第 1 部分，我們介紹了 SOA 的概念、敏捷軟件開發和 LSD，并嘗試概述敏捷或精益原則和實踐對體系結構（包括服務體系結構）的影響。
本系列的第 2 部分嘗試將每種精益軟件原則與 SOA 開發混合起來。這種混合與文章的第 1 部分“敏捷開發”一章一起，構成了敏捷 SOA 開發的基礎。