快速敏捷開發方法

Ⅰ 常用的敏捷開發模式有哪些

敏捷開發模式是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。

它們的具體名稱、理念、過程、術語都不盡相同，相對於"非敏捷"，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重做為軟體開發中人的作用。

傳統的開發模式是基於「計劃」開展的，而因為大多數項目周期通常較長，這種計劃模式在實施過程中會遇到很多問題，比如項目需求一開始並不明朗，項目團隊也不一定完整，這時候計劃本身都是存在瑕疵的，那項目開發管控過程可想而知。

而敏捷開發模式則提供了一種新的模式，即小步快走，不斷調整，快速迭代!你需求不明朗沒關系，我們先做一小丟丟，對了就繼續不對也不至於說損失很大，調整方向也來得及，通過這種模式不斷糾正最後不斷趨近客戶最終想要的東西。

既然是新的開發模式，那自然要匹配新的工具——低代碼開發平台，這種將常用功能控制項組件化，常用業務場景模板化的開發工具和傳統底層編碼模式相比，開發周期更短，開發成本更低，業務調整更加靈活，國內專注這一塊的廠商也挺多。

天翎MYAPPS，普元，起步，天縱等老牌廠商已經耕耘了將近二十年，隨著低代碼概念的火熱，又出現了搭搭雲，簡道雲，宜搭，氚雲等新晉品牌。

連微軟上個月也宣布推出低代碼產品並將商用。他們有的擅長復雜業務流程處理，有的擅長數據填報分析，有的擅長網站小程序搭建，在實踐領域已經具備規模並日漸發展成熟。

敏捷開發模式在管理層面對項目開發模式產生了積極影響，低代碼開發平台從技術層面對項目開發產生了積極影響，兩者結合一定能開出美麗的花。

Ⅱ 敏捷開發的敏捷開發的原則

1. 快速迭代
相對那種半年一次的大版本發布來說，小版本的需求、開發和測試更加簡單快速。一些公司，一年僅發布僅2~3個版本，發布流程緩慢，它們仍採用瀑布開發模式，更嚴重的是對敏捷開發模式存在誤解。
2. 讓測試人員和開發者參與需求討論
需求討論以研討組的形式展開最有效率。研討組，需要包括測試人員和開發者，這樣可以更加輕松定義可測試的需求，將需求分組並確定優先順序。 同時，該種方式也可以充分利用團隊成員間的互補特性。如此確定的需求往往比開需求討論大會的形式效率更高，大家更活躍，參與感更強。
3. 編寫可測試的需求文檔
開始就要用「用戶故事」（User Story）的方法來編寫需求文檔。這種方法，可以讓我們將注意力放在需求上，而不是解決方法和實施技術上。過早的提及技術實施方案，會降低對需求的注意力。
4. 多溝通，盡量減少文檔
任何項目中，溝通都是一個常見的問題。好的溝通，是敏捷開發的先決條件。在圈子裡面混得越久，越會強調良好高效的溝通的重要性。
團隊要確保日常的交流，面對面溝通比郵件強得多。
5. 做好產品原型
建議使用草圖和模型來闡明用戶界面。並不是所有人都可以理解一份復雜的文檔，但人人都會看圖。
6. 及早考慮測試
及早地考慮測試在敏捷開發中很重要。傳統的軟體開發，測試用例很晚才開始寫，這導致過晚發現需求中存在的問題，使得改進成本過高。較早地開始編寫測試用例，當需求完成時，可以接受的測試用例也基本一塊完成了。

Ⅲ 怎樣讓團隊快速開始敏捷開發

試試Teamin。
我們之前做項目的時候，陷入bug裡面怎麼也搞不完，一直發不了版本，被老闆罵很多次。 後來用Teamin管項目，很快就找到節奏，每周都能固定發布版本。總之，很贊！

Ⅳ 快速迭代就是敏捷開發嗎

敏捷開發和迭代開發是不同的
迭代式開發也被稱作迭代增量式開發或迭代進化式開發，是一種與傳統的瀑布式開發相反的軟體開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。
什麼是迭代式開發？
每次只設計和實現這個產品的一部分,
逐步逐步完成的方法叫迭代開發,
每次設計和實現一個階段叫做一個迭代。

