敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

敏捷開發原則

敏捷建模（AM）定義了一系列的核心原則和輔助原則，它們為軟體開發專案中的建模實踐奠定了基石。其中一些原則是從XP中借鑑而來，在Extreme Programming Explained中有它們的詳細描述。而XP中的一些原則又是源於眾所周知的軟體工程學。複用的思想隨處可見！基本上，本文中對這些原則的闡述主要側重於它們是如何影響著建模工作；這樣，對於這些借鑑於XP的原則，我們可以從另一個角度來看待。

核心原則

◆主張簡單

當從事開發工作時，你應當主張最簡單的解決方案就是最好的解決方案。不要過分構建（overbuild）你的軟體。用AM的說法就是，如果你現在並不需要這項額外功能，那就不要在模型中增加它。要有這樣的勇氣：你現在不必要對這個系統進行過分的建模（over-model），只要基於現有的需求進行建模，日後需求有變更時，再來重構這個系統。儘可能的保持模型的簡單。

◆擁抱變化

需求時刻在變，人們對於需求的理解也時刻在變。專案進行中，Project stakeholder可能變化，會有新人加入，也會有舊人離開。Project stakeholder的觀點也可能變化，你努力的目標和成功標準也有可能發生變化。這就意味著隨著專案的進行，專案環境也在不停的變化，因此你的開發方法必須要能夠反映這種現實。

◆你的第二個目標是可持續性

即便你的團隊已經把一個能夠運轉的系統交付給使用者，你的專案也還可能是失敗的－－實現專案投資者的需求，其中就包括你的系統應該要有足夠的魯棒性（robust ），能夠適應日後的擴充套件。就像Alistair Cockburn常說的，當你在進行軟體開發的競賽時，你的第二個目標就是準備下一場比賽。可持續性可能指的是系統的下一個主要釋出版，或是你正在構建的系統的運轉和支援。要做到這一點，你不僅僅要構建高質量的軟體，還要建立足夠的文件和支援材料，保證下一場比賽能有效的進行。你要考慮很多的因素，包括你現有的團隊是不是還能夠參加下一場的比賽，下一場比賽的環境，下一場比賽對你的組織的重要程度。簡單的說，你在開發的時候，你要能想象到未來。

◆遞增的變化

和建模相關的一個重要概念是你不用在一開始就準備好一切。實際上，你就算想這麼做也不太可能。而且，你不用在模型中包容所有的細節，你只要足夠的細節就夠了。沒有必要試圖在一開始就建立一個囊括一切的模型，你只要開發一個小的模型，或是概要模型，打下一個基礎，然後慢慢的改進模型，或是在不在需要的時候丟棄這個模型。這就是遞增的思想。

◆令投資最大化

你的專案投資者為了開發出滿足自己需要的軟體，需要投入時間、金錢、裝置等各種資源。投資者應該可以選取最好的方式投資，也可以要求你的團隊不浪費資源。並且，他們還有最後的發言權，決定要投入多少的資源。如果是這些資源是你自己的，你希望你的資源被誤用嗎。

◆有目的的建模

對於自己的產出，例如模型、原始碼、文件，很多開發人員不是擔心它們是否夠詳細，就是擔心它們是否太過詳細，或擔心它們是否足夠正確。你不應該毫無意義的建模，應該先問問，為什麼要建立這個產出，為誰建立它。和建模有關，也許你應該更多的瞭解軟體的某個方面，也許為了保證專案的順利進行，你需要和高階經理交流你的方法，也許你需要建立描述系統的文件，使其他人能夠操作、維護、改進系統。如果你連為什麼建模，為誰建模都不清楚，你又何必繼續煩惱下去呢？首先，你要確定建模的目的以及模型的受眾，在此基礎上，再保證模型足夠正確和足夠詳細。一旦一個模型實現了目標，你就可以結束工作，把精力轉移到其它的工作上去，例如編寫程式碼以檢驗模型的運作。該項原則也可適用於改變現有模型：如果你要做一些改變，也許是一個熟知的模式，你應該有做出變化的正確理由（可能是為了支援一項新的需求，或是為了重構以保證簡潔）。關於該項原則的一個重要暗示是你應該要了解你的受眾，即便受眾是你自己也一樣。例如，如果你是為維護人員建立模型，他們到底需要些什麼？是厚達500頁的詳細文件才夠呢，還是10頁的工作總覽就夠了？你不清楚？去和他們談談，找出你想要的。

