敏捷開發一些百科。

簡單的說，敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也價值觀
編輯

敏捷建模（Agile Modeling，AM）的價值觀包括了XP（Extreme Programming：極限編程）的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴展了第五個價值觀：謙遜。
敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提升開發效率和響應能力。除了原則和實踐，模式也是很重要的，多研究模式及其應用可使你更深層次的理解敏捷開發。
溝通

建模不但可以促進你團隊內部的開發人員之間溝通、還可以促進你的團隊和你的project stakeholder之間的溝通。
簡單

畫一兩張圖表來代替幾十甚至幾百行的代碼，經過這種方法，建模成爲簡化軟件和軟件（開發）過程的關鍵。這一點對開發人員而言很是重要－它簡單，容易發現出新的想法，隨着你（對軟件）的理解的加深，也可以很容易的改進。
反饋

Kent Beck在Extreme Programming Explained中有句話講得很是好：「過分自信是編程的職業病，反饋則是其處方。」經過圖表來交流你的想法，你能夠快速得到反饋，並可以按照建議行事。
勇氣

勇氣很是重要，當你的決策證實是不合適的時候，你就須要作出重大的決策，放棄或重構（refactor）你的工做，修正你的方向。
謙遜

最優秀的開發人員都擁有謙遜的美德，他們總能認識到本身並非無所不知的。事實上，不管是開發人員仍是客戶，甚至全部的 project stakeholder，都有他們本身的專業領域，都可以爲項目作出貢獻。一個有效的作法是假設參與項目的每個人都有相同的價值，都應該被尊重。可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。
原則
主張簡單
核心原則