在迭代式開發方法中，整個開發工作被組織為一系列的短小的、
固定長度（如3周）的小項目，被稱為一系列的迭代。
每一次迭代都包括了需求分析、設計、實現與測試。
採用這種方法，開發工作可以在需求被完整地確定之前啟動，
並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。
再通過客戶的反饋來細化需求，並開始新一輪的迭代。
迭代式開發的優點：
1. 降低風險。
2. 得到早期用戶反饋。
3. 持續的測試和集成。
4. 使用變更。
5. 提高復用性。
敏捷軟體開發又稱敏捷開發， 是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不 盡相同，相對於「非敏捷」，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織 型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發中人的作用。

Ⅳ 如何藉助「敏捷開發」快速實現MVP

在敏捷實踐體系中，迭代交付模式是敏捷開發的核心要素。敏捷開發方法有很多，Scrum提供了迭代管理和持續改進的框架，如圖5-15所示。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。

圖5-16 用戶需求列表（產品功能需求）

步驟2. 召開計劃會議和制定開發計劃（計劃版）

Scrum Master負責組織召開計劃會議，產品經理和團隊一起根據需求的重要性、開發量來確定開發優先順序，做工作量預估，制定迭代開發計劃（從需求列表中挑選出高優先順序 Story（用戶需求）[張樂飛3] 作為本次迭代完成的目標，這個目標的時間周期是1~4個星期，然後把這個Story進行細化，形成一個Sprint Backlog（迭代代辦事項）[張樂飛4] ）。開發團隊一旦接受這些開發任務，就應該准時完成，不得修改交付標准。

步驟3. 執行迭代計劃（任務板）

首先，你需要確定每次Sprint（開發沖刺）[張樂飛5] 的周期，短的周期可以更頻繁的發布產品版本，因此可以從客戶那裡更迅速地收到反饋，修正錯誤。這個周期一般為1~4周，當然，你可以根據團隊成熟程度或迭代任務確定一個合適的迭代周期，比如2周。這樣可以讓開發人員更投入地工作。

所謂Sprint，就是在一定時間內全身心投入開發。這個階段通常用看板來管理需求，每個卡片[張樂飛6] 就是一個開發任務，工作完成後，可以將卡片移到下一個階段，用看板管理需求，如圖5-17所示：你也可以使用專門的軟體來管理看板，例如國外的Jira、國內的明道。

圖5-17 敏捷開發項目管理看板

在沖刺中，每一天都會舉行項目狀況會議，被稱為「每日站會」。會議在固定地點和每天的同一時間舉行，對於遲到者團隊常常會制定懲罰措施（例如罰款，做俯卧撐，在脖子上掛橡膠雞玩具）。不論團隊規模大小，會議被限制在15分鍾。所有出席者都應站立，每個人都必須發言。會議的目標是討論當前的任務的狀態，一個推薦的匯報形式是：我昨天已經做了什麼？我接下來准備做什麼？現在遇到什麼阻礙和問題？注意在會議中團隊成員不必要針對每個問題進行探討，只是作為一個重要信息的反饋通道，具體問題相關成員在會後私下當面溝通解決，這樣更加高效，避免浪費問題無關成員的時間。

步驟4. 產品測試和演示

因為每次的Sprint目標就是交付一個可以用的產品特性，所以測試工作非常重要。有不少方法可以減少測試周期，比如，你可以減少需求數量，或者讓開發參與測試。當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行演示會議，也稱為評審會議。產品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum團隊的成員都要向他們演示自己完成的軟體產品（這個會議非常重要，一定不能取消）。

步驟5. 回顧會議和下一個Sprint計劃

每一個沖刺完成後，都會舉行一次沖刺回顧會議。回顧會議也稱為總結會議，會議的時間限制在4小時，以輪流發言方式進行，每個人都要發言，哪裡做得好、哪裡不好都可以提出，總結並討論改進的地方，放入下一輪Sprint計劃。

Ⅵ 如何通過「敏捷開發」模式開發MVP產品

敏捷開發以用戶的需求進化為核心，採用迭代、循序漸進的方法進行產品開發。在敏捷開發中，產品項目在構建初期被切分成多個子產品，各個子產品的成果都經過測試，具備可視、可集成和可運行使用的特徵。換言之，就是把一個大產品分為多個相互聯系，但也可獨立運行的小產品模塊或功能，並分別完成，在此過程中產品一直處於可使用狀態。

