敏捷軟體開發

敏捷軟體開發（Agile software development），又稱敏捷開發，是一種應對快速變化需求的軟體開發模式，描述了一套軟體開發的價值和原則。此模式中，自組織的跨功能團隊在緊密的協作中發掘使用者或顧客的需求以及改良解決方案，此模式也強調適度的計畫、進化開發、提前交付與持續改進，並且鼓勵快速與靈活的面對開發與變更。這些原則支援許多軟體開發方法的定義和持續進化。

「敏捷」（Agile 或 agile）一詞由「敏捷軟體開發宣言」（Manifesto for agile software development）中開始普及，「敏捷軟體開發宣言」定義了相關的價值和原則。敏捷軟體開發的框架不斷的發展，兩個最廣泛被使用的是 Scrum 與 Kanban。

詞源

敏捷一詞來源於 2001 年初美國猶他州雪鳥滑雪聖地的一次敏捷方法發起者和實踐者（他們發起組成了敏捷聯盟）的聚會。

迭代和增量式軟體開發方法可以追溯到 1957 年。進化式專案管理和適應性軟體開發出現在 1970 年代初期。在 1990 年代，因針對重量級的軟體開發方法的批評，而發展了許多輕量化的軟體開發方法、計畫與細微化開發管理。包含了，從 1991 年開始的迅速應用程式開發、從 1994 年開始的統一處理程序與動態系統開發法（DSDM）、從 1995 年的 Scrum、從 1996 年的水晶清透法與極限程式設計法、1997 年的功能驅動開發。雖然那些開發法都起源於敏捷開發宣言之前，但都統稱為敏捷軟體開發法。在此同時，製造業與航空業也遭遇相同變化。

在 2001 年，十七名軟體開發人員在猶他州的雪鳥度假村會面，討論這些輕量級的開發方法，並由 Jeff Sutherland，Ken Schwaber 和 Alistair Cockburn 發起，一同發布了「敏捷軟體開發宣言」。

在 2005 年，由 Alistair Cockburn 和 Jim Highsmith 領導的小組編寫了一份專案管理原則的附錄，即 “相互依存宣告”，以便根據敏捷軟體開發方法來指導軟體專案管理。

在 2009 年，（Robert C Martin）編寫了軟體開發原則的擴充套件，即軟體工藝宣言（Software Craftsmanship Manifesto），根據職業行為和掌握程度來指導敏捷軟體開發。

在 2011 年，敏捷聯盟建立了敏捷實踐指南（2016 年更名為 “敏捷詞彙”）、敏捷實踐、術語和元素工作定義的演化開放式彙編，以及來自敏捷從業者社群的經驗指南。

價值觀

雪鳥會議共同起草了敏捷軟體開發宣言。其中最重要的部分就是對一些與會者一致同意的軟體開發價值觀的表述。其中包括了以下方針：

個體和互動：高於流程和工具。
工作的軟體：高於詳盡的文件。
客戶合作：高於合同談判。
響應變化：高於遵循計劃。

雖然他們也很重視右邊的內容，但是更重視左邊的內容。相關術語的意思是:

個人和互動：自我組織和動機是重要的，像共同定位和雙人程式開發，這樣作業模式中的溝通是重要的。建立一個良好的溝通和協作的開發團隊，優於一個孤立執行的專家團隊。溝通是一個基本的概念。
工作軟體：工作軟體比在會議中向客戶呈現檔案更有用並更受歡迎。最好的做法是和程式碼一起評論，保持外部檔案的輕量化，而不是沉重的檔案，後者需要花費很大的精力，且很快就會過時。
客戶協作：在軟體開發週期的初始階段，需求無法完全收集，所以最好直接涉及到付費客戶、終端使用者或者代理，以便在反饋的基礎上逐步闡述和調整詳細的需求。
回應變化：敏捷軟體開發方法的重點是快速響應變化和持續發展。

一些軟體開發者組織了敏捷聯盟，為非營利組織，根據宣言的價值觀和原則促進軟體開發。（Jim Highsmith）代表敏捷聯盟（Agile Alliance）介紹宣言：

總覽

3.1 迭代、漸進和進化

大多數敏捷開發方法將產品開發工作細分微小化，因此大大的減少了前期規劃和設計的數量。迭代或衝刺都是短時間的框架（時間），通常持續一到四周。每個迭代都具有跨功能、職能的團隊，包含了規劃、分析、設計、程式編碼、單元測試和驗收測試。在迭代結束時，將工作產品向利益相關者展示。透過上述方式讓整體風險降至最低，並使產品能夠快速適應變化。迭代的方式，可能不會一次增加足夠的功能來保證可立即釋出使用，但是目標是在每次迭代結束時，有一個可用的發行版（最小化程式缺點）。因此完整產品的釋出或新功能可能需要多次迭代。

