3、敏捷建模的實踐
敏捷建模（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看。只有建模工具能夠給我們的編程工作提供價值（例如代碼自動生成）時才使用建模工具。你可以這樣想：如果你正在創建簡單的模型，
這些模型都是可以拋棄的。你建模的目的就是爲了理解，一旦你理解了問題，模型就沒有存在的必要了，因此模型都是可以丟棄的，這樣，你根本就不必要使用一個
複雜的建模工具。