在2001年，17位敏捷方法論的擁護者和倡議者聚集在猶他州的雪鳥滑雪場，起草了一份陳述敏捷組織原則的文件。這份文件基本上代表了不同敏捷方法論的共同點，我們稱之為「敏捷宣傳」，也叫做敏捷軟體開發宣言，是指導以人為中心的迭代軟體開發方法，具體四個核心價值內容如圖5-14所示。

圖5-14 敏捷開發宣傳

1. 個體和互動高於流程和工具

項目是通過人來完成的，流程和工具可以幫助人，但絕不能自行完成工作。雖然，過程和工具都是好東西，但是它們有時也會成為障礙。面對面的直接溝通，比一些流程性的文件和工具溝通，效率要高出很多。當然最好的是，在溝通後就多方達成的共識形成一個簡要性的文檔備錄。

2. 工作的軟體高於詳盡的文檔

可用軟體的價值是很重要的，因為軟體是為業務目標提供支持的，是可用軟體(而不是文件)為客戶和也會[張樂飛1] 傳遞了高價值。一般來說，一個敏捷項目的進展情況是由開發了多少可用軟體來跟蹤和報告的。但不是說文檔一無是處，適量的文檔在絕大多數的項目中是有益的和必要的。敏捷通過尋求「剛好足夠」的文檔來避免這種情況。其中的原則是任何文件的創建都應與為客戶創造的價值直接掛鉤，且不論該價值體現在現狀還是將來。

3. 客戶合作高於合同談判

這個[張樂飛2] 價值觀的核心是越接近你的客戶越好。客戶最清楚他想要什麼，即使在需求明確過程中也會包含一些試驗和錯誤。在合同談判期間，試圖避免所有的嘗試和錯誤不發生是不現實的，也是徒勞的。定位你與客戶的關系很重要，你是選擇對抗你的客戶還是選擇與你的客戶一起為接近方案努力而使每個人都受益？敏捷團隊更願意和客戶在同一方向一起使勁而不是把力氣花在背離客戶的方向。

4. 響應變化高於遵循計劃

任何一個曾在軟體項目工作過的人都知道這些項目的本質就是變化。即使底層的技術也在快速變化，新的途徑和可能性在不斷的被打開。對變化響應的速度就決定你在市場上的靈活性，循規蹈矩的做事將被市場甩在後面，永遠慢市場半拍，慢慢你的市場會被蠶食掉。

當你讀到這個宣言，你會發現它具有最高原則性，因為敏捷方法論在最高層面上是一致的，但到具體細節上每種方法都會不同。除了敏捷宣言之外，還有12條准則的支持文件，為敏捷宣言提供了更多的擴充細節。

l准則1：我們的最高目標是，通過盡早和持續地交付有價值的軟體來滿足客戶。敏捷團隊可以很快將可用軟體交付到客戶手中，並且是開放式地快速更新，給客戶帶來優先順序最高地價值。

l准則2：歡迎對需求提出變更，即使在項目開發後期；要善於利用需求變更，幫助客戶獲得競爭優勢。傳統項目管理中地一個原則是設法去影響和控制會導致變化地因素。敏捷項目管理預期到需求會發生變化，並在實際過程中歡迎擁抱這些變化，即使這些變化發生在項目後期。迅速應對和適應變化能給客戶帶來顯著地競爭優勢，從而應對新的機遇。

l准則3：要不斷交付可用的軟體，周期從幾周到幾個月不等，且越短越好。不同的敏捷方法論採用不同的迭代周期，但都是相對較短的。關鍵是能快速把可用的軟體交付到客戶手上並能利用軟體獲得有意義的回報。較短的迭代周期可以使團隊持續關注客戶的價值。[張樂飛3]

l准則4：在項目過程中，業務人員、產品經理與開發人員必須在一起。敏捷項目管理，讓業務人員、產品經理和開發人員彼此靠近，並時常讓他們在同一個地方一起工作，通過這樣的方式讓業務人員和開發人員之間沒有隔閡。是因為業務人員和開發人員的共同目標就是通過可用的軟體向客戶傳遞價值。

l准則5：要善於激勵項目人員，給他們所需要的環境和支持，並相信他們能夠完成任務。傳統項目管理，常對員工進行微觀管理，不僅告訴他們要做什麼，還告訴他們如何做，無意間形成自上而下的管理方式。敏捷項目建立了一支強有力的團隊並積極避免微觀管理，要求一個自律的團隊，自發告知開發人員做什麼。提供相關資源，給予鼓勵，相信團隊能夠完成任務。