3.2 工作軟體是進化的主要手段

3.3 高效率的面對面溝通

無論採用哪種開發方式，每個團隊都應該包含一個客戶代表（Scrum 中的產品負責人）。這個人是由利益相關者同意代表他們行事，並作出個人承諾，回應開發人員在開發迭代過程中的問題。在每次迭代結束時，利益相關方和客戶代表將審查進度並重新評估優先順序，以最佳化投資回報（ROI）並確保與客戶需求和公司目標保持一致。在敏捷軟體開發中，會在開發團隊附近設定一個訊息釋出器（通常很大）實體顯示器，甚至路人也可以看到它。它提供了最新的產品開發狀態摘要。並透過建置狀態指示燈以通知團隊他們的產品開發的當前狀態。

3.4 非常短的反饋迴路和適應週期

敏捷軟體開發中的一個共同特點就是每日站會（也在 scrum 中被稱為日常 scrum）。 在一個簡短的會議中，團隊成員相互報告他們前一天對於團隊的迭代目標、今天打算做的目標以及他們可以看到的任何障礙或阻礙。

3.5 品質焦點

經常使用諸如持續整合、自動化單元測試、配對程式開發、測試驅動開發、設計模式、領域驅動設計，程式碼重構和其他技術的特定工具和技術來提高品質和提高產品開發敏捷性

哲學

與傳統軟體工程相比，敏捷軟體開發主要針對具有動態、非確定性和非線性特徵的複雜系統和產品進行開發。準確的估計、穩定的計劃和預測往往很難在早期達到，因此對它們的信心可能很低，在獲得價值的證據之前，敏捷開發從業人員需要相當的的信心。 需求和設計被認為是緊急情況下，過大的前期規格可能會造成很多浪費，在經濟上也不划算。 由行業從多年經驗的成功和失敗中學到的這些基本論點。

4.1 適應性與預測性

從適應到預測的軟體開發法存在於連續體中，敏捷軟體開發法倚靠連續體的適應性面。適應性開發法的一個關鍵是透過「滾動波」法進行計劃。其中確定了里程碑，但留下了靈活性，以達到他們的路徑，也允許里程碑本身的改變。

適應性方法的重點是快速適應不斷變化的現實。當專案需求發生變化時，適應性團隊也會發生變化。 自適應團隊很難描述未來會發生什麼。 離專案目標日期越遠，適應性方法越是模糊，越無法確知那天會發生什麼變化。一個自適應的團隊無法準確地報告他們下週將要完成的任務，而只是他們下個月計劃的功能。當被問及六個月後的釋出時，一個自適應團隊可能只能報告發布的使命宣告，或預期價值與成本的宣告。

相較之下，預測法著重於詳細分析和規劃未來，並迎合已知的風險。在極端情況下，預測團隊可以準確報告在整個開發過程中計劃的功能和任務。預測法依靠有效的早期階段分析，如果這樣做很不妥，專案可能難以改變方向。預測團隊通常設立一個變更控制委員會，以確保他們只考慮最有價值的變化。

風險分析可以於自適應（敏捷或價值驅動）和預測（計劃驅動）法之間進行選擇。（Barry Boehm）和理查德・特納（Richard Turner）認為，連續統一體的每一面都有自己的主場，如下表所示:

4.2 疊代法與瀑布法

敏捷軟體開發法和瀑布法之間的區別，其中之一就是質量和測試方法。在瀑布模型中，構建階段之後總是有單獨的測試階段；但是，在敏捷軟體開發測試中，與程式設計相同的疊代完成。

由於測試是在每一次疊代中完成的 - 開發一小部分軟體，使用者可以經常使用這些新的軟體並驗證其價值。使用者知道更新後的軟體的真實價值後，可以對軟體的未來作出更好的決策。在每次疊代中進行一次價值回顧和軟體重新計劃會話 - Scrum 通常只有兩個星期的疊代迴圈 - 幫助團隊不斷調整自己的計劃，以最大限度地提高其價值。 遵循與 PDCA 迴圈類似的模式，因為工作已經計劃、完成、檢查（在審查和回顧中），並且任何商定的變更都會被執行。

這種疊方法支援產品更甚於專案思維。這在整個開發過程中提供更大的靈活性；而在專案中，需求是從一開始就定義和鎖定的，以後很難改變它們。疊代開發允許軟體產品根據業務環境或市場需求的變化而發展。由於敏捷軟體開發的疊代方式較短，因此與精益創業概念有著密切的聯絡。

4.3 程式碼與文件

在給 IEEE 計算機的一封信中，Steven Rakitin 表達了對敏捷軟體開發的憤世嫉俗，稱敏捷開發為 "一個破壞軟體工程規範的嘗試" ，並將 "將軟體工作在綜合性文件之上" 翻譯為 "我們要花時間編碼。請記住，真正的程式設計師不寫文件 。"