◆多種模型

開發軟體需要使用多種模型，因為每種模型只能描述軟體的單個方面，“要開發現今的商業應用，我們該需要什麼樣的模型？”考慮到現今的軟體的複雜性，你的建模工具箱應該要包容大量有用的技術（關於產出的清單，可以參閱AM的建模工件）。有一點很重要，你沒有必要為一個系統開發所有的模型，而應該針對系統的具體情況，挑選一部分的模型。不同的系統使用不同部分的模型。比如，和家裡的修理工作一樣，每種工作不是要求你用遍工具箱裡的每一個工具，而是一次使用某一件工具。又比如，你可能會比較喜歡某些工具，同樣，你可會偏愛某一種模型。有多少的建模工件可供使用呢，如果你想要了解這方面的更多細節，我在Be Realistic About the UML中列出了UML的相關部分，如果你希望做進一步的瞭解，可以參閱白皮書The Object Primer -- An Introduction to Techniques for Agile Modeling。

◆高質量的工作

沒有人喜歡爛糟糟的工作。做這項工作的人不喜歡，是因為沒有成就感；日後負責重構這項工作（因為某些原因）的人不喜歡，是因為它難以理解，難以更新；終端使用者不喜歡，是因為它太脆弱，容易出錯，也不符合他們的期望。

◆快速反饋

從開始採取行動，到獲得行動的反饋，二者之間的時間至關緊要。和其他人一共開發模型，你的想法可以立刻獲得反饋，特別是你的工作採用了共享建模技術的時候，例如白板、CRC卡片或即時貼之類的基本建模材料。和你的客戶緊密工作，去了解他們的的需求，去分析這些需求，或是去開發滿足他們需求的使用者介面，這樣，你就提供了快速反饋的機會。

◆軟體是你的主要目標

軟體開發的主要目標是以有效的方式，製造出滿足投資者需要的軟體，而不是製造無關的文件，無關的用於管理的工件，甚至無關的模型。任何一項活動（activity ），如果不符合這項原則，不能有助於目標實現的，都應該受到稽核，甚至取消。

◆輕裝前進

你建立一個工件，然後決定要保留它，隨著時間的流逝，這些工件都需要維護。如果你決定保留7個模型，不論何時，一旦有變化發生（新需求的提出，原需求的更新，團隊接受了一種新方法，採納了一項新技術...），你就需要考慮變化對這7個模型產生的影響並採取相應的措施。而如果你想要保留的僅是3個模型，很明顯，你實現同樣的改變要花費的功夫就少多了，你的靈活性就增強了，因為你是在輕裝前進。類似的，你的模型越複雜，越詳細，發生的改變極可能就越難實現（每個模型都更“沉重”了些，因此維護的負擔也就大了）。每次你要決定保留一個模型時，你就要權衡模型載有的資訊對團隊有多大的好處（所以才需要加強團隊之間，團隊和專案投資者之間的溝通）。千萬不要小看權衡的嚴重性。一個人要想過沙漠，他一定會攜帶地圖，帽子，質地優良的鞋子，水壺。如果他帶了幾百加侖的水，能夠想象的到的所有求生工具，一大堆有關沙漠的書籍，他還能過得去沙漠嗎？同樣的道理，一個開發團隊決定要開發並維護一份詳細的需求文件，一組詳細的分析模型，再加上一組詳細的架構模型，以及一組詳細的設計模型，那他們很快就會發現，他們大部分的時間不是花在寫原始碼上，而是花在了更新文件上。

宣言原則

最重要的是通過儘早和不斷交付有價值的軟體滿足客戶需要。

我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。

經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。

業務人員和開發者應該在整個專案過程中始終朝夕在一起工作。

圍繞鬥志高昂的人進行軟體開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。

在開發小組中最有效率也最有效果的資訊傳達方式是面對面的交談。

可以工作的軟體是進度的主要度量標準。

敏捷過程提倡可持續開發。出資人、開發人員和使用者應該總是維持不變的節奏。

對卓越技術與良好設計的不斷追求將有助於提高敏捷性。