l准則6：無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。非正式口頭的溝通在敏捷項目管理中遠比正式的書面溝通更普遍。其想法是兩個人坐在一起為一個解決方案努力會比他們用郵件來來往往或交換文件更有效率。面對面溝通是敏捷項目管理的精髓。這種溝通是公開的，任何團隊成員都可以自由參與對話。

l准則7：可用的軟體是衡量進度的主要指標。計劃和文件可能是有用的，但是當最根本的目標發生變化時，它們就可能失去應有的價值。傳統項目往往極其糾結的是，項目的不斷更新使得文件成為一種負擔。真正的價值是通過結果來表達的，結果又是通過可用的軟體來呈現的。

l准則8：敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恆久穩定的進展速度。可持續開發的焦點是在團隊身上，他們會努力保持一個穩定的可持續的進展速度，從而使得團隊成員不會在迭代周期的尾端匆忙趕工。理想的目標是保持一種可持續的速度，使團隊成員不會感到過度的壓力和筋疲力盡，而是能夠保持在一個理想的強度下工作。

l准則9：對技術的精益求精及對設計的不斷完善將提升敏捷性。設計的越完善，維護起來就越簡單，即使遇到變化。穩定和優質的項目會比劣質的項目更加允許團隊快速應對變化。

l准則10：要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術，被所有的敏捷方法所擁護，尤其是精益方法。[張樂飛4] 關鍵點對客戶價值保持關注和毫無猶豫的削減不增加價值的活動。保持簡單不只是一種願望，它使最基本的原則。

l准則11：最佳的架構、需求和設計出自自我組織的團隊。自我組織是敏捷團隊的核心元素之一。當一個團隊是自我組織型的時候，說明該團隊自己去決定工作如何分配及誰去做某個特定的工作，而不是人力資源部門或管理層來決定。不僅小團隊是自我組織的，較大的跨職能團隊也可以是自我組織的。

l准則12：團隊要定期反省如何能夠做到更有效，並相應的調整團隊的行為。敏捷項目中最可預見的事情就是變更。傳統項目里當項目或階段完成時開會總結是最常見的做法。而敏捷試著通過更頻繁的回顧來完成這項工作。在一個回顧活動中，團隊查看各迭代周期中已完成的工作或發布，並評估下一次如何改進他們的做法。每日站立會議即每天簡單碰頭15分鍾是另一項協調團隊努力方向、團隊自我評定和自我調整的重要方式。

敏捷開發的業務目標是更早的交付價值，價值的交付不僅僅是早晚上線兩天的問題，而是更早上線能夠給自己和客戶帶來更大的價值越晚交付，價值越低。更快不是絕對速度的快，而是指時間上的早，即通過迭代交付實現分批和更早的交付。同時靈活地響應變化，當今世界跨界顛覆的案例數不勝數，一個企業的核心能力不再是已有的能力有多強，而是靈活響應變化，快速學習的能力有多好。

Ⅶ 如何敏捷開發 如何快速迭代

快速迭代，版本更新快，所以要考慮降低項目風險，確保正確的方向。
敏捷開發能夠縮短項目的反饋周期，因其將項目分成了若干個迭代周期，每個迭代周期結束都能立即反饋。且通過不斷的溝通，還能減少理解上的偏差，配合反饋，減少誤解，從而降低修正錯誤的代價。且每個迭代周期的結束都能接受驗證，從而能快速的適應變化，及時的適應新的需求，保證產品的正確性。

Ⅷ 敏捷開發模式的對比其它方法

敏捷方法有時候被誤認為是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。
適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化. 兩者沒有很多的共同點，瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。
瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。
相對來講，敏捷方法則在幾周或者幾個月的時間內完成相對較小的功能，強調的是能將盡早將盡量小的可用的功能交付使用，並在整個項目周期中持續改善和增強。
有人可能在這樣小規模的范圍內的每次迭代中使用瀑布式方法，另外的人可能將選擇各種工作並行進行。

Ⅸ 敏捷方法的敏捷開發

