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看。只有建模工具能夠給我們的程式設計工作提供價值（例如**自動生成）時才使用建模工具。你可以這樣想：如果你正在建立簡單的模型， 這些模型都是可以拋棄的。你建模的目的就是為了理解，一旦你理解了問題，模型就沒有存在的必要了，因此模型都是可以丟棄的，這樣，你根本就不必要使用乙個 複雜的建模工具。
全面認識敏捷建模思想 1
1 敏捷建模的價值觀 2 敏捷建模的原則 3 敏捷建模的實踐 4 敏捷建模是 不是 什麼？5 模型何時是敏捷的？6 你是在敏捷建模嗎？7 敏捷建模何時是有 沒有 意義的？8 am的實踐是如何組合的？9 那，你想成為乙個敏捷建模者嗎?10 建模的誤區 1 敏捷建模的價值觀 am的價值觀包括了xp的四個...
爬蟲全面認識
爬蟲 其實爬蟲就像乙個瀏覽器瀏覽網上的資訊 只是我們稱之為爬蟲是因為它不是人為而是機器自動獲取某些程式設計師設定的信 息，對於某些 它不想讓爬蟲獲取訊息，我們稱之為反爬。裡面的具體一些技術，我會一 一解釋和貼原始碼 文章只是自己學習沒有任何商業用途。1 爬蟲用到的語言 python2 html js...
敏捷建模介紹
敏捷建模方法的重點有 敏捷建模遵循敏捷宣言和原則。正因為如此，敏捷建模可以是一種實踐，你可以把它新增到你的敏捷工具箱裡。模型能用來溝通和理解。我們力爭用簡單的工具建立簡單的模型。擁抱簡單。我們知道需求是變化的，因此我們在建立模型的時候要擁抱變化。我們的重點是交付軟體，而不是交付模型。模型能帶來價值的...