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