敏捷開發（agile development）是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。簡言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟體一直處於可使用狀態。
敏捷開發是全新理論嗎？答案莫衷一是。細心的人們可以發現，敏捷開發其實借鑒了大量軟體工程中的方法。迭代與增量開發，這兩種在任何一本軟體工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有更多。
改善，而非創新。敏捷開發可理解為在原有軟體開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。「在敏捷軟體開發的過程中，我們每兩周都會得到一個可以工作的軟體，」Fowler介紹，「這種非常短的循環，使終端客戶可以及時、快速地看到他們花錢構建的軟體是一個什麼樣的結果。」
也許是因為時間關系，Fowler只說出了這些優勢中的一部分。允許開發過程中的需求變化、通過早期迭代可以較早發現風險、使代碼重用變得可行、減少項目返工……借鑒了眾多先進方法和豐富經驗，擁有的眾多優勢使得敏捷開發看來已經成為解決軟體危機的標准答案。
問題與思考然而，我們不得不面對的現實卻是，模式與方法的優化並不意味著問題的終結。作為一種開發模式，敏捷開發同樣需要面對眾多挑戰。
大項目的拆分意味著更多子項目的出現，協調這些同步或非同步推進的子項目，合理的資源調配都將變得更加復雜。另外，在當前項目和項目組普遍「增容」的情況下，遇到的問題同樣成倍增長。人的重要性被提到了更高的高度，而缺乏有效協調手段，減少人員流動和項目變更對整個項目造成的影響也將成為一大挑戰……新方法帶來眾多便利的同時，也相應引發了幾乎同樣多的問題。
敏捷開發（agile development）概念從2004年初開始廣為流行。Bailar非常支持這一理論，他採取了敏捷方式組建團隊：Capital One的敏捷團隊包括3名業務人員、兩名操作人員和5～7名IT人員，其中包括1個業務信息指導（實際上是業務部門和IT部門之間的翻譯者）；另外，還有一個由項目經理和至少80名開發人員組成的團隊。這些開發人員都曾被Bailar送去參加過敏捷開發的培訓，具備相關的技能。
每個團隊都有自己的敏捷指導（Bailar聘用了20個敏捷指導），他的工作是關注流程並提供建議和支持。最初提出的需求被歸納成一個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個項目階段，團隊人員密切合作，開發有規律地停頓--在9周開發過程中停頓3～4次，以評估過程及決定需求變更是否必要。在Capital One，大的IT項目會被拆分成多個子項目，安排給各敏捷團隊，這種方式在敏捷開發中叫蜂巢式（swarming），所有過程由一名項目經理控制。
為了檢驗這個系統的效果，Bailar將項目拆分，從舊的瀑布式開發轉變為並列式開發，形成了敏捷開發所倡導的精幹而靈活的開發團隊，並將開發階段分成30天一個周期，進行沖刺--每個沖刺始於一個啟動會議，到下個沖刺前結束。
在Bailar將其與傳統的開發方式做了對比後，他感到非常興奮--敏捷開發使開發時間減少了30%～40%，有時甚至接近50%，提高了交付產品的質量。不過，有些需求不能用敏捷開發來處理。 Bailar承認，敏捷開發也有局限性，比如對那些不明確、優先權不清楚的需求或處於較快、較便宜、較優的三角架構中卻不能排列出三者優先順序的需求。此外，他覺得大型項目或有特殊規則的需求的項目，更適宜採用傳統的開發方式。盡管描述需求一直是件困難的事，但經過陣痛之後，需求處理流程會讓CIO受益匪淺。
敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作、響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為： 個體和交互 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文檔 客戶合作 勝過 合同談判 響應變化 勝過 遵循計劃 並提出了以下遵循的原則： 我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。 經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。 在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。 圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。 在團隊內部，最具有效果並富有效率的傳遞信息的方法，就是面對面的交談。 工作的軟體是首要的進度度量標准。 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。 不斷地關注優秀的技能和好的設計會增強敏捷能力。 簡單是最根本的。 最好的構架、需求和設計出於自組織團隊。 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。 一、敏捷開發方法
（一） 說明 本文是閱讀Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些筆記和想法，Agile Software Development是一組軟體開發方法的總稱，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷開發方法又稱為「輕量級」開發方法。
下面這段話摘自Martin Fowler的一篇文章：
從無到繁重再到敏捷多數軟體開發仍然是一個顯得混亂的活動，即典型的「邊寫邊改」 （code and fix）。設計過程充斥著短期的，即時的決定，而無完整的規劃。這種模式對小系統開發其實很管用，但是當系統變得越大越復雜時，要想加入新的功能就越來越困難。同時錯誤故障越來越多，越來越難於排除。一個典型的標志就是當系統功能完成後有一個很長的測試階段，有時甚至有遙遙無期之感，從而對項目的完成產生嚴重的影響。 我們使用這種開發模式已有很長時間了，不過我們實際上也有另外一種選擇，那就是「正規方法」（methodology）。這些方法對開發過程有著嚴格而詳盡的規定，以期使軟體開發更有可預設性並提高效率，這種思路是借鑒了其他工程領域的實踐。 這些正規方法已存在了很長時間了，但是並沒有取得令人矚目的成功，甚至就沒怎麼引起人們的注意。對這些方法最常聽見的批評就是它們的官僚繁瑣，要是按照它的要求來，那有做太多的事情需要做，而延緩整個開發進程。所以它們通常被認為是「繁瑣滯重型」方法，或Jim HighSmith 所稱的「巨型」（monumental)方法。 作為對這些方法的反叛，在過去幾年中出現了一類新方法。盡管它們還沒有正式的名稱，但是一般被稱為「敏捷型」方法。對許多人來說，這類方法的吸引之處在於對繁文縟節的官僚過程的反叛。它們在無過程和過於繁瑣的過程中達到了一種平衡，使得能以不多的步驟過程獲取較滿意的結果。 敏捷型與滯重型方法有一些顯著的區別。其中一個顯而易見的不同反映在文檔上。敏捷型不是很面向文檔，對於一項任務，它們通常只要求盡可能少的文檔。從許多方面來看，它們更象是「面向源碼」（code-oriented）。事實上，它們認為最根本的文檔應該是源碼。 但是，我並不以為文檔方面的特點是敏捷型方法的根本之點。文檔減少僅僅是個表象，它其實反映的是更深層的特點： ? 敏捷型方法是「適配性」而非「預設性」。 重型方法試圖對一個軟體開發項目在很長的時間跨度內作出詳細的計劃，然後依計劃進行開發。這類方法在計劃制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。 ? 敏捷型方法是「面向人」的(people-oriented) 而非「面向過程」的 (process-oriented)。 它們試圖使軟體開發工作順應人的天性而非逆之。它們強調軟體開發應當是一項愉快的活動。我認為以上兩個特點很好的概括了敏捷開發方法的核心思想：適應變化和以人為中心
（二） 方法背後的思想
Alistair Cockburn在Agile Software Development中講述了敏捷開發方法背後的思想
人們掌握過程（process）可以分為3個階段：1 following 遵循一個定義好的process2 detaching 知道不同process的適用范圍，在不同的場合使用不同的process3 fluent 不關心是否遵循特定的process，知道在什麼情況下採用什麼動作
軟體開發是一個充滿發明和交流的協作性游戲(cooperative game of invertion and communication)。軟體開發的首要目標是生產出軟體，遵循特定的過程和模型只是手段，只要傳遞了足夠的信息，手段是次要的。交流的效果要遠遠重於交流的形式（Effect of communication is more important than the form of communication）。一般軟體開發有兩個目標：1 盡快的生產出軟體2 為下一個team或項目做准備，有時這兩個目標是矛盾的，我們要在這兩個目標之間尋求平衡
在軟體開發中，人的因素要遠遠大於過程和技術。人是有缺陷的：1 容易犯錯誤，因此必須在錯誤擴散之前找到並改正錯誤2 當覺得可能失去較多的時候，不願意冒險3 重新構造而不願意重復使用已有的東西4 難於堅持一個習慣
針對個人因素的幾個建議：1 具體的模型較抽象的模型更容易理解2 從一個例子開始是容易的3 通過觀察他人的成果學習4 要有足夠的不受打擾的時間5 分配的工作要與個人意向，能力匹配6 不正確的獎勵會有壞作用，從長期看個人興趣比獎勵更重要，培養在工作中的自豪感：1) pride in work參與工作的自豪感，通常參與一個重要的工作會有自豪感2) pride in accomplishment 完成工作的自豪感，長期未完的工作會使士氣低落3)pride in contribution 為他人貢獻的自豪感7 鼓勵關心其他人的工作和整體的工作
在一個團隊之間，交流是最重要的，實踐證明面對面的實時的交流是最有效的，對交流的延誤會損失信息，白板是最好的交流工具，交流工具的先進並不能提高交流效果。文檔的作用是記錄和備忘，不能通過文檔交流。
敏捷開發方法要避免的過程設計的幾個常見錯誤1 對所有的項目使用同一種過程2 沒有彈性3 過於沉重4 增加不必要的「必須完成」（「should do」 is really should？）5 沒有經過實踐檢驗
敏捷開發方法過程設計的幾個原理：1 交互的面對面的交流是代價最小，最迅速的交換信息的方法2 超過實際需要的過程是浪費的3 大的團隊需要重量級方法4 處理重大問題的項目需要重量級方法強調5 增加反饋和交流可以減少中間產品和文檔的需求6 輕量級方法更強調理解（understanding）,自律（discipline）和技能(skill)，重量級方法更強調文檔（documentation），過程（process）和正式（formality）understanding指整個團隊關於項目的全部知識，包括討論的過程，documentation只能記錄其中的一部分discipline是指個人主動的完成工作，process指個人根據指令完成工作skill指具有良好技能的人可以省略中間的產品，formality指必須按照規定步驟完成工作
7 確定開發中間的瓶徑，提高它的效率對於瓶徑處的工作應該盡量加快，減少重復，（使用更熟練的人，使用更多的人，使用更好的工具，使瓶徑處的工作的深入盡量穩定）對於非瓶徑處的工作可以多一些重復，在輸入還不確定的情況下也可以盡早開始。
這些原理的幾個結論：1 向一個項目增加人員要花費較大代價（constly），因為原有人員和新人員之間的交流要花費大量時間2 團隊的規模經常是跳躍的，例子：需要6個熟練的程序員，但是只有4個，於是增加不熟練的程序員，結果團隊的大量時間花費在培訓不熟練的程序員上面，最後增加到了20個不熟練的程序員。3 應該側重於提高團隊的技能而不是擴充團隊4 對不同的項目使用不同的過程5 在適用的條件下，輕量級的方法優於重量級的方法6 對不同的項目要裁減過程
敏捷開發方法的原則是「剛剛好」（Light and Sufficient）