簡單——儘可能減少工作量的藝術至關重要。

最好的架構、需求和設計都源自自我組織的團隊。

每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。

敏捷成功之道

隨機應變

要達到敏捷的成功—交付支撐業務的最佳軟體—軟體專家也可以引用這些規則。

自主權

專注於工作，交付正確的軟體，而不是被他人的憤怒情緒所影響。

分享經驗

構建完美軟體開發流程，並沒有統一的模式。但是在這個領域，敏捷技術，加上持續的應用和改進，都能夠達到敏捷的成功。

敏捷開發相關工具

Visual Studio Team Foundation Server

TFS，即團隊基礎伺服器是微軟應用程式生命週期管理伺服器，用於幫助團隊在Visual Studio的協作開發。最近，它進有了升級包括工作專案執行改進、富文字編輯器的改進，以及富文字編輯器中改善的超連結體驗。 TFS中的Kanban面板也做了改善，提升了可以錄入和跟蹤的專案數量，該伺服器現在有一個“利益相關者”許可，來規範伺服器的訪問許可權。

Atlassian Jira

Atlassian的是一個很流行的工具，主要用於跟蹤產品開發、幫助團隊整理問題、安排工具，以及記錄團隊行為。它Jira Agile外掛使開發人員更容易部署關鍵敏捷策略，這包括使用者故事開發、衝刺模組構建，以及視覺化的團隊活動。

Axosoft

Axosoft以前被稱為Axosoft OnTime Scrum，這一軟體套件有四個功能模組：Scrum、Bug追蹤器、幫助臺和Wiki。它是基於HTML5構建的，幫助開發團隊管理待辦事項列表、釋出和衝刺，帶有燃盡圖功能，有一個 管理儀表板用於跟蹤編碼和修改BUG的時間。

LeanKit

使用 LeanKit的團隊可以看到工作負載的分佈並匯出歷史資料。最近 LeanKit 進行了一次升級，包含單點登入功能 和附加報告功能，從而提供更細粒度的資料詳細資訊。

Planbox

Planbox 敏捷管理工具通過燃盡圖跟蹤程序，整合客戶反饋，它的目標人群很廣泛。最近它對應用的前端和後端都做的升級，添加了更強大的報告功能和新儀表盤，來提升專案速度。時間跟蹤特性和工具允許使用者得到所有他們在Planbox產生的資料。

敏捷開發實踐

敏捷建模（AM）在AM原則的基礎上定義了一組核心實踐（practice）和補充實踐，其中的某些實踐已經是極限程式設計（XP）中採用了的，並在 Extreme Programming Explained一書中有詳細的論述，和AM的原則一樣，我們在描述這組實踐時，將會注重於建模的過程，這樣你可以從另外一個角度來觀察這些已或XP採用的素材。

核心實踐

◆Stakeholder的積極參與 我們對XP的現場客戶（On-Site Customer）的概念做了一個擴充：開發人員需要和使用者保持現場的接觸；現場的使用者要有足夠的許可權和能力，提供建構中的系統相關的資訊；及時、中肯的做出和需求相關的決策；並決定它們的優先順序。AM把XP的“現場客戶”實踐擴充套件為“使project stakeholder積極參與專案”，這個project stakeholder的概念包括了直接使用者、他們的經理、高階經理、操作人員、支援人員。這種參與包括：高階經理及時的資源安排決策，高階經理的對專案的公開和私下的支援，需求開發階段操作人員和支援人員的積極參與，以及他們在各自領域的相關模型。

◆正確使用artifact 每個artifact都有它們各自的適用之處。例如，一個UML的活動圖（activity diagram）適合用於描述一個業務流程，反之，你資料庫的靜態結構，最好能夠使用物理資料（physical data）或資料模型（persistence model）來表示。在很多時候，一張圖表比原始碼更能發揮作用，一圖勝千言，同樣，一個模型也比1K的原始碼有用的多，前提是使用得當（這裡借用了 Karl Wieger的Software Requirements中的詞彙）。因為你在研究設計方案時，你可和同伴們和在白板上畫一些圖表來討論，也可以自己坐下來開發一些程式碼樣例，而前一種方法要有效的多。這意味著什麼？你需要了解每一種artifact的長處和短處，當你有眾多的模型可供選擇的時候，要做到這一點可沒有那麼容易。

