軟體開發生命週期(SDLC Software development life cycle)和過程模型是軟體開發過程的高階表示。這些模型定義了軟體開發所經歷的階段（phase），以及在每個階段所進行的活動。每個SDLC模型代表一個軟體專案、迭代或增量，從構思到該版本的產品完成和/或釋出。軟體產品生命週期模型代表了軟體產品的生命週期，從構思到產品退役。對於一個成功的軟體產品來說，產品生命週期通常包含了多次透過軟體開發生命週期或過程模型的過程。生命週期和過程模型為各個軟體開發過程的詳細定義提供框架（最高級別的過程架構）。定義好的模型作為開發團隊的路線圖，確保在軟體開發過程中實施所有必要的和經過驗證的步驟，以便生產出高質量的產品。遵循預先定義的模型及其相關流程，有助於確認包括提高質量的關鍵步驟。這些模型描述了主要里程碑、基線和專案交付物之間的相互關係。這些模型可以幫助專案經理和/或團隊計劃活動和跟蹤進度，將開發工作分成幾個階段，每個階段都有一套確定的活動，包括階段過渡審查。這些模型還提供了一個一致的框架，用於。
收集經驗教訓實施過程改進比較多個專案的結果建立衡量標準提供有用的組織流程資產，可用於更好地估計和規劃未來的開發、維護和收購專案。這些模型多年來透過經驗和研究不斷完善。組織可以從這些改進中學習，然後採用和調整自己的生命週期和過程模型，以符合他們的需求、業務領域、文化和軟體開發方法。
瀑布模型瀑布模型
瀑布模型是基於這樣一個概念：軟體開發可以被認為是簡單的階段序列。每個階段從開始到結束，然後才開始下一個階段。瀑布模型中一個階段產生的工作產品通常是後續階段的輸入。瀑布模型的前提是，一個專案可以在開始之前就進行規劃，並透過開發以合理有序的方式進行。在瀑布模型中，在設計開始之前，一組定義明確的需求被指定，在編碼開始之前，設計已經完成，產品在建成之後被測試。
在實際專案中，階段的數量取決於專案的需求和進行專案的組織。有些瀑布模型只包括向下的箭頭，描述了活動在開發專案中向下的流動。這個例子還包括向上的箭頭，表示在開發活動中允許一些迭代。
許多批評瀑布模型的人說，它已經過時了，不能反映軟體開發中的真實情況。然而模型是從一個特定的角度對一個專案或過程的抽象表述。模型是一種簡化，旨在表達專案或過程的某些方面的要點，而不提供不必要的細節。模型的目的是使有關人員能夠思考和討論這些基本要素，而不被所有的細節所困擾。在這方面，瀑布模型仍然是一個有用的工具，因為它是一個容易理解和討論的模型。即使是最不成熟的利益相關者也能理解瀑布模型的基本概念。誠然瀑布模型幾乎刪除了所有的細節，包括開發過程中通常發生的大部分迭代，但這些細節中的許多可能在模型下的較低級別的過程定義中得到說明。
瀑布模型是第一個定義軟體開發的規範化方法的模型，易於理解，定義明確。瀑布模型的優點之一是它與軟體開發的可交付成果直接相關，這可以幫助專案管理活動。有許多工具可以支援瀑布模型。
瀑布模型的主要弱點是，大多數（如果不是全部）需求必須在開發之初就知道。瀑布模型不容易適應變化。軟體產品在專案完成或接近完成時才可以使用，所以該模型不包括對利益相關者的中間反饋的規定，儘管在基於瀑布的開發過程中可以使用原型來提供早期反饋。瀑布模型最適合於那些需求是已知的並且預期是穩定的專案，並且開發過程預期會以一種有序的、有紀律的方式進行。例如，瀑布模型可能適合於將現有產品移植到一個新的平臺、環境或語言的專案，其中的限制因素是眾所周知的。其他的例子可能包括更新軟體以符合新的政府法規的增強專案，或者使目前正在手工執行的報告自動化的專案。瀑布式生命週期模型也適用於只有幾個有經驗的程式設計師和許多初級程式設計師的專案，或者是在非常成熟的領域中的新開發專案，即正在建立的另一個軟體產品，就像上一個產品。瀑布模型通常不適合於需求模糊或預期具有高波動性的專案，或預期不會以線性方式進展的專案。對於大型的、高風險的專案，更多基於風險的方法，如螺旋模型或增量開發可能比瀑布模型更合適。
V型模型
V型模型是瀑布模型的一個變種，它強調了測試階段和生命週期早期階段產生的產品之間的關係，驗收測試根據概念階段定義的利益相關者的需求來評估軟體，系統測試根據需求階段指定的產品級需求來評估軟體，以此類推。測試規劃和設計可以在相應的早期開發階段顯著完成後立即開始。例如，一旦相當數量的利益相關者的需求（概念，在例子中）被定義，驗收測試規劃和設計就可以開始了。一旦相當數量的產品級需求被定義，系統測試規劃和設計就可以開始了。
W-模型
W模型是瀑布模型的另一種變體。W模型有兩條路徑（或稱交叉V），每條路徑都代表一個獨立的組織或獨立團隊在開發過程中的生命週期。第一條路徑代表開發組織/團隊，負責開發需求、設計和程式碼。第二條路徑代表獨立的驗證和確認（V&V）組織，負責獨立分析、審查和測試軟體生命週期各階段的工作成果。
遞增/迭代式軟體開發生命週期螺旋模型
螺旋模型最初由Boehm（1988）定義，是一個基於風險的過程模型，它在以前的模型基礎上擴充套件了細節，包括替代方案的探索、原型設計和規劃。螺旋模型將軟體開發的每個週期細分為四個象限。然後，生命週期的活動以螺旋方式納入這四個象限，從中間的概念階段開始。
確定目標、備選方案和約束條件。開發團隊確定該週期的目標、替代方案和約束條件。例如，在概念階段，這可能包括探索購買和建造的替代方案，或確定在專案中應該解決哪些業務層面和/或利益相關者層面的要求。識別和解決風險，評估替代方案，並選擇方法：評估替代方案，識別和分析風險，並可能進行原型設計，以選擇最適合該專案週期的方法。例如，對於概念階段，這可能包括風險識別和分析購買和建造的選擇，對替代方案的成本/效益分析，以及原型設計，以評估選擇，以確定在內部建造軟體是否是合適的決定。開發和V&V下一層次的產品。開發該階段的軟體產品，並對這些產品進行V&V活動。這也可能包括建立模擬、模型或基準，如果合適的話。例如，對於概念階段，這可能包括徵詢、分析和指定業務層面和利益相關者層面的需求，並執行V&V活動來驗證這些需求。計劃下一個階段。在這前三項活動中，會做出一些決定並獲得一些影響專案計劃的額外資訊。因此，在螺旋模型的第四個活動中，專案計劃被逐步闡述，為後續週期提供更多的細節。這第四步通常以審查和/或其他週期過渡活動結束。例如，對於概念階段，這可能包括使用概念階段前三個活動的資訊和決定來更新需求階段和其他後續階段的專案計劃。然後，這四個象限被重複用於需求週期和高層（架構）設計週期。隨著詳細設計週期的前兩項活動的完成，專案的大部分主要決定已經做出，螺旋模型完成了第三項活動，其中包括詳細設計規範和V&V、編碼和程式碼V&V、單元測試、整合和測試、系統測試、驗收測試和運營。與其他所有的軟體開發生命週期模型一樣，螺旋模型可以根據專案和組織的需要進行調整。
螺旋模型將重點從產品開發轉移到風險分析和規避上。螺旋模型把注意力集中在早期探索選項上，透過原型設計獲得反饋，以驗證正確的產品是以最合適的方式建立的。螺旋模型還包括處理變化的機制，透過任何給定的活動或週期的迭代，在進入下一個週期之前，根據需要多次進行。螺旋模型透過強調在獲得更多資訊時對專案計劃的更新，納入了堅實的專案管理技術。Boehm（2000）列出了成功應用螺旋模型的六個共同特徵。
"同時而不是按順序確定工件在每個螺旋迴圈中考慮主要的螺旋要素。關鍵利益相關者的目標和約束產品和過程的選擇風險識別和解決利益相關者審查承諾進行使用風險考慮來確定每個螺旋週期內每個活動的努力程度使用風險考慮因素來確定每個螺旋週期中產生的每個工件的詳細程度用三個錨點裡程碑來管理利益相關者的生命週期承諾。生命週期目標(LCO)生命週期結構(LCA)初始執行能力（IOC強調系統和生命週期的活動和工件，而不是軟體和初始開發。
螺旋模型是一個複雜的模型，一些利益相關者並不瞭解或不容易掌握，因此利益相關者可能會發現它難以溝通和使用。螺旋模型需要高水平的風險管理技能和分析技術，這使得它比其他模型更依賴於人。這也意味著，螺旋模型需要一個強大的、熟練的專案經理。螺旋模型的一個弱點是，它不像基於瀑布模型那樣與根據合同進行的軟體開發的需求相關（例如，與控制、檢查點和中間交付的對映）。
螺旋模型適合於那些軟體開發方法是非線性的和/或包含多種需要探索的替代方法的專案。對於較小的、低風險的、直接的專案，額外的風險管理、分析和計劃步驟可能會增加不必要的額外成本和/或努力。由於螺旋模型具有廣泛的靈活性和自由度，固定成本或固定進度的專案可能不適合使用這種模型。螺旋模型也可能不是經驗不足的專案的合適選擇。
迭代模式
迭代模型其中的步驟或活動被重複多次。這樣做可能是為了給需求、設計、程式碼或測試增加更多的細節，也可能是為了實現小塊的新功能，一個接一個。有許多不同的迭代模型。例如，上面討論的螺旋模型可以作為一個迭代模型來實現，下面的敏捷軟體開發生命週期小節中描述的測試驅動開發和功能驅動開發方法也是迭代模型。迭代模型中開發週期從短期的、集中的計劃開始，它定義了在該迭代中要實現的功能。每個週期包括設計、編寫測試、開發程式碼、執行測試，並將成功開發的程式碼整合到該週期的 "基線 "中，然後再設計、編寫測試，如此迴圈。這個過程持續進行，在各個環節都有反饋（來自其他開發者、客戶、使用者和/或其他利益相關者，以及軟體本身），直到功能在分配給增量的時間範圍內完成。然後，該增量的輸出被髮布給利益相關者，他們可能會試用並投入執行，或者只是為下一個開發週期（迭代）提供反饋。
迭代模型的好處包括不需要預先知道所有的需求。明確的需求可以在軟體中實現，而較模糊的需求正在被調查和/或穩定下來。新的需求可以被新增到未來的迭代中，因為它們被確認。將高風險的產品/專案分解成更小的部分，也有助於減少風險。構建在迭代模型中的連續反饋迴路提供了學習的迴圈，有助於消除類似錯誤在產品其他部分的傳播，並允許以更大的信心在產品中構建質量。
增量開發
增量開發是指透過使用軟體開發的多次傳遞，構建越來越大的軟體需求子集的過程。在增量開發中，需求被確定後，它們被優先分配到計劃的增量中，每個增量都是軟體開發的一個環節。每一個後續的版本/發行都是可用的，但只具有部分功能（除了最後一次交付，它包括所有的需求）。每個增量可以有自己的軟體開發生命週期模型（例如，瀑布式、V型、迭代式）。不要求每個增量都使用相同的模型。例如，前兩個增量可以使用瀑布模型，而下一個增量可以改用迭代模型。
增量開發可以按順序進行，即在開始下一個增量之前完成一個增量。這些增量也可以平行進行。
增量開發的主要優勢之一是建立較小的子集比建立一個大系統的風險要小。這使得客戶/使用者可以收到和/或評估產品的早期版本，其中包含他們最優先的操作需求。這提供了比傳統瀑布式專案更早的驗證和反饋的機會。增量開發也能很好地適應變化。如果在增量的開發過程中發現了新的或變化的需求，它們可以被分配到未來的增量中，而不會擾亂當前開發週期的時間表和計劃。然而，如果新的或改變的需求有足夠高的優先順序，以至於它們必須被新增到當前的版本中，那麼要麼是優先順序較低的未實施的需求可以滑落到下一個增量中，要麼是更新的時間表和其他計劃可能需要重新協商。
增量開發模式的一個弱點是，大部分的需求仍然必須在前面知道。根據系統和專案所使用的開發方法，可能需要額外的工作來建立一個能夠支援整個系統的架構，並且足夠開放以接受每一個新的功能增量的加入。每個釋出的增量必須是一個完整的工作系統，即使它不包括所有的預期功能。因此，增量開發對如何選擇特定增量的內容是很敏感的，如果它是為了釋出到運營中。例如，如果在以後的版本中才安排核銷庫存的功能，那麼釋出一個允許核銷庫存的庫存控制系統增量是不可行的。遞增式開發還將產品的某些部分提前置於配置控制之下，從而要求正式的變更程式，以及相關的增加的開銷，提前開始。最後，增量開發的好處之一是能夠更快地將高優先順序的軟體功能送到客戶/使用者手中，從而更早地獲得他們的反饋。然而，這也可能是一個弱點，如果軟體的質量不好。換句話說，開發組織可能忙於修復上一個增量中的缺陷，而沒有時間為下一個增量進行新的開發。
增量開發不需要迭代產品生命週期，但它們經常被一起使用。術語迭代開發和迭代正在被使用，特別是在敏捷社群，一般是指增量產品生命週期和迭代開發生命週期的結合。例如極限程式設計的流程原則將迭代開發週期與增量產品開發相結合，一個迭代的輸出成為下一個迭代的輸入，以此類推。
演進開發
進化開發發生在現有的執行中的軟體產品被更新以實現完善性、適應性或預防性維護。演進開發發生在一個軟體產品成功的時候。如果客戶/使用者喜歡這個產品，他們會想繼續使用它，但執行環境很少是靜態的。技術在變，利益相關者的需求和優先順序在變，業務領域在變，標準和法規在變，等等。因此，聰明的組織在規劃他們的軟體戰略時，會考慮到這些潛在的變化，並計劃進行進化式開發。
演進開發和增量式開發的主要區別在於，在進化式開發中，包含所有需求的完整系統已經在執行中使用了一段時間。與增量開發一樣，演進式開發建立了一系列連續的不同版本的軟體。然而，在演進式開發中，所有的原始需求都被建立在釋出到執行中的軟體的第一次演進中。增量開發技術可以用來建立任何一個使用遺留軟體作為輸入的軟體演化。每個演進都可以使用與其前身演進相同或不同的軟體開發模型。
演進模型的優點之一是，它關注軟體的長期成功，因為它改變並適應利益相關者的需求和其他隨時間發生的變化。只有當前演化的需求是已知的，但這種方法提供了機會，讓客戶/使用者在交付版本時得到驗證和反饋。產品演進可以被出售以資助進一步的開發，併為組織提供利潤。事實上，這些演變很多時候是開發組織的 "現金牛"，因為他們為新的和更新的軟體提供資金，而不需要從頭開始建立一個全新的系統的必要投資。
演進模式的主要弱點可能是時間跨度越長，或者進化的次數越多，有知識的人轉到其他專案甚至其他組織的可能性就越大。對於組織在幾個月甚至幾年內都不知道的需求的長期支援和未來發展需求，努力、費用和其他專案屬性可能很難估計。進化的開發只有在強大的客戶/使用者的參與和投入下才會成功。還有一個風險（和潛在的好處），那就是永無止境的進化。幾十年前建立的軟體仍然在執行，這並不罕見。在某些時候，可能很難找到具有適當技能的員工，或者找到硬體和其他技術，來支援這些非常老的軟體系統。例如，作者知道有一家公司仍在支援一個在20世紀60年代用COBOL編寫的舊的遺留工資系統。他們的產品支援團隊由程式設計師組成，他們的年齡從50多歲到80多歲不等，其中許多人正準備退休，或者已經退休並被重新僱用為顧問。這家公司的管理層找不到想要學習COBOL的年輕程式設計師。當然，解決這個難題的辦法是使用新技術將軟體重新設計成現代程式語言，這也是管理層現在正在進行的主要投資，以便使軟體能夠支援到未來。他們目前正在支付兩個開發團隊的費用，其中一個團隊正在支援舊系統，同時將他們的知識傳授給建立現代版系統的新一代程式設計師。
敏捷軟體開發的生命週期
應用敏捷生命週期和相關的過程模型，並確定它們的好處以及何時使用。
實際上有很多敏捷方法，包括Scrum、極限程式設計（XP）、測試驅動開發（TDD）、功能驅動開發（FDD）、Crystal、精益（本書第7章有討論）、看板等。這些方法中的許多都集中在軟體開發的不同方面，是相互補充的。術語 "敏捷 "或 "敏捷開發 "通常用於描述這些方法中的一種，或這些方法中的幾種的合併，由一個組織採用和調整以滿足其需求，以及其團隊、專案和利益相關者的需求。
敏捷宣言，如圖9.12所示，是2001年在猶他州雪鳥的一次會議上制定的。這是後來被稱為 "敏捷聯盟 "的第一次會議。強調 "右邊的專案有價值 "這句話很重要，因為有些對敏捷方法的批評讓人覺得這種方法拒絕流程、計劃、合同和檔案。"超過 "這個詞是關鍵。宣言中並沒有說 "代替"，而許多批評敏捷方法的人似乎是在暗示。敏捷聯盟（www.agilealliance.com）也定義了以下12條原則來支援敏捷宣言。
"我們的首要任務是透過早期和持續交付有價值的軟體來滿足客戶。歡迎不斷變化的需求，甚至在開發後期。敏捷過程為客戶的競爭優勢駕馭變化。頻繁地交付工作軟體，從幾周到幾個月不等，更傾向於較短的時間範圍。業務人員和開發人員必須在整個專案中每天一起工作。圍繞積極的個人建立專案。給他們需要的環境和支援，並相信他們能完成工作。向開發團隊傳達資訊以及在開發團隊內部傳達資訊的最有效方法是面對面的交談。工作軟體是衡量進展的主要標準。敏捷過程促進可持續發展。贊助商、開發人員和客戶/使用者應該能夠無限期地保持恆定的速度。持續關注卓越的技術和良好的設計可以增強敏捷性。簡潔性，即最大限度地減少未完成的工作的藝術，是至關重要的。最好的架構、需求和設計產生於自我組織的團隊。每隔一段時間，團隊就會反思如何變得更有效，然後相應地調整和調整其行為"。計劃驅動的軟體開發方法學側重於定義程式和方法、人員、工具和裝置如何相互作用的 "規則"。在計劃驅動的方法論中，通常會強調對過程問題的技術解決方案。
敏捷方法主要關注的是客戶、開發者和產品之間的溝通，因為這三者之間的行為非常重要。開發者必須與客戶溝通，瞭解他們的需求以及對這些客戶的附加價值。然後，開發人員建立產品，並透過審查和測試與該產品溝通，以驗證該產品是否符合其規格。產品透過頻繁的原型和建成後的產品演示與客戶溝通，這樣客戶就可以驗證產品是否符合其預期用途並按需要工作。然後，客戶將任何問題和額外的需求傳達給開發人員，反饋繼續進行。這種頻繁的、高質量的溝通提供了一個持續的反饋迴路，以確認正確的產品正在被正確地構建，並在開發週期的早期發現問題，提高最終產品的質量。
敏捷方法強調社會學解決方案。敏捷社群認為，"關注技能、溝通和社群可以使專案更有效、更敏捷。"敏捷軟體開發使用的不是以技術為導向的規則，而是 "輕鬆但充分的專案行為規則 "和 "以人和溝通為導向的規則"（Cockburn 2002）。然後，這些解決方案與適當的技術搭配，以提高效率（例如，促進測試自動化的工具，持續部署，等等）。
敏捷方法適用於 "不確定的需求和不可預測的實施風險 "的軟體開發工作。如果開發工作 "依賴於知識創造和協作"，敏捷方法可能比計劃驅動的方法更合適（James 2012）。
兩種最廣為人知和使用的敏捷方法是Scrum和XP（如下所述）。Scrum主要專注於軟體開發的計劃和監控方面，而XP則專注於技術實施技巧。正因為如此，許多組織將Scrum和XP方法結合起來，因為它們可以很好地互補。
Scrum
Scrum這個詞最初來源於橄欖球比賽中的一種策略，它表示透過團隊合作 "讓一個失去比賽的球回到比賽中"（Schwaber 2002）。Scrum是一個軟體開發框架，它定義了一個角色、會議、工作產品和規則的結構。Scrum使用一個短的（例如，兩週或四周）增量開發週期，稱為衝刺。每個衝刺的目標是在衝刺結束時開發一個完整的可交付產品功能的增量。Scrum定義了三個具體的角色和責任。
產品負責人負責建立整體的產品願景，並負責軟體開發工作的投資回報率（ROI）。其他產品負責人的職責包括。為產品的開發獲取初始和持續的資金代表其他利益相關者，充當需求問題、決策和優先順序的最終仲裁者管理、控制並使產品積壓可見，以便每個迭代都能解決產品積壓中最有價值的需求。接受或拒絕每個衝刺階段所完成的軟體版本，並決定產品的交付時間。規劃長期的釋出策略決定何時終止開發Scrum團隊，也叫Scrum開發團隊，是一個自我管理、自我組織的協作團隊，有權做出決定並採取必要的行動來實現每個衝刺的目標。Scrum團隊是跨職能的、多樣化的。該團隊必須包括具有實現軟體所需的所有技能的成員--需求、設計、程式碼、技術出版物、白盒和黑盒測試、質量、配置管理、領域和/或法規專業知識等等。除了這些活動，Scrum團隊還參與了。估算工作量建立衝刺積木幫助產品所有者審查和確定產品積壓的優先次序識別阻礙開發工作的因素理想的Scrum團隊規模是5到9名成員。對於需要更多人參與的大規模開發工作，Scrum方法論建議組建多個Scrum團隊，並使用Scrum of Scrums，由各個Scrum團隊的代表組成，以實現團隊間的協調。Scrum主管負責確保開發工作是按照Scrum的實踐、價值和規則進行的，並確保開發工作按計劃進行。Scrum主管與Scrum團隊、產品所有者和其他利益相關者進行互動，以。
傳授Scrum流程，並充當敏捷教練保護Scrum團隊不受外界干擾和干涉幫助獲取資源和消除障礙幫助採用、調整和持續改進Scrum流程，以滿足Scrum團隊和組織的需求主持衝刺計劃會議、日常Scrum會議、衝刺回顧會議和衝刺回顧會議促進團隊協議的收集，包括關於他們將如何開展工作的協議在每個衝刺期間，捕捉經驗資料以跟蹤進度並確定Scrum團隊的速度（團隊交付工作的總體能力）。在Scrum中，雖然Scrum團隊是自我管理的，但管理層負責最終決策，並制定專案必須遵循的章程、標準和慣例。管理層也參與制定專案的目標、目的和要求。管理層參與選擇產品負責人，衡量進度，並減少產品積壓。
客戶、使用者和其他利益相關者參與到為正在開發或增強的系統確定產品積壓專案的相關工作中。客戶和使用者收到交付的軟體並向Scrum團隊提供反饋。客戶也可能參與選擇產品負責人。
產品積壓定義了所有尚未在軟體中實現的、打算成為最終產品一部分的已知特性（功能和非功能要求）。產品積壓包括對正在建立或增強的系統的業務和技術要求的優先順序和持續更新的列表，通常被表述為使用者故事。產品積壓專案可以包括期望的特性、功能、錯誤修正、缺陷、要求的增強和技術升級。產品積壓也可以包括流程改進。
Scrum過程以願景開始，包括預期的投資回報率、釋出和里程碑。最初的產品積壓包含一個優先考慮的產品需求列表（例如，使用者故事、用例或功能）。隨著時間的推移，會有更多的需求出現，並被優先考慮，新增到產品積壓中。
每個衝刺階段都會有一個由Scrum主管主持的衝刺計劃會議。這個會議實際上是兩個背對背舉行的會議，但許多組織將這兩個會議合併為一個會議。在衝刺計劃會議的第一部分，Scrum團隊和Scrum主管與產品所有者會面，以。
確定一個衝刺 "目標"，這是一個對沖刺期間要實現的整體工作的簡短描述。這個目標被用來集中精力，並在概念上將衝刺聯絡在一起。根據新的資訊，或者自上個衝刺階段以來新增或返回到產品積壓中的任何專案，重新確定產品積壓中剩餘專案的優先次序。對於Scrum團隊就產品積壓中的專案提出的任何問題，包括關於內容、目的、意義和意圖的問題，從產品所有者那裡獲得答案。從產品積壓中選擇Scrum團隊認為在衝刺結束前可以轉化為可交付產品功能的完整增量的專案--建立衝刺積壓。Scrum團隊使用故事點或努力來估計選定的使用者故事。團隊將估計的總數與他們在過去衝刺期間的表現進行比較，以此來衡量他們在衝刺期間的工作投入是否過多或過少。估算和速度在第15章中討論）。Scrum團隊向產品所有者承諾，他們將盡最大努力交付這些選定的專案。在衝刺計劃會議的第二部分，衝刺活動是透過將每個選定的產品積壓專案轉化為實施該專案所需的初步任務集來計劃的。根據需要，也可以增加額外的任務來進行衝刺。團隊可能不會預先知道所有的任務，隨著衝刺的進行，額外的任務可能會被新增到列表中。
在衝刺期間，Scrum團隊透過執行將衝刺積壓專案轉化為一個或多個軟體產品（軟體構建、使用者文件等）的任務，將選定的產品積壓變成功能的增量。在衝刺期間，Scrum團隊還舉行簡短的每日會議，稱為Scrums或每日站立會議。在這些每日Scrums中，每個Scrum團隊成員都要回答三個問題。
自從上次Scrum會議以來，我已經做了什麼工作？在下一次Scrum會議之前，我將做什麼工作？我有哪些障礙（問題或難題）？每個衝刺的主要產出是 "一個潛在的可發貨的產品增量"（Schwaber 2007），這是一個工作軟體（根據商定的 "完成 "的定義進行測試和完成），其質量足以發貨，儘管它可能不具備所有需要實際發貨的功能。當Scrum團隊在衝刺結束時交付新功能時，交付過程包括。
衝刺回顧，Scrum主管和Scrum團隊對上一個衝刺的執行情況進行評估，並根據需要調整團隊的流程和工作協議，以便為下一個衝刺進行改進。在每個Scrum結束時，產品所有者決定產品積壓上是否有足夠的價值繼續進行下一個衝刺。在衝刺期間或衝刺結束時，可能會根據利益相關者的反饋或其他利益相關者的需求來確定新的需求。此外，在剛剛結束的衝刺階段，可能還有不完整的衝刺積壓專案。這些需求將被優先考慮並新增到產品積壓中。然後召開下一次衝刺計劃會議，再次開始這個迴圈，重複這個迴圈，直到所有的功能都被實現，或者產品所有者決定終止開發工作。
積壓改進會議不是Scrum的正式會議之一。然而，許多組織發現這些會議對於為下一次衝刺計劃會議準備產品積壓中的專案很有用。
將大的故事/功能或史詩（一個故事太大，無法在一個衝刺階段實現）分解成小的故事/功能更清楚地定義不容易理解或模糊的故事/功能與利益相關者進行額外的對話，以確定故事的接受標準重新確定新增或改進專案的優先次序極限程式設計
極限程式設計（XP）是一種敏捷的迭代開發方法，它將敏捷開發的思想帶到了極致。XP包括測試驅動開發（TDD）技術，開發人員首先編寫一個當前軟體無法透過的測試，因為他們還沒有編寫相應的程式碼，然後編寫能夠透過該測試的程式碼。使用重構，開發人員然後改善該程式碼的質量，消除任何重複的、複雜的或笨拙的結構。這就建立了Beck（2005）所說的測試--程式碼--重構，測試--程式碼--重構的自然和有效的 "節奏"。
XP基於以下價值觀，其中許多是整個敏捷社群共有的。
溝通。XP強調溝通。根據Beck（2005），"在團隊軟體開發中最重要的是溝通"。簡潔性。為了避免對模糊理解的需求和結構的承諾，XP要求設計保持在最基本的東西上，可以在下一次交付/迭代的時間範圍內提供所需的功能。一個直截了當的、被廣泛溝通和理解的軟體結構意味著人們需要正式 "溝通 "的東西會減少。這有助於消除可能混淆有效溝通的含糊不清之處。XP創造了一個縮寫YAGNI，"你不需要它"，以強調不要添加當前（已知）功能不需要/不會需要的結構和設計。如果你認為你將來可能需要它，那就等到將來再新增它（基於Succi 2001）。然而，YAGNI並不意味著你不能擁有複雜的軟體。YAGNI只是意味著軟體應該儘可能的簡單，並且仍然滿足客戶的需求。反饋。XP實踐者認為，因為事情會發生變化，所以必須縮短反饋週期，從幾周或幾個月，縮短到幾分鐘或幾小時。XP團隊不斷努力獲得並利用盡可能多的反饋。勇氣。勇氣有時會表現為一個人在遇到障礙時願意去做或嘗試一些事情，犯錯誤，從錯誤中學習，拋棄不可行的東西，重新開始。在其他時候，勇氣可能意味著等待、傾聽和學習，直到一個更好的、更簡單的解決方案出現。XP實踐者必須有勇氣說出真相，承認真正存在的東西並處理它。尊重。如果任何一個人的貢獻不被其他成員所重視，那麼這個團隊就不可能像它應該/可以的那樣有效。團隊還必須有強烈的成功動機和對工作環境的熱情。為了達到這個目的，團隊成員必須互相尊重，尊重專案，以建立信任和集體責任。XP提倡以下原則，其中許多也是整個敏捷社群共有的。
經濟性。XP方法透過以下方式關注經濟性。推遲成本。鼓勵專案在做出設計/開發承諾之前，"等到最後的責任時刻"。賺取報酬。承諾儘快交付有價值的、可執行的軟體，並在此後經常交付，這意味著客戶將獲得軟體的好處，而開發組織將更快收到付款。軟體再利用。建立用於重複使用的軟體意味著它的價值可以被反覆實現，而不是僅僅一次。業務調整。強調與客戶的互動和反饋，創造出的軟體產品更有可能具有商業價值，與商業目標和目的相一致，並滿足企業的需求。互利：互利意味著關注那些現在為利益相關者、現在為開發者、以及以後為利益相關者和開發者提供價值的活動和產品。接受的責任：XP團隊成員 "簽署 "實施任務。也就是說，一旦下一次迭代的需求清單被定義、優先順序被確定，並被分解為實現這些功能所需的任務，開發人員就會自行分配這些任務。冗餘：這意味著使用目標相似的冗餘活動，只要它們能增加價值。例如，在使用結對程式設計後進行測試是多餘的，因為這兩種活動都是為了消除缺陷--然而，在實踐中，測試通常會發現在開發中沒有發現的額外缺陷，所以測試是增值的。自我相似性：尋找有效的模式並在其他地方重複它們。尋找能幫助你用昨天的解決方案解決今天的問題的模式。除非是唯一的選擇，否則不要去用獨特的解決方案來解決管理或流程問題，也不要用需求、設計或程式碼解決方案。質量。質量必須建立在軟體中。引用Beck（2005）的話。"把質量推得更高，往往會導致更快的交付；而降低質量標準，往往會導致更晚、更難預測的交付。""質量的好處沒有明顯的限制，只有我們理解如何實現質量的能力的限制。""質量不是一個純粹的經濟因素。人們需要做他們感到自豪的工作。"流程：XP認為軟體開發是一個從一個迭代到下一個迭代的連續流程，而不是一組離散的階段。失敗。失敗不是浪費，它使我們能夠從錯誤中學習。試驗和錯誤可能是發現什麼是有效的最便宜的方法。機會。學會把問題看作是機會。改進我們做事的方式創造更好的軟體建立人際關係拓展我們的個人知識和技能組合團隊和組織學習反思：改進來自於對問題（或潛在問題）原因的學習，以及找到糾正（或避免）問題的解決方案。XP要求團隊不斷思考他們在做什麼和為什麼。這提供了輸入和反饋，允許立即重用好的想法和快速消除問題。我們不應該隱藏我們的錯誤。我們應該暴露它們並從中學習。人性化：XP增加了對人的問題的關注，以便人們和團隊能夠緊密合作。這種關注對那些習慣於作為個人貢獻者工作的人來說可能是新的，甚至是不舒服的。改進：敏捷方法和計劃驅動方法都認為，持續改進是有效和高效地實現更高質量和增值的軟體的最佳途徑。小步走。XP強調以小步快跑的方式做出改變。團隊應該尋找最起碼的方向，然後對變化進行優先排序，並逐步實施，這樣可以減少開銷和風險。多樣性：在團隊中擁有多樣性可以幫助產生積極的衝突（新的想法、不同的意見、替代的方法）。為了將其價值和原則落實到軟體開發的日常工作中，XP包括一套主要和必然的實踐。XP的主要實踐包括。
團隊共處：軟體應該在一個足夠大的工作空間裡開發，以便整個團隊，包括客戶，都能在一個空間裡一起工作。整個團隊。在實施XP專案時，整個跨職能、自我指導的XP團隊作為一個單位工作，以完成其目標。資訊化的工作空間: XP團隊利用工作空間的牆壁來傳達重要的、活躍的資訊。一目瞭然，人們應該能夠感受到專案的進展情況，並能夠僅僅透過檢視工作區周圍張貼的資訊就能發現當前或潛在的問題。有活力的工作：XP強調在可持續的節奏下，從業者只需工作儘可能多的時間就能有成效（每天8小時，每週40小時，不生病來上班）。- XP也鼓勵在工作時有合理的玩耍時間，以使個人恢復活力並激發創造力。故事: 開發人員透過要求他們的利益相關者講述關於誰將使用該系統，如何使用該系統，以及為什麼使用的故事來建立系統的需求。這些故事被記錄下來，成為第一層次的優先需求，只有在選擇實施時才會充實到更多細節。季度週期。以季度為週期，計劃（Beck 2005）。"識別瓶頸--特別是那些在團隊之外控制的瓶頸專注於大局--專案在組織中的位置啟動修復計劃本季度的主題挑選一個季度的故事來解決這些主題"每週的週期。團隊的工作是編寫測試用例，並在接下來的五天內讓它們執行。召開每週計劃會議，以。審查實際進展與預期進展的匹配情況選擇該周要實施的客戶故事根據需要，進一步重新定義每個故事的要求和接受標準估計實施每個故事所需的工作時間將故事劃分為任務讓每個團隊成員自行選擇他們負責執行的任務鬆弛：理想情況下，團隊將在所需的時間內完成所有承諾的工作，但在每週的時間表中留有一些鬆弛，以便在每週的週期內彌補任何不可預見的事件。結對程式設計：結對程式設計涉及兩個人，其中一個人不斷審查另一個人正在開發的東西。關於結對程式設計的更多細節見第22章）。測試驅動的開發（TDD）：TDD主張在編寫程式碼之前，先編寫程式碼必須透過的測試用例。漸進式設計。一般來說，敏捷方法，特別是XP，不寫一些所謂的大設計在前面（BDUF）。也就是說，設計是隨著時間的推移而出現的，透過逐步的、持續的努力，致力於反思系統中已經存在的東西和接下來需要的東西。持續整合：XP實踐在持續的基礎上將每一塊改變的（或新的）軟體程式碼整合到系統中，在程式碼改變的幾個小時內建立並測試一個新的構建。這是與傳統的瀑布式生命週期行為相反的一端，所有（或大部分）的軟體程式碼在整合開始前就已經寫好。10分鐘的構建。要想在XP專案中頻繁地進行整合，必須能夠非常快速地構建系統和執行測試。10分鐘構建所代表的目標就是要使之成為可能。XP的必然做法包括。
團隊的連續性：高績效的團隊應該長期保持在一起。真正的客戶參與。Martin (2003)說，客戶是 "定義和優先考慮功能的人或團體"。客戶需要與開發團隊保持密切聯絡（如果不是團隊的實際成員），並透過積極參與軟體的定義和驗證（編寫測試用例，甚至可能執行測試用例）來對軟體負責。協商範圍：XP哲學說，如果在一個給定的增量中，有什麼東西必須 "滑落"，那應該是範圍（功能），而不是操縱成本、進度或質量。由於範圍縮小而錯過的功能被移到下一個增量。單一程式碼庫：正如前面討論持續整合時指出的，保持單一程式碼基線是非常理想的。然而，分支可以在短時間內出現，然後透過頻繁的整合將其重新整合在一起，至少每天都要做。共享程式碼。在團隊有了集體責任感之後，團隊中的任何人都可以在任何時候改進系統的任何部分（Beck 2005）。這需要採用全團隊的編碼標準。"如果需要進行改變，處於最佳狀態的人（看到立即需要改變的開發者）可以進行改變"（Astels 2002）。程式碼和測試。XP的 "最小化 "文件方法表明，程式碼和測試應該是任何其他文件的基礎，而不是相反。無論好壞，產品就是軟體的作用，所以軟體程式碼和測試是記錄產品能力的最終權威。漸進式部署。透過在專案的早期和之後經常遞增地部署軟體，專案可以定期地展示有形的工作成果。這使得客戶也能經常提供有用的反饋，因此，在完成工作和反映工作之間幾乎沒有時間間隔。對小增量的審查允許經常調整專案方向和快速識別缺陷。對每個小增量的規劃也更準確。每日部署。XP的理想是每天把工作的軟體送到客戶的手中。除了在小的情況下，由於各種原因，這可能是不實際的。然而，重要的是要認識到，軟體不被積極使用的時間越長，開發就越有可能偏離客戶的最終需求（即使它符合客戶最初認為有意義的方向）。