1、敏捷建模的價值觀
2、敏捷建模的原則
3、敏捷建模的實踐
4、敏捷建模是（不是）什麼？
5、模型何時是敏捷的？
6、你是在敏捷建模嗎？
7、敏捷建模何時是有（沒有）意義的？
8、am的實踐是如何組合的？
9、那，你想成為乙個敏捷建模者嗎?
10、建模的誤區
1、敏捷建模的價值觀
am的價值觀包括了xp的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴充套件了第五個價值觀：謙遜。
◆溝通建模不但能夠促進你團隊內部的開發人員之間溝通、還能夠促進你的團隊和你的project stakeholder之間的溝通。
◆簡單畫一兩張圖表來代替幾十甚至幾百行的**，通過這種方法，建模成為簡化軟體和軟體（開發）過程的關鍵。這一點對開發人員而言非常重要－它簡單，容易發現出新的想法，隨著你（對軟體）的理解的加深，也能夠很容易的改進。
◆反饋kent beck在extreme programming explained中有句話講得非常好：「樂觀是程式設計的職業病，反饋則是其處方。」通過圖表來交流你的想法，你可以快速獲得反饋，並能夠按照建議行事。
◆勇氣勇氣非常重要，當你的決策證明是不合適的時候，你就需要做出重大的決策，放棄或重構（refactor）你的工作，修正你的方向。
◆謙遜最優秀的開發人員都擁有謙遜的美德，他們總能認識到自己並不是無所不知的。事實上，無論是開發人員還是客戶，甚至所有的 project stakeholder，都有他們自己的專業領域，都能夠為專案做出貢獻。乙個有效的做法是假設參與專案的每乙個人都有相同的價值，都應該被尊重。
2、敏捷建模的原則
敏捷建模（am）定義了一系列的核心原則和輔助原則，它們為軟體開發專案中的建模實踐奠定了基石。其中一些原則是從xp中借鑑而來，在 extreme programming explained中有它們的詳細描述。而xp中的一些原則又是源於眾所周知的軟體工程學。復用的思想隨處可見！基本上，本文中對這些原則的闡述主要側重 於它們是如何影響著建模工作；這樣，對於這些借鑑於xp的原則，我們可以從另乙個角度來看待。
核心原則：
◆主張簡單
當從事開發工作時，你應當主張最簡單的解決方案就是最好的解決方案。不要過分構建（overbuild）你的軟體。用am的說法 就是，如果你現在並不需要這項額外功能，那就不要在模型中增加它。要有這樣的勇氣：你現在不必要對這個系統進行過分的建模（over-model），只要 基於現有的需求進行建模，日後需求有變更時，再來重構這個系統。盡可能的保持模型的簡單。
◆擁抱變化
需求時刻在變，人們對於需求的理解也時刻在變。專案進行中，project stakeholder可能變化，會有新人加入，也會有舊人離開。project stakeholder的觀點也可能變化，你努力的目標和成功標準也有可能發生變化。這就意味著隨著專案的進行，專案環境也在不停的變化，因此你的開發方 法必須要能夠反映這種現實。
◆你的第二個目標是可持續性
即便你的團隊已經把乙個能夠運轉的系統交付給使用者，你的專案也還可能是失敗的－－實現project stakeholder的需求，其中就包括你的系統應該要有足夠的魯棒性（robust ），能夠適應日後的擴充套件。就像alistair cockburn常說的，當你在進行軟體開發的競賽時，你的第二個目標就是準備下一場比賽。可持續性可能指的是系統的下乙個主要發布版，或是你正在構建的 系統的運轉和支援。要做到這一點，你不僅僅要構建高質量的軟體，還要建立足夠的文件和支援材料，保證下一場比賽能有效的進行。你要考慮很多的因素，包括你 現有的團隊是不是還能夠參加下一場的比賽，下一場比賽的環境，下一場比賽對你的組織的重要程度。簡單的說，你在開發的時候，你要能想象到未來。
◆遞增的變化
和建模相關的乙個重要概念是你不用在一開始就準備好一切。實際上，你就算想這麼做也不太可能。而且，你不用在模型中包容所有的 細節，你只要足夠的細節就夠了。沒有必要試圖在一開始就建立乙個囊括一切的模型，你只要開發乙個小的模型，或是概要模型，打下乙個基礎，然後慢慢的改進模 型，或是在不在需要的時候丟棄這個模型。這就是遞增的思想。
◆令stakeholder投資最大化
你的project stakeholder為了開發出滿足自己需要的軟體，需要投入時間、金錢、裝置等各種資源。stakeholder應該可以選取最好的方式投資，也可以 要求你的團隊不浪費資源。並且，他們還有最後的發言權，決定要投入多少的資源。如果是這些資源是你自己的，你希望你的資源被誤用嗎。
◆有目的的建模
對於自己的artifact，例如模型、源**、文件，很多開發人員不是擔心它們是否夠詳細，就是擔心它們是否太過詳細，或 擔心它們是否足夠正確。你不應該毫無意義的建模，應該先問問，為什麼要建立這個artifact，為誰建立它。和建模有關，也許你應該更多的了解軟體的某 個方面，也許為了保證專案的順利進行，你需要和高階經理交流你的方法，也許你需要建立描述系統的文件，使其他人能夠操作、維護、改進系統。如果你連為什麼 建模，為誰建模都不清楚，你又何必繼續煩惱下去呢？首先，你要確定建模的目的以及模型的受眾，在此基礎上，再保證模型足夠正確和足夠詳細。一旦乙個模型實 現了目標，你就可以結束目前的工作，把精力轉移到其它的工作上去，例如編寫**以檢驗模型的運作。該項原則也可適用於改變現有模型：如果你要做一些改變， 也許是乙個熟知的模式，你應該有做出變化的正確理由（可能是為了支援一項新的需求，或是為了重構以保證簡潔）。關於該項原則的乙個重要暗示是你應該要了解 你的受眾，即便受眾是你自己也一樣。例如，如果你是為維護人員建立模型，他們到底需要些什麼？是厚達500頁的詳細文件才夠呢，還是10頁的工作總覽就夠 了？你不清楚？去和他們談談，找出你想要的。
全面認識敏捷建模思想 3
3 敏捷建模的實踐 敏捷建模 am 在am原則的基礎上定義了一組核心實踐 practice 和補充實踐，其中的某些實踐已經是極限程式設計 xp 中採用了的，並在 extreme programming explained一書中有詳細的論述，和am的原則一樣，我們在描述這組實踐時，將會注重於建模的過程...
爬蟲全面認識
爬蟲 其實爬蟲就像乙個瀏覽器瀏覽網上的資訊 只是我們稱之為爬蟲是因為它不是人為而是機器自動獲取某些程式設計師設定的信 息，對於某些 它不想讓爬蟲獲取訊息，我們稱之為反爬。裡面的具體一些技術，我會一 一解釋和貼原始碼 文章只是自己學習沒有任何商業用途。1 爬蟲用到的語言 python2 html js...
敏捷建模介紹
敏捷建模方法的重點有 敏捷建模遵循敏捷宣言和原則。正因為如此，敏捷建模可以是一種實踐，你可以把它新增到你的敏捷工具箱裡。模型能用來溝通和理解。我們力爭用簡單的工具建立簡單的模型。擁抱簡單。我們知道需求是變化的，因此我們在建立模型的時候要擁抱變化。我們的重點是交付軟體，而不是交付模型。模型能帶來價值的...