◆集體所有制 只要有需要，所有人都可以使用、修改專案中的任何模型、任何artifact。

◆測試性思維 當你在建立模型的時候，你就要不斷的問自己，“我該如何測試它？”如果你沒辦法測試正在開發的軟體，你根本就不應該開發它。在現代的各種軟體過程中，測試和質保（quality assurance）活動都貫穿於整個專案生命週期，一些過程更是提出了“在編寫軟體之前先編寫測試”的概念（這是XP的一項實踐：“測試優先”）。

◆並行建立模型 由於每種模型都有其長處和短處，沒有一個模型能夠完全滿足建模的需要。例如你在收集需求時，你需要開發一些基本用例或使用者素材，一個基本使用者介面原型，和一些業務規則。再結合實踐切換到另外的Artifact，，敏捷建模者會發現在任何時候，同時進行多個模型的開發工作，要比單純集中於一個模型要有效率的多。

◆建立簡單的內容 你應該儘可能的使你的模型（需求、分析、架構、設計）保持簡單，但前提是能夠滿足你的project stakeholder的需要。這就意味著，除非有充分的理由，你不應該隨便在模型上畫蛇添足－－如果你手頭上沒有系統認證的功能，你就不應該給你的模型增加這麼一個功能。要有這樣的勇氣，一旦被要求新增這項功能，自己就能夠馬上做到。這和XP的實踐“簡單設計”的思想是一樣的。

◆簡單地建模 當你考慮所有你能夠使用的圖表（UML圖、使用者介面圖、資料模型等）時，你很快會發現，大部分時候你只需要這些圖表符號的一部分。一個簡單的模型能夠展示你想要了解的主要功能，例如，一個類圖，只要能夠顯示類的主要責任和類之間的關係就已經足夠了。不錯，編碼的標準告訴你需要在模型中加入框架程式碼，比如所有的get和set操作，這沒有錯，但是這能提供多少價值呢？恐怕很少。

◆公開展示模型 你應當公開的展示你的模型，模型的載體被稱為“建模之牆”（modeling wall）或“奇蹟之牆（wall of wonder）”。這種做法可以在你的團隊之間、你和你的project stakeholder之間營造出開放誠實的溝通氛圍，因為當前所有的模型對他們都是舉手可得的，你沒有向他們隱藏什麼。你把你的模型貼到建模之牆上，所有的開發人員和project stakeholder都可以看建模之牆上的模型，建模之牆可能是客觀存在的，也許是一塊為你的架構圖指定的白板，或是物理資料模型的一份列印輸出，建模之牆也可能是虛擬的，例如一個存放掃描好的圖片的internet網頁。如果你想要多瞭解一些相關的資料，你可以看看Ellen Gottesdiener的Specifying Requirements With a Wall of Wonder。

◆切換到另外的Artifact 當你在開發一個artifact（例如用例、CRC卡片、順序圖、甚至原始碼），你會發現你卡殼了，這時候你應當考慮暫時切換到另一個artifact。每一個artifact都有自己的長處和短處，每一個artifact都適合某一型別的工作。無論何時你發現你在某個artifact上卡殼了，沒辦法再繼續了，這就表示你應該切換到另一個artifact上去。舉個例子，如果你正在製作基本用例，但是在描述業務規則時遇到了困難，你就該試著把你的注意力轉移到別的artifact上去，可能是基本使用者介面原型、CRC模型，可能是業務規則、系統用例、或變化案例。切換到另一個artifact上去之後，你可能就立刻不再卡殼了，因為你能夠在另一個artifact上繼續工作。而且，通過改變你的視角，你往往會發現原先使你卡殼的原因。

◆小增量建模 採用增量開發的方式，你可以把大的工作量分成能夠釋出的小塊，每次的增量控制在幾個星期或一兩個月的時間內，促使你更快的把軟體交付給你的使用者，增加了你的敏捷性。

◆和他人一起建模 當你有目的建模時你會發現，你建模可能是為了瞭解某事，可能是為了同他人交流你的想法，或是為了在你的專案中建立起共同的願景。這是一個團體活動，一個需要大家有效的共同工作才能完成的活動。你發現你的開發團隊必須共同協作，才能建立一組核心模型，這對你的專案是至關重要的。例如，為了建立系統的映像和架構，你需要和同組成員一起建立所有人都贊同的解決方案，同時還要儘可能的保持它的簡單性。大多數時候，最好的方法是和另一些人討論這個問題。

