敏捷软件开发

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 驗收測試驅動開發（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
• 敏捷路徑
• 整體軟件開發

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

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

相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。

两者没有很多的共同点，瀑布模型是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行，例如极限编程。