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