Ⅹ 敏捷開發方式有哪些

敏捷開發包括一系列的方法，主流的有如下七種：
XP
XP（極限編程）的思想源自 Kent Beck和Ward Cunningham在軟體項目中的合作經歷。XP注重的核心是溝通、簡明、反饋和勇氣。因為知道計劃永遠趕不上變化，XP無需開發人員在軟體開始初期做 出很多的文檔。XP提倡測試先行，為了將以後出現bug的幾率降到最低。
SCRUM
SCRUM是一種迭代的增量化過程，用於產品開發或工作管理。它是一種可以集合各種開發實踐的經驗化過程框架。SCRUM中發布產品的重要性高於一切。
該方法由Ken Schwaber和 Jeff Sutherland 提出，旨在尋求充分發揮面向對象和構件技術的開發方法，是對迭代式面向對象方法的改進。
Crystal Methods
Crystal Methods（水晶方法族）由Alistair Cockburn在20實際90年代末提出。之所以是個系列，是因為他相信不同類型的項目需要不同的方法。雖然水晶系列不如XP那樣的產出效率，但會有更多的人能夠接受並遵循它。
FDD
FDD （Feature-Driven Development，特性驅動開發）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同開發，是一套針對中小型軟體開發項目的開發模式。此外，FDD是一個模型驅動的快速迭代開發過程，它強調的是簡化、實用、 易於被開發團隊接受，適用於需求經常變動的項目。
ASD
ASD（Adaptive Software Development，自適應軟體開發）由Jim Highsmith在1999年正式提出。ASD強調開發方法的適應性（Adaptive），這一思想來源於復雜系統的混沌理論。ASD不象其他方法那樣 有很多具體的實踐做法，它更側重為ASD的重要性提供最根本的基礎，並從更高的組織和管理層次來闡述開發方法為什麼要具備適應性。
DSDM
DSDM（動態系統開發方法）是眾多敏捷開發方法中的一種，它倡導以業務為核心，快速而有效地進行系統開發。實踐證明DSDM是成功的敏捷開發方法之一。在英國，由於其在各種規模的軟體組織中的成功，它已成為應用最為廣泛的快速應用開發方法。
DSDM不但遵循了敏捷方法的原理，而且也適合那些成熟的傳統開發方法有堅實基礎的軟體組織。
輕量型RUP
RUP其實是個過程的框架，它可以包容許多不同類型的過程， Craig Larman 極力主張以敏捷型方式來使用RUP。他的觀點是:目前如此眾多的努力以推進敏捷型方法，只不過是在接受能被視為RUP 的主流OO開發方法而已。