◆用程式碼驗證 模型是一種抽象，一種能夠正確反映你正在構建的系統的某個方面的抽象。但它是否能執行呢？要知道結果，你就應該用程式碼來驗證你的模型。你已經用一些HTML頁面建立了接受付款地址資訊的草圖了嗎？編碼實現它，給你的使用者展示最終的使用者介面，並獲取反饋。你已經做好了表示一個複雜業務規則邏輯的UML順序圖了嗎？寫出測試程式碼，業務程式碼，執行測試以保證你做的是對的。永遠也別忘了用迭代的方法開發軟體（這是大多數專案的標準做法），也別忘了建模只是眾多工中的一個。做一會兒建模、做一會兒編碼、做一會兒測試（在其它的活動之中進行）。

◆使用最簡單的工具 大多數的模型都可以畫在白板上，紙上，甚至紙巾的背面。如果你想要儲存這些圖示，你可以用數碼相機把它們拍下來，或只是簡單的把他們轉錄到紙上。這樣做是因為大多數的圖表都是可以扔掉的，它們只有在你畫出模型並思考一個問題的時候才有價值，一旦這個問題被解決了它們就不再有意義了。這樣，白板和標籤往往成為你建模工具的最佳選擇：使用畫圖工具來建立圖表，給你重要的project stakeholder看。只有建模工具能夠給我們的程式設計工作提供價值（例如程式碼自動生成）時才使用建模工具。你可以這樣想：如果你正在建立簡單的模型，這些模型都是可以拋棄的。你建模的目的就是為了理解，一旦你理解了問題，模型就沒有存在的必要了，因此模型都是可以丟棄的，這樣，你根本就不必要使用一個複雜的建模工具。

補充實踐

◆使用建模標準 這項實踐是從XP的編碼標準改名而來，基本的概念是在一個軟體專案中開發人員應該同意並遵守一套共同的建模標準。遵守共同的編碼慣例能夠產生價值：遵守你選擇的編碼指南能夠寫出乾淨的程式碼，易於理解，這要比不這麼做產生出來的程式碼好得多。同樣，遵守共同的建模標準也有類似的價值。可供選擇的建模標準有很多，包括物件管理組織（OMG）制定的統一建模語言ML），它給通用的面向物件模型定義了符號和語義。UML開了一個好頭，但並不充分－就像你在Be Realistic About The UML中看到的，UML並沒有囊括所有可能的的建模artifact。而且，在關於建立清楚可看的圖表方面，它沒有提供任何建模風格指南。那麼，風格指南和標準之間的差別在何處呢。對原始碼來說，一項標準可能是規定屬性名必須以attributeName的格式，而風格指南可能是說在一個單元中的一段控制結構（一個if語句，一段迴圈）的程式碼縮排。對模型來說，一項標準可能是使用一個長方形對類建模，一項風格指南可能是圖中子類需要放在父類的下方。

◆逐漸應用模式 高效的建模者會學習通用的架構模式、設計模式和分析模式，並適當的把它們應用在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那樣，開發人員應當輕鬆的使用模式，逐漸的應用模式。這反映了簡單的價值觀。換言之，如果你猜測一個模式可能適用，你應當以這樣的方式建模：先實現目前你需要的最小的範圍，但你要為日後的重構留下伏筆。這樣，你就以一種可能的最簡單的方式實現了一個羽翼豐滿的模式了。就是說，不要超出你的模型。舉一個例子，在你的設計中，你發現有個地方適合使用GoF的Strategy模式，但這時候你只有兩個演算法要實現。最簡單的方法莫過於把演算法封裝為單獨的類，並建立操作，能夠選擇相應的演算法，以及為演算法傳遞相關的輸入。這是Strategy模式的部分實現，但你埋下了伏筆，日後如有更多的演算法要實現，你就可以重構你的設計。並沒有必要因為Strategy模式需要，就建立所有的框架。這種方法使你能夠輕鬆的使用模式。

