本文探討了各種方法，例如 Scrum、極限編程（Extreme Programming，XP）、Crystal、動態系統開發方法（Dynamic Systems Development Method，DSDM）等等，它們專注于精益軟件開發（Lean Software Development，LSD）的概念。在這個由兩部分組成的關于敏捷軟件開發的系列中，作者詳細地評估了它們對于開發面向服務的體系結構（Service-Oriented Architecture，SOA）的適宜性。
引言
正如我們在本系列的第 1 部分中所闡釋的，面向服務的體系結構 (SOA) 和敏捷開發兩個概念都旨在用于可適應的企業 IT 系統。然而，在關于 SOA 開發和敏捷方法的主題的 CBDI 說明中提到，敏捷開發和 SOA，就如同油和水一樣，不能溶合在一起。所以，如果頭腦中已經有了這樣的想法，您還真的可以像 SOA 那樣來將敏捷開發原則擴展到多應用程序環境中嗎？在本系列的這一部分中，我們提供了證據來證明答案是“肯定的”。
SOA 和精益軟件開發：Fit-Gap 分析
通過依次介紹每個精益軟件開發原則，我們研究如何使用它們來使 SOA 的開發從中受益。除此之外，我們還討論了它們在使用敏捷方法的環境中的好處。下表給出了 LSD 原則與其在敏捷方法的環境中帶給 SOA 開發和交付的基本好處之間的初始高級映射。
表 1. LSD 與 SOA 原則的初始映射
|
LSD 原則
|
SOA 的好處
|
| 1. 消除浪費 |
- 寬度優先的服務模型開發有助于識別正確的服務候選者和重用能力。
-
值流映射 (Value stream mapping)，一種用于系統地檢測沒有價值的處理步驟的技術，使您能夠識別有價值的服務。
|
| 2. 加強學習 |
- 反饋有助于定義重用的服務。
- 同步在服務的實現階段特別有用。
|
| 3. 盡可能晚地決定 |
不確定服務接口的細節使得有可能通過實踐來學習。 |
| 4. 盡可能快地交付 |
- 使用服務的情節串連圖板 (Storyboard) 和“SRC 卡片”（服務 (Service)、責任 (Responsibility)、協作 (Collaboration)）來創建更小的工作單元和更高的吞吐量。
- 創建約定的一個簡單的經濟模型，可以用于驅動開發決策。
|
| 5. 向團隊授權 |
通過授權和委托微觀設計決策給負責交付 SOA 中的服務的專業人員，您增加了交付服務的能力，該服務滿足當前的業務需求，而不是先前預測的或者規定的業務需求。 |
| 6. 構建完整性 |
- 通過簡化端到端的通信流程，確保業務流程和交付的 IT 服務之間具有更強的耦合性以及期望的服務質量（Quality of Service，QoS）。這種方法使開發人員能夠確保交付的服務具有所需的完整性。
- 通過解構代碼和體系結構，確保開發和部署的服務能夠交付所期望的 QoS，同時支持業務環境的持續改變。使用這種服務模型使受控解構成為可能。
|
| 7. 眼觀全局 |
就其真實的本質來說，SOA 專注于業務流程聯合，重點在于企業。通過確保工作團隊堅持把工作重心放在全局性的問題上（眼觀全局），您實現了用于確保服務驗證和編排與核心業務流程緊密配合的最佳實踐。 |
讓我們進一步詳細地討論上面的表 1 中定義的映射：
原則 1：消除浪費
寬度優先服務模型開發
為了理解什么是重要的以及什么是多余的，使用寬度優先 (breadth-first) 取代深度優先 (depth-first) 是明智的，先取得總體認識，然后再深入細節。當開發企業級 SOA 時，您應該避免以遺漏關鍵部分為代價來預先構建系統無關緊要的部分的詳細分析文檔目錄。當然，很難預知未來和靈活性的需求；因此，快速反饋是必要的。
一些來自面向服務的建模和體系結構方法（Service-Oriented Modeling and Architecture Method，SOMA）的技術很好地支持“寬度優先”方法，即：自頂向下 (top-down) 域分解、自底向上 (bottom-up) 現有系統分析以及目標-服務建模（請參閱文章“Service-oriented modeling and architecture”）。在經過總體觀察以后，決定在服務組合 (Service Portfolio) 中包含哪些服務。只有到這個時候，您才能詳細地定義服務。
值流映射
映射值流是開始發現流程中的浪費的一種好方法。它把重點放在用戶的產品及其價值上，而不是組織、資產、技術、流程和人員上。利用值流映射的結果，您可以將精力投入到給組織帶來最多價值的流程和服務上。挑選最大的機會去增加流動和增值時間 (value-added time)。您可以利用這項技術來分析業務流程（將由 SOA 支持）或者軟件開發流程（用于開發 SOA）。
原則 2：加強學習
反饋
服務的“用戶”是應用程序。預先設計一個用于所有應用程序的最佳重用的服務接口是不可能的。實際上，您是從初始的接口和演示程序開始，然后部署服務，最后從使用的應用程序獲得反饋。一個小先遣隊開發了一個簡單跨系統的試驗應用程序：
- 采用一個業務流程
- 分析和設計它的服務
- 原型化用戶接口
- 與后端集成
- 跨整個流程
如果可能，試驗應用程序應該變成產品。當這種跨系統的應用程序在生產中得到證實時，您就知道了您有了可工作的應用程序。到了那時，多個小組就可以使用一樣的方法并且每次進行多項工作。
與采用瀑布方式開發整個 SOA 相比，依賴于快速交付和頻繁反饋甚至更為重要，這是因為您不可能第一次就做出正確的設計。敏捷方法推動了快速反饋和熱點 (Hot Spot) 的出現，這里需要靈活性。工程實踐（例如測試優先開發和持續集成）減少了開發人員獲得反饋的時間。增量功能的頻繁交付支持來自客戶或用戶的直接反饋。
同步
敏捷方法至少使項目間的依賴關系可見，并且還有一些處理它們的工具（請參閱本系列第 1 部分中的 Scrum 部分）。項目間頻繁同步的想法在服務的實現階段特別有用，這里可能發生服務范圍內的改變，因為正是在這一階段詳細地分析服務。
原則 3：盡可能晚地決定
不確定服務接口的細節
在像 SOA 這樣企業級的約定中，似乎最好是在非常詳細的層次上設計服務接口，讓不同的項目來實現它們。這種方法的優點好像是服務應用程序可以獨自工作，而不需要長期地與其他項目同步。遺憾的是，這并不能正常工作，因為您無法預先確定所有的細節。面對不確定性，這樣做的結果就是導致浪費（以錯誤的細節的方式）。長期進行來實現錯誤細節的項目將難以使它們的代碼解構變得簡單。這會產生一個未達到最佳狀態、卻又固定的服務模型。
盡可能晚地決定意味著，在有證據可以清楚地判斷服務應該是什么樣子之前，不確定服務接口的細節，而不是假裝無所不知。這就促使開發小組與公司的其他部門經常性地保持步調一致，而且它還產生更好的服務模型。
原則 4：盡可能快地交付
拉系統
敏捷開發中的拉系統 (Pull System) 借助于信息發射源 (Information Radiator) 使人們能夠自己確定去做什么（例如，走廊上可能有一個白板，所有相關的用戶素材都寫在上面的卡片上；分配工作意味著將素材卡片 (Story Card) 從白板的“to-do”區移到“checked-out”區）。
在 SOA 環境中，您可以在卡片上編寫用戶素材和服務。通過添加服務，工作單元甚至變得更小，因為正如本系列的第 1 部分的 SOA Application 部分中所述，功能性是在用戶界面應用程序、服務編排以及服務應用程序之間分配的。排隊論指出，更小的工作包產生更高的吞吐量，例如功能的更快交付。
眾所周知的用于面向對象 (OO) 設計的 CRC 卡片（類 (Class)、責任 (Responsibility)、協作 (Collaboration)）技術（請參閱 A Laboratory for Teaching Object-Oriented Thinking 以獲得背景信息）可以修改成 SOA 設計中的 SRC 卡片。“面向服務的分析與設計原理”包括這種技術的初始示例。
約定的經濟模型
傳統上，軟件開發有時被看作是產生成本。近來，軟件開發被看作是產生收入，可以幫助利用經濟期權。基于期權的軟件經濟從金融市場提取出相似之處：交付運行的軟件的短期迭代被看作是實物期權 (Real Option)。就像金融期權 (Financial Option) 一樣，實物期權通過現在非常少量的投資，來向您提供可能從未知的將來獲得收益的機會。
但是并不需要走那么遠：如果您創建約定的簡單經濟模型并使用它來驅動開發決策，甚至 SOA 約定也將從中受益。有了這個經濟模型，就可以向團隊成員授權，讓他們自己明確什么對于業務是重要的：他們可以都從相同的假定開始工作。如果您考慮減少一些特性，銷售部門可能推測出，沒有這些特性，他們將少銷售百分之“X”單位的產品。
原則 5：向團隊授權
對于任何軟件開發，最有資格作決定的人就是在第一線工作的人。在解決方案體系結構層次上仍然需要嚴格的控制，而基礎服務開發應該盡可能地靈活。通過授權給最接近實現的專業人員去做微觀決策，您可以確保服務的最終代碼滿足所需要的功能性。在企業 SOA 中，您可以從授權和委托設計決策給服務的開發人員（在定義的范圍內）中受益。
無論何時沿著層次結構向下委派決策權，您都必須確保所有的決策者都理解了統帥全局的愿景。通常，決策應該始終的是大家共同參與的活動，而不是孤立的活動。跨功能團隊的環境（出現在敏捷項目中）促進了決策協作。
原則 6：構建完整性
構建在概念上具有高度完整性的 SOA 的方法是從客戶到開發團隊、以及開發團隊的上游流程和下游流程之間都有良好的信息流。從我們的角度來看，我們認為這一原則在服務開發層次以及服務編排中具有很高的價值。通過維持業務和 IT 專業人員之間良好的通信水平，可以確信您所交付的 IT 解決方案滿足當前以及未來的業務流程和需求。隨著結構良好的 SOA 中的業務和 IT 之間的聯系越來越緊密，逐漸要求所交付的服務能夠滿足和緊密配合超出目標的業務流程。如果沒有這種高層次的完整性，那么交付的服務不滿足必要的業務要求或 QoS 的風險將會增加。
解構
現在，在 IT 產業中解構開發代碼的實踐得到認可已經有一段時間了。在 SOA 的環境中，這種實踐同樣重要。由于與業務的配合越來越緊密，以及需要確保所交付的服務可以支持不斷變化且敏捷的業務環境，因此需要從本質上確保持續地評審和解構基礎服務的設計。如果不能做到這一點，就將導致服務僵硬、不靈活，這對支持不斷變化的業務環境沒有益處。正如本系列的第 1 部分中的 Agile architecture 部分所述，該服務模型是控制持續解構的出色工具。
原則 7：眼觀全局
SOA 的一項基本原則就是企業層次上的業務聯合。對于任何企業體系結構 (Enterprise Architecture) 約定，都存在一個內在的需求，即確保始終維護統帥全局的“城市規劃 (city planning)”視圖，并專注于將在 SOA 中部署的單個服務的詳細設計。如果陷入以犧牲整體為代價來換取最佳的單個部分（或者服務）的誘惑中，您將承受交付不靈活的 SOA 的風險，它與企業中的關鍵業務流程是不相配的。
結束語和展望
正如我們在本系列中展示的，SOA 可以從敏捷軟件實踐和 LSD 的已證明有效的原則中獲得極大的好處。敏捷和 SOA 這兩種實踐的匹配基于一個共性——兩者都極力設法處理變化。服務接口應該當作實現可能將改變的應用程序的必要條件。敏捷項目為要求它們實現的服務接口的改變做好了準備。
SOA 的“持續的”解構意味著經常更改服務接口和服務組合。SOA 中的這種敏捷需要實現項目中的敏捷。基于本文中所強調的要點，我們要說，當實現項目采用敏捷方法并接受改變時，SOA 中真正的敏捷將起作用。
通常油和水并不能溶合在一起。不可否認，極限編程的想法和以可控的方式建立企業級服務體系結構之間存在著文化差異。但這僅僅是初步估計，在寫完本文之后，我們可以聲明存在一種乳化劑，即 LSD 的原則。
所以，最后我們將聲明，在 SOA 和 LSD 原則的上下文中，“油和水確實可以溶合”！