敏捷软件开发
 | 此條目需要补充更多来源。 (2018年1月4日) |
| 软件开发 |
|---|
| 核心行动 |
| 范式与模式 |
| 方法论与框架 |
| 支持行为 |
| 实践 |
| 工具 |
| 标准与知识体系 |
敏捷軟體開發（英語：Agile software development），又稱敏捷開發，是一種應對快速變化需求的一種軟體開發模式，描述了一套軟體開發的價值和原則。此模式中，自組織的跨功能團隊在緊密的協作中發掘使用者或顧客的需求以及改良解決方案，[1]此模式也強調適度的計畫、進化開發、提前交付與持續改進，並且鼓勵快速與靈活的面對開發與變更。[2][3]這些原則支援許多軟件開發方法的定義和持續進化。
「敏捷」（Agile 或 agile[4]）一詞由「敏捷軟件開發宣言」（Manifesto for agile software development）[5]中開始普及，「敏捷軟件開發宣言」定義了相關的價值和原則。敏捷軟體開發的框架不斷的發展，兩個最廣泛被使用的是 Scrum 與 Kanban。[6]
词源[编辑]
敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。
迭代和增量式軟件開發方法可以追溯到1957年。進化式專案管理和適應性軟體開發出現在1970年代初期。在1990年代，因針對重量級的軟體開發方法的批評，而發展了許多輕量化的軟體開發方法、計畫與細微化開發管理。包含了，從1991年開始的迅速應用程式開發、從1994年開始的統一處理程序與動態系統開發法（DSDM）、從1995年的Scrum、從1996年的水晶清透法與極限編程法、1997年的功能驅動開發。雖然那些開發法都起源於敏捷開發宣言之前，但都統稱為敏捷軟體開發法。在此同時，製造業與航空業也遭遇相同變化。
在2001年，十七名軟體開發人員在猶他州的雪鳥度假村會面，討論這些輕量級的開發方法，並由Jeff Sutherland，Ken Schwaber和Alistair Cockburn發起，一同發布了「敏捷軟體開發宣言」。
在2005年，由Alistair Cockburn和Jim Highsmith領導的小組編寫了一份項目管理原則的附錄，即“相互依存聲明”，以便根據敏捷軟體開發方法來指導軟體專案管理。
在2009年，羅伯特·C·馬丁（Robert C Martin）編寫了軟體開發原則的擴展，即軟體工藝宣言（Software Craftsmanship Manifesto），根據職業行為和掌握程度來指導敏捷軟體開發。
在2011年，敏捷聯盟創建了敏捷實踐指南（2016年更名為“敏捷詞彙”）、敏捷實踐、術語和元素工作定義的演化開放式彙編，以及來自敏捷從業者社群的經驗指南。
价值观[编辑]
雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述。[7][8]其中包括了以下方针：
- 个体和互动：高于流程和工具。
- 工作的软件：高于详尽的文档。
- 客户合作：高于合同谈判。
- 响应变化：高于遵循计划。
雖然他們也很重視右邊的內容，但是更重視左邊的內容。相關術語的意思是:
- 個人和互動：自我組織和動機是重要的，像共同定位和雙人程式開發，這樣作業模式中的溝通是重要的。建立一個良好的溝通和協作的開發團隊，優於一個孤立運行的專家團隊。溝通是一個基本的概念。
- 工作軟體：工作軟體比在會議中向客戶呈現文件更有用並更受歡迎。最好的做法是和程式碼一起評論，保持外部文件的輕量化，而不是沉重的文件，後者需要花費很大的精力，且很快就會過時。
- 客戶協作：在軟體開發週期的初始階段，需求無法完全收集，所以最好直接涉及到付費客戶、最終用戶或者代理，以便在反饋的基礎上逐步闡述和調整詳細的需求。
- 回應變化：敏捷軟件開發方法的重點是快速響應變化和持續發展。
一些軟體開發者組織了敏捷聯盟，為非營利組織，根據宣言的價值觀和原則促進軟體開發。吉姆·海史密斯（Jim Highsmith）代表敏捷聯盟（Agile Alliance）介紹宣言：
| “ | 敏捷運動並不是反方法論，實際上我們很多人都想恢復對方法論的可信度。我們想恢復平衡。我們接受建模，但不是為了在塵土飛揚的企業存儲庫中提交一些圖表。 我們擁抱文件，而不是數百頁從未維護和很少使用的文件。 我們計劃，但要認識到動盪環境下的規劃極限。 那些將XP或SCRUM或者其他敏捷方法的支持者稱為“黑客”的人對於黑客術語的方法和原始定義都是無知的。 | ” |
總覽[编辑]
迭代、漸進和進化[编辑]
大多數敏捷開發方法將產品開發工作細分微小化，因此大大的減少了前期規劃和設計的數量。迭代或衝刺都是短時間的框架（時間），通常持續一到四周。每個迭代都具有跨功能、職能的團隊，包含了規劃、分析、設計、程式編碼、單元測試和驗收測試。在迭代結束時，將工作產品向利益相關者展示。透過上述方式讓整體風險降至最低，並使產品能夠快速適應變化。迭代的方式，可能不會一次增加足夠的功能來保證可立即發佈使用，但是目標是在每次迭代結束時，有一個可用的發行版（最小化程式缺點）。因此完整產品的發佈或新功能可能需要多次迭代。
工作軟體是進化的主要手段[编辑]
高效率的面對面溝通[编辑]
無論採用哪種開發方式，每個團隊都應該包含一個客戶代表（Scrum中的產品負責人）。這個人是由利益相關者同意代表他們行事，並作出個人承諾，回應開發人員在開發迭代過程中的問題。在每次迭代結束時，利益相關方和客戶代表將審查進度並重新評估優先級，以優化投資回報（ROI）並確保與客戶需求和公司目標保持一致。在敏捷軟體開發中，會在開發團隊附近設置一個訊息發佈器（通常很大）實體顯示器，甚至路人也可以看到它。它提供了最新的產品開發狀態摘要。並透過建置狀態指示燈以通知團隊他們的產品開發的當前狀態。
非常短的反饋迴路和適應週期[编辑]
敏捷軟件開發中的一個共同特點就是每日站会（也在scrum中被稱為日常scrum）。 在一個簡短的會議中，團隊成員相互報告他們前一天對於團隊的迭代目標、今天打算做的目標以及他們可以看到的任何障礙或阻礙。
品質焦點[编辑]
經常使用諸如持續整合、自動化單元測試、配對程式開發、測試驅動開發、設計模式、領域驅動設計，程式碼重構和其他技術的特定工具和技術來提高品質和提高產品開發敏捷性
哲學[编辑]
與傳統軟體工程相比，敏捷軟體開發主要針對具有動態、非確定性和非線性特徵的複雜系統和產品進行開發。準確的估計、穩定的計劃和預測往往很難在早期達到，因此對它們的信心可能很低，在獲得價值的證據之前，敏捷開發從業人員需要相當的的信心。 需求和設計被認為是緊急情況下，過大的前期規格可能會造成很多浪費，在經濟上也不划算。 由行業從多年經驗的成功和失敗中學到的這些基本論點。
適應性與預測性[编辑]
從適應到預測的軟體開發法存在於連續體中，敏捷軟體開發法倚靠連續體的適應性面。適應性開發法的一個關鍵是透過「滾動波」法進行計劃。其中確定了里程碑，但留下了靈活性，以達到他們的路徑，也允許里程碑本身的改變。
適應性方法的重點是快速適應不斷變化的現實。當專案需求發生變化時，適應性團隊也會發生變化。 自適應團隊很難描述未來會發生什麼。 離專案目標日期越遠，適應性方法越是模糊，越無法確知那天會發生什麼變化。一個自適應的團隊無法準確地報告他們下週將要完成的任務，而只是他們下個月計劃的功能。當被問及六個月後的發佈時，一個自適應團隊可能只能報告發布的使命聲明，或預期價值與成本的聲明。
相較之下，預測法著重於詳細分析和規劃未來，並迎合已知的風險。在極端情況下，預測團隊可以準確報告在整個開發過程中計劃的功能和任務。預測法依靠有效的早期階段分析，如果這樣做很不妥，專案可能難以改變方向。預測團隊通常設立一個變更控制委員會，以確保他們只考慮最有價值的變化。
風險分析可以於自適應（敏捷或價值驅動）和預測（計劃驅動）法之間進行選擇。巴里·伯姆（Barry Boehm）和理查德·特納（Richard Turner）認為，連續統一體的每一面都有自己的主場，如下表所示:
| 價值驅動法 | 計畫驅動法 | 正式法 |
|---|---|---|
| 低臨界 | 高關鍵性 | 極端的危險 |
| 資深開發人員 | 初級開發者 | 資深開發人員 |
| 需求經常變化 | 需求不經常改變 | 有限的需求 |
| 少量的開發人員 | 大量的開發人員 | 可以建模的需求 |
| 響應變化的文化 | 要求秩序的文化 | 極致的品質 |
疊代法與瀑布法[编辑]
敏捷軟體開發法和瀑布法之間的區別，其中之一就是質量和測試方法。在瀑布模型中，構建階段之後總是有單獨的測試階段; 但是，在敏捷軟件開發測試中，與編程相同的疊代完成。
由於測試是在每一次疊代中完成的-開發一小部分軟件，用戶可以經常使用這些新的軟體並驗證其價值。用戶知道更新後的軟體的真實價值後，可以對軟體的未來作出更好的決策。在每次疊代中進行一次價值回顧和軟體重新計劃會話 - Scrum通常只有兩個星期的疊代循環 - 幫助團隊不斷調整自己的計劃，以最大限度地提高其價值。 遵循與PDCA循環類似的模式，因為工作已經計劃、完成、檢查（在審查和回顧中），並且任何商定的變更都會被執行。
這種疊方法支援產品更甚於專案思維。這在整個開發過程中提供更大的靈活性; 而在專案中，需求是從一開始就定義和鎖定的，以後很難改變它們。疊代開發允許軟體產品根據業務環境或市場需求的變化而發展。由於敏捷軟件開發的疊代方式較短，因此與精益創業概念有著密切的聯繫。
程式碼與文檔[编辑]
在給IEEE計算機的一封信中，Steven Rakitin表達了對敏捷軟件開發的憤世嫉俗，稱敏捷開發為 "一個破壞軟件工程規範的嘗試" ，並將 "將軟件工作在綜合性文檔之上" 翻譯為 "我們要花時間編碼。請記住，真正的程序員不寫文檔 。"
敏捷軟體開發的支持者認為，開發人員應該編寫文檔，如果這是實現相關目標的最佳途徑，但是與編寫靜態文檔相比，往往有更好的方法來實現這些目標。斯科特·安布勒（Scott Ambler）指出，文檔應該做到「夠好」即可，過多或全面的文檔通常會造成浪費，開發人員很少相信詳細的文檔，因為它通常與程式碼不同步，而文檔太少 也可能導致維護、溝通、學習和知識共享的問題。Alistair Cockburn寫了透明清晰法：
| “ | Crystal認為開發一系列的合作遊戲，並打算在下一場比賽中獲得足夠的文檔資料。null Crystal的工作產品包括使用案例、風險列表、疊代計劃、核心領域模型和設計註釋以供選擇...但是這些文檔沒有模板，描述也是模糊的，但是目標是明確的，也有足夠的文檔準備下一場比賽。我總是像我的團隊詢問：如果明天你加入了隊伍，你想知道什麼？ | ” |
原则[编辑]
- 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
- 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
- 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
- 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
- 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
- 可以工作的软件是进度的主要度量标准。
- 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
- 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
- 简单——尽可能减少工作量的艺术至关重要。
- 最好的架构、需求和设计都源自自我组织的团队。
- 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
敏捷軟體開發方法[编辑]
敏捷軟體開發法支援廣泛的軟體開發生命週期。有的專注於實踐（例如，極限編程、務實編程，敏捷建模），而有的專注於管理工作流程（例如Scrum，看板）。有的支援需求規範和開發（例如FDD）的活動，而另一些則試圖涵蓋整個開發生命週期（例如DSDM，RUP）。
流行的敏捷軟件開發框架包括（以下列舉常見的方法）：
- 自適應軟件開發（ASD）
- 敏捷建模
- 敏捷統一過程（AUP）
- 紀律敏捷交付
- 動態系統開發法（DSDM）
- 極限編程（XP）
- 功能驅動開發（FDD）
- 精益軟件開發
- 看板
- 快速應用程序開發（RAD）
- Scrum
- Scrumban
敏捷軟體開發實踐[编辑]
敏捷軟體開發得到了許多具體實踐的支持，涵蓋了需求、設計、建模、編碼、測試、計劃、風險管理、流程、品質等方面。一些值得注意的敏捷軟體開發實踐包括：
- 驗收測試驅動開發（ATDD）
- 敏捷建模
- 敏捷測試
- Backlogs（產品和衝刺）
- 行為驅動開發（BDD）
- 業務分析師設計方法（BADM）
- 持續整合（CI）
- 跨職能團隊
- 領域驅動設計（DDD）
- 訊息輻射體（Scrum板，任務板，視覺管理委員會，燃尽图）
- 疊代和增量式開發（IID）
- 低程式碼開發平台
- 配對編程
- 計劃撲克
- 重構
- 回顧
- Scrum事件（衝刺計劃，每日Scrum，衝刺回顧和回顧）
- 故事驅動的建模
- 測試驅動開發（TDD）
- 時間盒
- 用戶故事
- 用戶故事映射
- 速度跟踪
敏捷聯盟提供了一個全面的線上指南來應用敏捷與相關做法。
剪裁法[编辑]
在文獻中，有不同的術語指適應法的概念，包括“剪裁法”、“片段適應法”和“情景方法工程”。 方法剪裁被定義為：一個程序或能力，在這個程序或能力中，人類代理程式通過在情境、意圖和方法片段之間的響應變化和動態的相互作用來確定特定項目情境的系統開發方法。
幾乎所有的敏捷方法都適用於剪裁法。即使是DSDM方法也被用於此目的，並且已經成功地在CMM環境中進行了定制。敏捷法和傳統的軟體開發法之間的情境適應性，可以被認為是一個明顯的特徵，後者因規範而相對更加僵化。敏捷法實際的含義是可以使產品開發團隊根據個別產品的需求來調整工作實踐。實踐是作為方法框架一部分的具體活動和產品。在更為極端的層面上，可以調整由多種原則組成的方法背後的哲學（Aydin，2004）。
某些方法，如Scrum和極限編程，使得方法適應的需求是明確的。有了這些不太規範的框架，原則之一就是沒有一個程序適合每一個產品的開發，而是應該根據產品的需求量身定做。 Mehdi Mirakhorli提出了一個剪裁實踐，為適應所有實踐提供了足夠的路線圖和指導方針。RDP 的實踐是為極限編程而設計的。這種做法首先作為ICSE 2008會議APSO研討會上的一篇長篇研究論文提出，是目前唯一提出並且適用於定制極限編程的方法。雖然它是專門針對極限編程的解決方案，但是這種做法有擴展到其他方法的能力。乍看之下，這種做法似乎屬於靜態方法適應的範疇，但RDP實踐的經驗表明，它可以像動態方法適應一樣對待。靜態方法適應和動態方法適應之間的區別是微妙的。
Scrum不是為剪裁法而設計的。 Schwaber指出：“Scrum不是一種需要加強的方法，這是我們首先遇到的麻煩，認為問題沒有一個完美的方法，努力集中在企業所需的變化上。 Bas Vodde強調了這一說法，表明Scrum不像傳統的大型方法論，需要你“挑選”元素。 這是基礎知識的基礎上，您添加額外的元素來本地化和使用情況。
大規模，離岸和分佈式[编辑]
敏捷軟體開發被廣泛認為非常適合於某些類型的環境，包括從事綠地項目的小型專家團隊，在擁有傳統基礎架構的大型組織中採用敏捷軟件開發方法所遇到的挑戰和局限性， 記錄和理解。
作為回應，一系列的策略和模式已經發展成為克服大規模開發工作（> 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
敏捷技术[编辑]
参考文献[编辑]
- ^ Collier, Ken W. Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Pearson Education. 2011: 121 ff. ISBN 9780321669544.
What is a self-organizing team?
- ^ Beck, Kent M.; Beedle, Mike; Bennekum, Arie van; Cockburn, Alistair; Cunningham, Ward; Fowler, Martin; Grenning, James; Highsmith, Jim; Hunt, Andy; Jeffries, Ron; Kern, Jon; Marick, Brian; Martin, R. C.; Mellor, Steve J.; Schwaber, Ken; Sutherland, Jeff; Thomas, Dave. Manifesto for Agile Software Development. S2CID 109006295.
- ^ What is Agile Software Development?. Agile Alliance. 8 June 2013 [4 April 2015]. （原始内容存档于2015-11-27）.
- ^ Rally. Agile With a Capital "A" Vs. agile With a Lowercase "a". 2010 [September 9, 2015]. （原始内容存档于5 January 2016）.
- ^ Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick. Manifesto for Agile Software Development. Agile Alliance. 2001 [14 June 2010]. （原始内容存档于2011-02-23）.
- ^ Which is better – Kanban or Scrum?, 4 March 2016 [2023-02-28], （原始内容存档于2023-03-06）
- ^ 敏捷軟體開發宣言. [2017-12-20]. （原始内容存档于2017-12-30） （中文（繁體））.
- ^ 敏捷软件开发宣言. [2017-12-20]. （原始内容存档于2017-12-08） （中文（简体））.
- ^ 敏捷宣言背後的原則. [2011-02-01]. （原始内容存档于2010-12-16） （中文（繁體））.
- ^ 敏捷宣言遵循的原则. [2011-02-01]. （原始内容存档于2011-03-06） （中文（简体））.
延伸阅读[编辑]
- Abrahamsson, P.; Salo, O.; Ronkainen, J.; Warsta, J. Agile Software Development Methods: Review and Analysis. VTT Publications. 2002 [2019-10-19]. 478. （原始内容存档于2011-09-07）.
- Ashmore, Sondra; Runyan, Kristin. Introduction to Agile Methods. Addison-Wesley. 2014. ISBN 978-0321929563.
- Cohen, D.; Lindvall, M.; Costa, P. An introduction to agile methods. Zelkowitz, Marvin (编). Advances in Software Engineering. Advances in Computers 62. Academic Press. 2004: 1–66 [2019-10-19]. ISBN 978-0-08-047190-7. （原始内容存档于2019-12-12）.
- Dingsøyr, Torgeir; Dybå, Tore; Moe, Nils Brede. Agile Software Development: Current Research and Future Directions. Springer. 2010 [2019-10-19]. ISBN 978-3-642-12575-1. （原始内容存档于2019-12-12）.
- Fowler, Martin. Is Design Dead?. Succi, Giancarlo; Marchesi, Michele (编). Extreme Programming Examined. Addison-Wesley. 2001: 3–18 [2019-10-19]. ISBN 978-0-201-71040-3. （原始内容存档于2019-10-19）.
- Larman, Craig; Basili, Victor R. Iterative and Incremental Development: A Brief History (PDF). IEEE Computer. June 2003, 36 (3): 47–56. doi:10.1109/MC.2003.1204375.
- Casagni, Michelle; Benito, Robert; Mayfield, Dr Kathleen M.; Northern, Carlton. Handbook for Implementing Agile in Department of Defense Information Technology Acquisition. The Mitre Corporation (MITRE). 8 September 2013 [2019-10-19]. （原始内容存档于2019-10-19）.
- Moran, Alan. Managing Agile: Strategy, Implementation, Organisation and People. Springer. 2015 [2019-10-19]. ISBN 978-3-319-16262-1. （原始内容存档于2019-12-12）.
- Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other. [2019-10-19]. （原始内容存档于2020-07-20）. In Succi & Marchesi 2001
- Shore, James; Warden, Shane. The Art of Agile Development. O'Reilly Media. 2008 [2019-10-19]. ISBN 978-0-596-52767-9. （原始内容存档于2019-12-12）.
- Stephens, M.; Rosenberg, D. Extreme Programming Refactored: The Case Against XP. Apress. 2003. ISBN 978-1-59059-096-6.
外部链接[编辑]
- 捷伴行Agile--专注敏捷文化在软件开发领域的传播 （页面存档备份，存于互联网档案馆）
- 敏捷联盟 (英語，Agile Alliance) （页面存档备份，存于互联网档案馆）
- 敏捷软件开发随笔--专注Scrum+XP （页面存档备份，存于互联网档案馆）
- 敏捷軟體開發宣言繁體中文版翻譯始末 （页面存档备份，存于互联网档案馆）
| |||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||