敏捷軟體開發的支持者認為，開發人員應該編寫文件，如果這是實現相關目標的最佳途徑，但是與編寫靜態文件相比，往往有更好的方法來實現這些目標。斯科特・安布勒（Scott Ambler）指出，文件應該做到「夠好」即可，過多或全面的文件通常會造成浪費，開發人員很少相信詳細的文件，因為它通常與程式碼不同步，而文件太少 也可能導致維護、溝通、學習和知識共享的問題。Alistair Cockburn 寫了透明清晰法：

原則

宣言中還包括以下原則：

對我們而言，最重要的是透過儘早和不斷交付有價值的軟體滿足客戶需要。
我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。
經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。
業務人員和開發者應該在整個專案過程中始終朝夕在一起工作。
圍繞鬥志高昂的人進行軟體開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。
在開發小組中最有效率也最有效果的資訊傳達方式是面對面的交談。
可以工作的軟體是進度的主要度量標準。
敏捷過程提倡可持續開發。出資人、開發人員和使用者應該總是維持不變的節奏。
對卓越技術與良好設計的不斷追求將有助於提高敏捷性。
簡單 —— 儘可能減少工作量的藝術至關重要。
最好的架構、需求和設計都源自自我組織的團隊。
每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。

敏捷軟體開發方法

敏捷軟體開發法支援廣泛的軟體開發生命週期。有的專注於實踐（例如，極限程式設計、務實程式設計，敏捷建模），而有的專注於管理工作流程（例如 Scrum，看板）。有的支援需求規範和開發（例如 FDD）的活動，而另一些則試圖涵蓋整個開發生命週期（例如 DSDM，RUP）。

流行的敏捷軟體開發框架包括（以下列舉常見的方法）：

（ASD）
（AUP）
（DSDM）
極限程式設計（XP）
（FDD）
精益軟體開發
看板
快速應用程式開發（RAD）
Scrum

6.1 敏捷軟體開發實踐

敏捷軟體開發得到了許多具體實踐的支援，涵蓋了需求、設計、建模、編碼、測試、計劃、風險管理、流程、品質等方面。一些值得注意的敏捷軟體開發實踐包括：

驗收測試驅動開發（ATDD）
敏捷建模
敏捷測試
Backlogs（產品和衝刺）
行為驅動開發（BDD）
業務分析師設計方法（BADM）
持續整合（CI）
跨職能團隊
領域驅動設計（DDD）
訊息輻射體（Scrum 板，任務板，視覺管理委員會，燃盡圖）
疊代和增量式開發（IID）
低程式碼開發平臺
配對程式設計
計劃撲克
重構
回顧
Scrum 事件（衝刺計劃，每日 Scrum，衝刺回顧和回顧）
故事驅動的建模
測試驅動開發（TDD）
時間盒
使用者故事
使用者故事對映
速度跟蹤

敏捷聯盟提供了一個全面的線上指南來應用敏捷與相關做法。

6.2 剪裁法

在文獻中，有不同的術語指適應法的概念，包括 “剪裁法”、“片段適應法” 和 “情景方法工程”。 方法剪裁被定義為：一個程式或能力，在這個程式或能力中，人類代理程式透過在情境、意圖和方法片段之間的響應變化和動態的相互作用來確定特定專案情境的系統開發方法。

幾乎所有的敏捷方法都適用於剪裁法。即使是 DSDM 方法也被用於此目的，並且已經成功地在 CMM 環境中進行了定製。敏捷法和傳統的軟體開發法之間的情境適應性，可以被認為是一個明顯的特徵，後者因規範而相對更加僵化。敏捷法實際的含義是可以使產品開發團隊根據個別產品的需求來調整工作實踐。實踐是作為方法框架一部分的具體活動和產品。在更為極端的層面上，可以調整由多種原則組成的方法背後的哲學（Aydin，2004）。

某些方法，如 Scrum 和極限程式設計，使得方法適應的需求是明確的。有了這些不太規範的框架，原則之一就是沒有一個程式適合每一個產品的開發，而是應該根據產品的需求量身定做。 Mehdi Mirakhorli 提出了一個剪裁實踐，為適應所有實踐提供了足夠的路線圖和指導方針。RDP 的實踐是為極限程式設計而設計的。這種做法首先作為 ICSE 2008 會議 APSO 研討會上的一篇長篇研究論文提出，是目前唯一提出並且適用於定製極限程式設計的方法。雖然它是專門針對極限程式設計的解決方案，但是這種做法有擴充套件到其他方法的能力。乍看之下，這種做法似乎屬於靜態方法適應的範疇，但 RDP 實踐的經驗表明，它可以像動態方法適應一樣對待。靜態方法適應和動態方法適應之間的區別是微妙的。