◆丟棄臨時模型 你建立的大部分的模型都是臨時使用的模型－－設計草圖，低精度原型，索引卡片，可能架構/設計方案等等－－在它們完成了它們的目的之後就再不能提供更多的價值了。模型很快就變得無法和程式碼同步，這是正常的。你需要做出決定：如果“同步更新模型”的做法能夠給你的專案增添價值的話，那就同步更新模型；或者，如果更新它們的投入將抵消它們能夠提供的所有價值（即負收益），那就丟棄它們。

◆合同模型要正式 在你的系統需要的資訊資源為外部組織所控制的時候，例如資料庫，舊有系統和資訊服務，你就需要合同模型。一個合同模型需要雙方都能同意，根據時間，根據需要相互改變。合同模型的例子有API的細節文件，儲存形式描述，XML DTD或是描述共享資料庫的物理資料模型。作為法律合同，合同模型通常都需要你投入重要資源來開發和維護，以確保它的正確、詳細。你的目標是儘量使你係統的合同模型最少，這和XP的原則traveling light是一致的。注意你幾乎總是需要電子工具來建立合同模型，因為這個模型是隨時需要維護的。

◆為交流建模 建模的次要原因是為了和團隊之外的人交流或建立合同模型。因為有些模型是給團隊之外的客戶的，你需要投入時間，使用諸如文書處理器，畫圖工具包，甚至是那些“被廣告吹得天花亂墜”的CASE工具來美化模型。

◆為理解建模 建模的最重要的應用就是探索問題空間，以識別和分析系統的需求，或是比較和對照可能的設計選擇方法，以識別可能滿足需求的、最簡單的解決方案。根據這項實踐，你通產需要針對軟體的某個方面建立小的、簡單的圖表，例如類的生命週期圖，或螢幕順序，這些圖表通常在你完成目的（理解）之後就被丟棄。

◆重用現有的資源 這是敏捷建模者能夠利用的資訊財富。例如，也許一些分析和設計模式適合應用到系統上去，也許你能夠從現有的模型中獲利，例如企業需求模型，業務過程模型，物理資料模型，甚至是描述你使用者團體中的系統如何部署的模型。但是，儘管你常常搜尋一些比較正確的模型，可事實是，在大多陣列織中，這些模型要麼就不存在，要麼就已經過期了。

◆非到萬不得已不更新 你應當在你確實需要時才更新模型，就是說，當不更新模型造成的代價超出了更新模型所付出的代價的時候。使用這種方法，你會發現你更新模型的數量比以前少多了，因為事實就是，並不是那麼完美的模型才能提供價值的。我家鄉的街道圖已經使用了5年了，5年我自己街道並沒有改變位置，這張地圖對我來說還是有用的。不錯，我可以買一張新地圖，地圖是每年出一次的，但為什麼要這麼麻煩呢？缺少一些街道並沒有讓我痛苦到不得不投資買一份新地圖。簡單的說，當地圖還管用的時候，每年花錢買新地圖是沒有任何意義的。為了保持模型、文件和原始碼之間的同步，已經浪費了太多太多的時間和金錢了，而同步是不太可能做到的。時間和金錢投資到新的軟體上不是更好嗎？

確實不錯的主意

以下的實踐雖然沒有包括在AM中，但是可以做為AM的一份補充：

◆重構 這是一項編碼實踐。重構，就是通過小的變化，使你的程式碼支援新的功能，或使你的設計儘可能的簡單。從AM的觀點來看，這項實踐可以保證你在編碼時，你的設計乾淨、清楚。重構是XP的一個重要部分。

◆測試優先設計 這是一項開發實踐。在你開始編寫你的業務程式碼之前，你要先考慮、編寫你的測試案例。從AM的觀點來看，這項實踐強制要求你在寫程式碼之前先通盤考慮你的設計，所以你不再需要細節設 計建模了。測試優先設計是XP的一個重要部分。

敏捷開發名詞詳解