◆主張簡單
當從事開發工做時，你應當主張最簡單的解決方案就是最好的解決方案。不要過度構建
敏捷開發
敏捷開發
（overbuild）你的軟件。用AM的說法就是，若是你如今並不須要這項額外功能，那就不要在模型中增長它。要有這樣的勇氣：你如今沒必要要對這個系統進行過度的建模（over-model），只要基於現有的需求進行建模，往後需求有變動時，再來重構這個系統。儘量的保持模型的簡單。
◆擁抱變化
需求時刻在變，人們對於需求的理解也時刻在變。項目進行中，Project stakeholder可能變化，會有新人加入，也會有舊人離開。Project stakeholder的觀點也可能變化，你努力的目標和成功標準也有可能發生變化。這就意味着隨着項目的進行，項目環境也在不停的變化，所以你的開發方法必需要可以反映這種現實。
◆你的第二個目標是可持續性
即使你的團隊已經把一個可以運轉的系統交付給用戶，你的項目也還多是失敗的－－實現Project stakeholder的需求，其中就包括你的系統應該要有足夠的魯棒性（robust ），可以適應往後的擴展。就像Alistair Cockburn常說的，當你在進行軟件開發的競賽時，你的第二個目標就是準備下一場比賽。可持續性可能指的是系統的下一個主要發佈版，或是你正在構建的系統的運轉和支持。要作到這一點，你不只僅要構建高質量的軟件，還要建立足夠的文檔和支持材料，保證下一場比賽能有效的進行。你要考慮不少的因素，包括你現有的團隊是否是還可以參加下一場的比賽，下一場比賽的環境，下一場比賽對你的組織的重要程度。簡單的說，你在開發的時候，你要能想象到將來。
◆遞增的變化
和建模相關的一個重要概念是你不用在一開始就準備好一切。實際上，你就算想這麼作也不太可能。並且，你不用在模型中包容全部的細節，你只要足夠的細節就夠了。沒有必要試圖在一開始就創建一個囊括一切的模型，你只要開發一個小的模型，或是概要模型，打下一個基礎，而後慢慢的改進模型，或是在不在須要的時候丟棄這個模型。這就是遞增的思想。
◆令Stakeholder投資最大化
你的project stakeholder爲了開發出知足本身須要的軟件，須要投入時間、金錢、設備等各類資源。stakeholder應該能夠選取最好的方式投資，也能夠要求你的團隊不浪費資源。而且，他們還有最後的發言權，決定要投入多少的資源。若是是這些資源是你本身的，你但願你的資源被誤用嗎。
◆有目的的建模
對於本身的artifact，例如模型、源代碼、文檔，不少開發人員不是擔憂它們是否夠詳細，就是擔憂它們是否太過詳細，或擔憂它們是否足夠正確。你不該該毫無心義的建模，應該先問問，爲何要創建這個artifact，爲誰創建它。和建模有關，也許你應該更多的瞭解軟件的某個方面，也許爲了保證項目的順利進行，你須要和高級經理交流你的方法，也許你須要建立描述系統的文檔，使其餘人可以操做、維護、改進系統。若是你連爲何建模，爲誰建模都不清楚，你又何須繼續煩惱下去呢？首先，你要肯定建模的目的以及模型的受衆，在此基礎上，再保證模型足夠正確和足夠詳細。一旦一個模型實現了目標，你就能夠結束目前的工做，把精力轉移到其它的工做上去，例如編寫代碼以檢驗模型的運做。該項原則也可適用於改變現有模型：若是你要作一些改變，也許是一個熟知的模式，你應該有作出變化的正確理由（多是爲了支持一項新的需求，或是爲了重構以保證簡潔）。關於該項原則的一個重要暗示是你應該要了解你的受衆，即使受衆是你本身也同樣。例如，若是你是爲維護人員創建模型，他們到底須要些什麼？是厚達500頁的詳細文檔纔夠呢，仍是10頁的工做總覽就夠了？你不清楚？去和他們談談，找出你想要的。
◆多種模型
開發軟件須要使用多種模型，由於每種模型只能描述軟件的單個方面，「要開發現今的商業應
敏捷開發
敏捷開發
用，咱們該須要什麼樣的模型？」考慮到現今的軟件的複雜性，你的建模工具箱應該要包容大量有用的技術（關於artifact的清單，能夠參閱AM的建模artifact）。有一點很重要，你沒有必要爲一個系統開發全部的模型，而應該針對系統的具體狀況，挑選一部分的模型。不一樣的系統使用不一樣部分的模型。好比，和家裏的修理工做同樣，每種工做不是要求你用遍工具箱裏的每個工具，而是一次使用某一件工具。又好比，你可能會比較喜歡某些工具，一樣，你可會偏心某一種模型。有多少的建模 artifact可供使用呢，若是你想要了解這方面的更多細節，我在Be Realistic About the UML中列出了UML的相關部分，若是你但願作進一步的瞭解，能夠參閱白皮書The Object Primer -- An Introduction to Techniques for Agile Modeling。
◆高質量的工做
沒有人喜歡爛糟糟的工做。作這項工做的人不喜歡，是由於沒有成就感；往後負責重構這項工做（由於某些緣由）的人不喜歡，是由於它難以理解，難以更新；最終用戶不喜歡，是由於它太脆弱，容易出錯，也不符合他們的指望。
◆快速反饋
從開始採起行動，到得到行動的反饋，兩者之間的時間相當緊要。和其餘人一共開發模型，你的想法能夠馬上得到反饋，特別是你的工做採用了共享建模技術的時候，例如白板、CRC卡片或即時貼之類的基本建模材料。和你的客戶緊密工做，去了解他們的的需求，去分析這些需求，或是去開發知足他們需求的用戶界面，這樣，你就提供了快速反饋的機會。
◆軟件是你的主要目標
軟件開發的主要目標是以有效的方式，製造出知足project stakeholder須要的軟件，而不是製造無關的文檔，無關的用於管理的artifact，甚至無關的模型。任何一項活動（activity ），若是不符合這項原則，不能有助於目標實現的，都應該受到審覈，甚至取消。
◆輕裝前進
你創建一個artifact，而後決定要保留它，隨着時間的流逝，這些artifact都須要維護。若是你決定保留7個模型，不論什麼時候，一旦有變化發生（新需求的提出，原需求的更新，團隊接受了一種新方法，採納了一項新技術...），你就須要考慮變化對這7個模型產生的影響並採起相應的措施。而若是你想要保留的僅是3個模型，很明顯，你實現一樣的改變要花費的功夫就少多了，你的靈活性就加強了，由於你是在輕裝前進。相似的，你的模型越複雜，越詳細，發生的改變很可能就越難實現（每一個模型都更「沉重」了些，所以維護的負擔也就大了）。每次你要決定保留一個模型時，你就要權衡模型載有的信息對團隊有多大的好處（因此才須要增強團隊之間，團隊和project stakeholder之間的溝通）。千萬不要小看權衡的嚴重性。一我的要想過沙漠，他必定會攜帶地圖，帽子，質地優良的鞋子，水壺。若是他帶了幾百加侖的水，可以想象的到的全部求生工具，一大堆有關沙漠的書籍，他還能過得去沙漠嗎？一樣的道理，一個開發團隊決定要開發並維護一份詳細的需求文檔，一組詳細的分析模型，再加上一組詳細的架構模型，以及一組詳細的設計模型，那他們很快就會發現，他們大部分的時間不是花在寫源代碼上，而是花在了更新文檔上。
宣言原則

