王老師讓撰寫一篇部落格關於敏捷開發方法，讓我們深入理解敏捷開發方法。
我看來，在爆發軟體危機以來，我們一直沒有找到乙個完美的方法解決。敏捷開發是在人們探索中由以前的開發方法中探索和總結出來的，雖然不完美，但是正在逐步適應。
敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效率和響應能力。除了原則和實踐，模式也是很重要的，多研究模式及其應用可以使你更深層次的理解敏捷開發。
敏捷建模（am）定義了一系列的核心原則和輔助原則，它們為軟體開發專案中的建模實踐奠定了基石。其中一些原則是從xp中借鑑而來，在extreme programming explained中有它們的詳細描述。而xp中的一些原則又是源於眾所周知的軟體工程學。復用的思想隨處可見！基本上，本文中對這些原則的闡述主要側重於它們是如何影響著建模工作；這樣，對於這些借鑑於xp的原則，我們可以從另乙個角度來看待。
簡單，變化，持續性，迭代，成本。。。這是敏捷開發中常見的幾個詞。
簡單：當從事開發工作時，你應當主張最簡單的解決方案就是最好的解決方案。不要過分構建（overbuild）你的軟體。用am的說法就是，如果你現在並不需要這項額外功能，那就不要在模型中增加它。要有這樣的勇氣：你現在不必要對這個系統進行過分的建模（over-model），只要基於現有的需求進行建模，日後需求有變更時，再來重構這個系統。盡可能的保持模型的簡單。
變化：需求時刻在變，人們對於需求的理解也時刻在變。專案進行中，project stakeholder可能變化，會有新人加入，也會有舊人離開。project stakeholder的觀點也可能變化，你努力的目標和成功標準也有可能發生變化。這就意味著隨著專案的進行，專案環境也在不停的變化，因此你的開發方法必須要能夠反映這種現實。
持續：即便你的團隊已經把乙個能夠運轉的系統交付給使用者，你的專案也還可能是失敗的－－實現project stakeholder的需求，其中就包括你的系統應該要有足夠的魯棒性（robust ），能夠適應日後的擴充套件。就像alistair cockburn常說的，當你在進行軟體開發的競賽時，你的第二個目標就是準備下一場比賽。可持續性可能指的是系統的下乙個主要發布版，或是你正在構建的系統的運轉和支援。要做到這一點，你不僅僅要構建高質量的軟體，還要建立足夠的文件和支援材料，保證下一場比賽能有效的進行。你要考慮很多的因素，包括你現有的團隊是不是還能夠參加下一場的比賽，下一場比賽的環境，下一場比賽對你的組織的重要程度。簡單的說，你在開發的時候，你要能想象到未來。
迭代：和建模相關的乙個重要概念是你不用在一開始就準備好一切。實際上，你就算想這麼做也不太可能。而且，你不用在模型中包容所有的細節，你只要足夠的細節就夠了。沒有必要試圖在一開始就建立乙個囊括一切的模型，你只要開發乙個小的模型，或是概要模型，打下乙個基礎，然後慢慢的改進模型，或是在不在需要的時候丟棄這個模型。這就是遞增的思想。
成本：你的project stakeholder為了開發出滿足自己需要的軟體，需要投入時間、金錢、裝置等各種資源。stakeholder應該可以選取最好的方式投資，也可以要求你的團隊不浪費資源。並且，他們還有最後的發言權，決定要投入多少的資源。如果是這些資源是你自己的，你希望你的資源被誤用嗎。
除此之外，還有乙個重要的詞是團隊，什麼是團隊，這也是敏捷開發必須需要考慮的，團隊不是一群人做乙個人的事。
團隊中必須有人是領導者，有人是執行者。好比僚機和戰鬥機的關係。團隊的每日站立會議也很重要，團隊要變成自己領導自己，從消極的聽從指揮變成自己主動，是團隊的主導不是個人的主導，向團隊利益最大化的方向發展。
宣言原則
最重要的是通過盡早和不斷交付有價值的軟體滿足客戶需要。
我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。
經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。
業務人員和開發者應該在整個專案過程中始終朝夕在一起工作。
圍繞鬥志高昂的人進行軟體開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。
在開發小組中最有效率也最有效果的資訊傳達方式是面對面的交談。
可以工作的軟體是進度的主要度量標準。
敏捷過程提倡可持續開發。出資人、開發人員和使用者應該總是維持不變的節奏。
對卓越技術與良好設計的不斷追求將有助於提高敏捷性。
簡單——盡可能減少工作量的藝術至關重要。
最好的架構、需求和設計都源自自我組織的團隊。
每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。
敏捷開發方法
敏捷方法一覽 各種敏捷方法的要求千差萬別，但是它們都遵循以下12條原則。1 最重要的是通過盡早地 頻繁地交付有價值的軟體來滿足客戶 盡早交付有價值的軟體。2 頻繁地交付可執行的軟體，數週或者數月交付一次 頻繁發布新版本。3 可執行的軟體是衡量進展的主要標準 軟體比文件更重要 4 接受需求變更，即便是...
常用敏捷開發方法
摘自 輕鬆scrum之旅 1 極限程式設計 extreme programming，xp 極限程式設計的思想源自 kent beck 和 ward cunningham 在軟體專案中的合作經歷。在這裡，extreme 的意思是希望將軟體開發過程中一些好的方法發揮到極致。xp 注重的核心在於 溝通 簡...
敏捷開發方法綜述
敏捷開發的出現是由於在2000年左右，許多團隊採用龐大，重型的過程方法的趨勢在逐漸增長，一批自稱敏捷聯盟的業界專家概括出了可以讓軟體團隊具有快速工作，響應變化能力的價值觀和原則。影響至今的就是他們的敏捷聯盟宣言 個體和互動勝過過程和工具 可以工作的軟體勝過面面俱到的文件 客戶合作勝過合同談判 響應變...