Scrum 不是為剪裁法而設計的。 Schwaber 指出：“Scrum 不是一種需要加強的方法，這是我們首先遇到的麻煩，認為問題沒有一個完美的方法，努力集中在企業所需的變化上。 Bas Vodde 強調了這一說法，表明 Scrum 不像傳統的大型方法論，需要你 “挑選” 元素。 這是基礎知識的基礎上，您新增額外的元素來本地化和使用情況。

6.3 大規模，離岸和分散式

敏捷軟體開發被廣泛認為非常適合於某些型別的環境，包括從事綠地專案的小型專家團隊，在擁有傳統基礎架構的大型組織中採用敏捷軟體開發方法所遇到的挑戰和侷限性， 記錄和理解。

作為回應，一系列的策略和模式已經發展成為克服大規模開發工作（> 20 個開發人員）或分散式（非集中式）開發團隊等挑戰；現在有幾個公認的框架，試圖減輕或避免這些挑戰。

規模敏捷框架（SAFe），Dean Leffingwell 等等
紀律敏捷交付（DAD），Scott Ambler 等等
大規模 Scrum（LeSS），Craig Larman 和 Bas Vodde
Nexus（縮放專業 Scrum），Ken Schwaber
Scale Scrum，Jeff Sutherland，Alex Brown
企業 Scrum，邁克 Beedle
Setchu（基於 Scrum 的輕量級框架），Michael Ebbage 的 Xscale
敏捷路徑
整體軟體開發

對於所有這些是否有效或者確實符合敏捷開發的定義，存在許多相互矛盾的觀點，而且這仍然是一個積極和正在進行的研究領域。

當敏捷軟體開發應用於分散式環境（團隊分散在多個業務地點）時，通常稱為分散式敏捷開發。目標是利用每種方法提供的獨特優勢。分散式開發允許組織透過戰略性地在全球不同地區建立團隊來構建軟體，實際上是全天候建立軟體（或稱為 “跟隨太陽模式”）。另一方面，敏捷開發在響應變化時提供了更高的透明度，持續的反饋和更大的靈活性。

敏捷方法的適用性

在敏捷方法其獨特之處以外，他和其他的方法也有很多共同之處，比如迭代開發，關注互動溝通，減少中介過程的無謂資源消耗。通常可以在以下方面衡量敏捷方法的適用性：從產品角度看，敏捷方法適用於需求萌動並且快速改變的情況，如系統有比較高的關鍵性、可靠性、安全性方面的要求，則可能不完全適合；從組織結構的角度看，組織結構的文化、人員、溝通則決定了敏捷方法是否適用。跟這些相關聯的關鍵成功因素有：

組織文化必須支援談判
人員彼此信任
人少但是精幹
開發人員所作決定得到認可
環境設施滿足成員間快速溝通之需要

最重要的因素恐怕是專案的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，40、30、20、10 人或者更少。大規模的敏捷軟體開發尚處於積極研究的領域。

另外的問題是專案初期的大量假定或者快速收集需求可能導致專案走入誤區，特別是客戶對其自身需要毫無概念的情況下。與之類似，人之天性很容易造成某個人成為主導並將專案目標和設計引入錯誤方向的境況。開發者經常能把不恰當的方案授予客戶，並且直到最後發現問題前都能獲得客戶認同。雖然理論上快速互動的過程可以限制這些錯誤的發生，但前提是要有效的 “負反饋”，否則錯誤會迅速膨脹，並在最終提交時造成極大返工。

用於敏捷開發團隊的專案管理工具

已經有一些專案管理工具用於敏捷開發，可以用它們來幫助規劃，跟蹤，分析和整合工作。

這些工具在敏捷開發中扮演的重要的角色，也是知識管理的一種方法。

通常包括：版本控制整合，進度跟蹤，工作分配，整合釋出和迭代規劃，論壇和軟體缺陷的報告和跟蹤。

方法列表

目前列入敏捷方法的有：

軟體開發之韻，Software Development Rhythms
敏捷資料庫技術，AD/Agile Database Techniques
敏捷建模，AM/Agile Modeling
自適應軟體開發，ASD/Adaptive Software Development
水晶方法，Crystal
特性驅動開發，FDD/Feature Driven Development
動態系統開發方法，DSDM/Dynamic Systems Development Method
精益軟體開發，Lean Software Development
AUP（Agile Unified Process）
Scrum
XBreed
極限程式設計，（Extreme Programming）
探索性測試
ATDD

敏捷技術

測試驅動開發，TDD/Test-Driven Development
行為驅動開發，BDD/Behavior-Driven Development
Scrum