最重要的是經過儘早和不斷交付有價值的軟件知足客戶須要。
咱們歡迎需求的變化，即便在開發後期。敏捷過程可以駕馭變化，保持客戶的競爭優點。
常常交付能夠工做的軟件，從幾星期到幾個月，時間尺度越短越好。
業務人員和開發者應該在整個項目過程當中始終朝夕在一塊兒工做。
圍繞鬥志高昂的人進行軟件開發，給開發者提供適宜的環境，知足他們的須要，並相信他們可以完成任務。
在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。
能夠工做的軟件是進度的主要度量標準。
敏捷過程提倡可持續開發。出資人、開發人員和用戶應該老是維持不變的節奏。
對卓越技術與良好設計的不斷追求將有助於提升敏捷性。
簡單——儘量減小工做量的藝術相當重要。
最好的架構、需求和設計都源自自我組織的團隊。
每隔必定時間，團隊都要總結如何更有效率，而後相應地調整本身的行爲。[1]
補充原則

◆內容比表示更重要
一個模型有不少種的表示方法。例如，能夠經過在一張紙上放置即時貼的方法來創建一個用戶界面規格（基本/低精度原型）。它的表現方式能夠是紙上或白板上的草圖，能夠是使用原型工具或編程工具創建和傳統的原型，也能夠是包括可視界面和文本描述的正式文檔。有一點頗有意思，一個模型並不必定就是文檔。它們一般做爲其它artifact的輸入，例如源代碼，但沒必要把它們處理爲正式的文檔，即便是使用CASE工具創建的複雜的圖表，也是同樣。要認識到一點，要利用建模的優勢，而不要把精力花費在建立和維護文檔上。
◆三人行必有我師
你不可能徹底精通某項技術，你老是有機會學習新的知識，拓展知識領域。把握住這個機會，和他人一同工做，向他人學習，試試作事的新方式，思考什麼該作，什麼不應作。技術的變化很是的快，現有的技術（例如Java）以難以置信的速度在改進，新的技術（例如C#和.NET）也在有規律的產生。現存開發技術的改進相對會慢一些，但也在持續的改進中－－計算機產業屬於工業，咱們已經掌握了其中的試驗基本原理，但咱們還在不斷的研究，不斷的實踐，不斷的改進咱們對它的瞭解。咱們工做在一個變化是屢見不鮮的產業中，咱們必須經過訓練、教育、思考、閱讀、以及和他人合做，抓住每個機會學習新的處事之道。
◆瞭解你的模型
由於你要使用多種模型，你須要瞭解它們的優缺點，這樣纔可以有效的使用它們。
◆瞭解你的工具
軟件（例如做圖工具、建模工具）有各類各樣的特色。若是你打算使用一種建模工具，你就應當瞭解何時適合用它，何時不適合用它。
◆局部調整
你的軟件開發方法要可以反映你的環境，這個環境包括組織特徵，project stakeholder的特徵，項目自身的特徵。有可能受其影響的問題包括：你使用的建模技術（也許你的用戶堅持要看到一個細節的用戶界面，而不是初始草圖或基本原型）；你使用的工具（可能你沒有數字照相機的預算，或是你已經擁有某個CASE工具的license）；你遵循的軟件過程（你的組織採用XP的開發過程，或是RUP，或是本身的過程）。所以你會調整你的方法，這種調整多是針對項目的，也多是針對我的的。例如，有些開發人員傾向於使用某一類工具，有些則不用。有些人在編碼上花大力氣，基本不作建模，有些則寧肯在建模上多投入一些時間。
◆開放誠實的溝通
人們須要可以自由的提出建議，並且人們還應該可以感覺到他們是自由的。建議多是和模型有關的想法：也許是某些人提出某部分新的設計方法，或是某個需求的新的理解；建議還多是一些壞消息，例如進度延誤；或僅僅是簡單的工做情況報告。開放誠實的溝通是人們可以更好的決策，由於做爲決策基礎的信息會更加準確。
◆相信直覺
有時你會感受到有什麼地方出問題了，或是感受什麼地方有不一致的狀況，或是某些東西感受不是很對。其實，這種感受頗有可能就是事實。隨着你的軟件開發的經驗的增長，你的直覺也會變得更敏銳，你的直覺下意識之間告訴你的，極可能就是你工做的關鍵之處。若是你的直覺告訴你一項需求是沒有意義的，那你就不用投入大量的精力和用戶討論這方面的問題了。若是你的直覺告訴你有部分的架構不能知足你的須要，那就須要創建一個快速技術原型來驗證你的理論。若是你的直覺告訴設計方法A要比設計方法B好，並且並無強有力的理由支持你選擇某一個方法，那就儘管選擇方法A。勇氣的價值就已經告訴你，若是將來證明你的直覺是錯的，你也有能力來挽救這種狀況。你應該有這種自信，這很重要。