AM是一種態度，而不是一個說明性的過程。AM是敏捷建模者們堅持的價值觀、敏捷建模者們相信的原則、敏捷建模者們應用的實踐組成的集合。AM描述了一種建模的風格。當它應用於敏捷的環境中時，能夠提高開發的質量和速度，同時能夠避免過度簡化和不切實際的期望。AM可不是開發的“食譜”，如果你尋覓的是一些細節的指導，如建立UML順序圖或是畫出使用者介面流圖，你可以看看在建模Artifacts中列出的許多建模書籍，我特別推薦我的書The Object Primer 2/e(儘管這有失公允）。

AM是對已有方法的補充，而不是一個完整的方法論。AM的主要焦點是在建模上，其次是文件。也就是說，AM技術在你的團隊採用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基礎上能夠提高建模的效果。AM同樣也可以用於那些傳統過程（例如Unified Process），儘管這種過程較低的敏捷性會使得AM不會那麼成功。

AM是一種有效的共同工作的方法，能夠滿足Project Stakeholder的需要。敏捷開發者們和Project Stakeholder進行團隊協作，他們輪流在系統開發中扮演著直接、主動的角色。在“敏捷”的字典中沒有“我”這個單詞。

AM是有效的，而且也已開始有效。當你學習到更多的AM知識時，有件事對你來說可能不好接受，AM近乎無情的注重有效性。AM告訴你：要使你的 Project Stakeholder的投資最大化；當有清晰的目的以及需要了解受眾的需要時要建立模型或文件；運用合適的工件來記錄手頭的情形；不論何時都儘可能建立簡單的模型。

AM不是靈丹妙藥。敏捷建模是改進眾多專家軟體開發成果的有效技術，充其量也就是這樣了。它並不是什麼了不得的靈丹妙藥，能夠解決你開發中的所有問題。如果你努力的工作；如果你專注其上；如果打心眼兒裡接受它的價值觀、它的原則、它的實踐；你就可以改進你做為一個開發人員的效果。

AM是面向一般的開發人員的，但並不是要排斥有能力的人。AM的價值觀、原則和實踐都簡單易懂，其中的很多內容，可能你都已經採用或期待多年了。應用AM技術並不是要你去練水上飄，但你需要有一些基本的軟體開發技能。AM最難的就是它逼著你去學習更廣泛的建模技術，這是個長期的、持續性的活動。學習建模在一開始可能很難，但你可以試著一次學習一樣技術來完成你的學習。

AM並不是要反對文件。文件的建立和維護都會增大專案涉眾的投資。敏捷文件儘可能的簡單，儘可能的小，目的只集中在和開發的系統有直接關係的事情上，充分了解受眾的需要。

AM也不是要反對CASE工具。敏捷建模者使用那些能夠幫助開發人員提高效果，提升價值的工具。而且，他們還盡力使用那些能夠勝任工作的最簡單的工具。

何時是敏捷的？

要想了解AM，你需要了解模型和敏捷模型之間的區別。模型是一個抽象的概念，它描述了一個的問題的一個或多個方面，或是處理這個問題可能的解決方案。傳統意義上，模型被認為是圖表加上相應的文件。然而那不夠直觀的artifact，也可以被視為模型，例如CRC卡片集，單條或多條業務規則的文字描述，或是業務流程的一段結構化英文描述。一個敏捷模型就是一個剛剛足夠好的模型。但是你怎麼知道什麼時候模型才是剛剛足夠好呢？當敏捷模型顯現出如下的特性時，它就是剛剛足夠好的：

敏捷模型實現了它們的目的。有時你為溝通而建模，或許你需要把你工作的範圍告訴高階經理；有時你為理解而建模，或許你需要確定一個設計策略，實現一組Java類。一個敏捷模型是否足夠好，要看它是不是滿足了建立它時的初衷。

敏捷模型是可理解的。敏捷模型要能為其預期聽眾所理解。使用使用者能夠理解的業務語言來描述需求模型，反之，技術架構模型則需要使用開發人員熟悉的技術術語。你所使用的建模符號會影響易懂性－－如果你的使用者不瞭解UML用例圖中的符號的含義，那用例圖對使用者就沒有任何價值。這樣的話，要麼使用另一種方法，要麼教授使用者學習建模技術。風格問題同樣也會影響易懂性，例如避免交叉線。雜亂的圖表比清晰的圖表難懂。模型的細節程度（見下文），也會影響易懂性，因為相較一個不那麼詳細的模型來說，一個過於詳細的模型要難於理解。簡單（見下文）同樣是影響易懂性的一個因素。

敏捷開發

敏捷模型是足夠正確的。模型通常都不需要100%正確，只要足夠正確就行了。舉個例子，如果一張街道地圖漏畫了一條街道，或是它標示某條街道是通行的，但你發現它已經關閉維修了，那你會不會扔掉你的地圖開始在城裡飆車犯罪呢？不太可能。你會考慮更新你的地圖，你可能會拿出筆來自己做修改或是去當地的商店買一張最新版的地圖（你原來的那張過期了）。也許你還是會接受那張雖不完美但仍可使用的地圖，因為它對你來說已經足夠好了。你還是可以用這張地圖四處轉轉，因為它還是個正確的模型，標記出了大部分街道的位置。你在發現這張地圖不正確的時候，你沒有立刻扔掉它，原因是你根本不在乎它是否完美。類似的，當你在需求模型、資料模型中發現錯誤的時候，你也會選擇更新或是接受－－雖不完美但已經足夠好了。有些專案成員能夠容忍這種不正確而有些則不能：這取決於專案的特性，每個團隊成員的特性，組織的特性。充分正確性既和模型的聽眾有關，也和你要處理的問題有關。

敏捷模型是足夠一致的。一個敏捷模型並不需要和自己（或其它有用的artifact）保持完全的一致。如果一個用例在它的一個步驟中顯式的呼叫了另一個用例，那麼相應的用例圖需要用UML的 <> 版型來標記這兩個用例之間的關係。然而，你看了看圖表，發現它們並沒有這樣做，天哪！用例和圖之間不一致！危險！太危險了！紅色警報！快逃命呀！等一下，你的用例模型是有不一致的地方，但也沒到世界末日啊。是的，理想情況下，你的所有artifact最好是能夠完全一致，但這通常是不可能的。當我開發一個簡單的商用系統時，我通常都可以容忍部分的不一致。但有時我是不能容忍這種不一致的。最有力的佐證就是1999年 NASA發射火星太空探測器時採用了精密的測量系統。要樹立一個觀點，敏捷模型只要足夠一致就行了，你通常不需要使用那麼完美的模型。

關於正確性和一致性，很明顯要考慮權衡問題。如果你要維護一個artifact（我們稱之為“保管”），隨著時間的流逝，你需要投入資源來更新它。否則它很快會就會過期，對你就沒用了。例如，我可以容忍一張地圖示錯了一兩條街道，但是我絕對無法容忍一張地圖中四分之三的街道都標錯了。這就需要權衡了，進行足夠的努力，保證artifact足夠正確。過多不必要的努力反而會減緩專案的進度，而投入不足就沒有辦法保證artifact的有效性。

敏捷模型有足夠的細節。一張路線圖並不需要標記出每條街道上的每棟房子。那會有太多的細節，使得地圖難以使用。然而，在修路的時候，我想施工人員一定會有這條街道的詳細地圖，包括每幢建築、下水道、電線盒等足夠的細節，這樣的地圖才是有用的。但是這張地圖並不用標記出每個院子和通向它們的路線。因為這樣又太繁瑣了。足夠的細節和聽眾有關，也和他們使用模型的目的有關－－司機需要的是顯示道路的地圖，施工人員需要的是顯示土木工程細節的地圖。

考慮一個架構模型，可能一組畫在白板上的圖表就足夠了－－專案的進行中再對它們更新，也許你需要用CASE 工具來生成一些圖表，也許這些圖表還需要有詳細的文件，這依賴於環境。不同的專案有不同的需要。在每一個例子中，實際上你都是在開發、維護一個有足夠的細節的架構模型，只是這個“足夠的細節”的概念和環境有關。

敏捷模型能提供正面價值。對專案中的任一artifact，一個基本的要求是它們能夠提供正面價值。一個架構模型給你的專案帶來的價值是不是能夠超過開發它、維護它（可選）的總成本？一個架構模型能夠堅定你們團隊為之努力的願景，所以它當然是有價值的。但是，如果它的成本超過了這個價值，那就是說，它無法提供正面價值。投入100,000美元去開發一個詳細的、重量級的文件化架構模型，而它的效用，只需一些畫在白板上的圖表就能夠達到，這些圖只需要花你 5,000美元，看看，這是多麼輕率的做法。

敏捷模型要儘可能的簡單。只要能夠達到目的，你應當努