軟件開發(fā)生命周期(SDLC Software development life cycle)和過程模型是軟件開發(fā)過程的高級表示昼弟。這些模型定義了軟件開發(fā)所經歷的階段（phase）汹想，以及在每個階段所進行的活動在岂。每個SDLC模型代表一個軟件項目、迭代或增量玖姑，從構思到該版本的產品完成和/或發(fā)布吐辙。
軟件產品生命周期模型代表了軟件產品的生命周期，從構思到產品退役穿挨。對于一個成功的軟件產品來說月弛，產品生命周期通常包含了多次通過軟件開發(fā)生命周期或過程模型的過程。
生命周期和過程模型為各個軟件開發(fā)過程的詳細定義提供框架（最高級別的過程架構）科盛。定義好的模型作為開發(fā)團隊的路線圖帽衙，確保在軟件開發(fā)過程中實施所有必要的和經過驗證的步驟，以便生產出高質量的產品贞绵。遵循預先定義的模型及其相關流程厉萝，有助于確認包括提高質量的關鍵步驟。這些模型描述了主要里程碑榨崩、基線和項目交付物之間的相互關系谴垫。這些模型可以幫助項目經理和/或團隊計劃活動和跟蹤進度，將開發(fā)工作分成幾個階段母蛛，每個階段都有一套確定的活動翩剪，包括階段過渡審查。這些模型還提供了一個一致的框架彩郊，用于前弯。

• 收集經驗教訓
• 實施過程改進
• 比較多個項目的結果
• 建立衡量標準
• 提供有用的組織流程資產，可用于更好地估計和規(guī)劃未來的開發(fā)焦辅、維護和收購項目博杖。

這些模型多年來通過經驗和研究不斷完善。組織可以從這些改進中學習筷登，然后采用和調整自己的生命周期和過程模型剃根，以符合他們的需求、業(yè)務領域前方、文化和軟件開發(fā)方法狈醉。

瀑布模型

瀑布模型

瀑布模型是基于這樣一個概念：軟件開發(fā)可以被認為是簡單的階段序列。每個階段從開始到結束惠险，然后才開始下一個階段苗傅。瀑布模型中一個階段產生的工作產品通常是后續(xù)階段的輸入。瀑布模型的前提是班巩，一個項目可以在開始之前就進行規(guī)劃渣慕，并通過開發(fā)以合理有序的方式進行。在瀑布模型中抱慌，在設計開始之前逊桦，一組定義明確的需求被指定，在編碼開始之前抑进，設計已經完成强经，產品在建成之后被測試。

在實際項目中寺渗，階段的數量取決于項目的需求和進行項目的組織匿情。有些瀑布模型只包括向下的箭頭兰迫，描述了活動在開發(fā)項目中向下的流動。這個例子還包括向上的箭頭炬称，表示在開發(fā)活動中允許一些迭代汁果。

許多批評瀑布模型的人說，它已經過時了玲躯，不能反映軟件開發(fā)中的真實情況须鼎。然而模型是從一個特定的角度對一個項目或過程的抽象表述。模型是一種簡化府蔗，旨在表達項目或過程的某些方面的要點，而不提供不必要的細節(jié)汞窗。模型的目的是使有關人員能夠思考和討論這些基本要素姓赤，而不被所有的細節(jié)所困擾。在這方面仲吏，瀑布模型仍然是一個有用的工具不铆，因為它是一個容易理解和討論的模型。即使是最不成熟的利益相關者也能理解瀑布模型的基本概念裹唆。誠然瀑布模型幾乎刪除了所有的細節(jié)誓斥，包括開發(fā)過程中通常發(fā)生的大部分迭代，但這些細節(jié)中的許多可能在模型下的較低級別的過程定義中得到說明许帐。

瀑布模型是第一個定義軟件開發(fā)的規(guī)范化方法的模型劳坑，易于理解，定義明確成畦。瀑布模型的優(yōu)點之一是它與軟件開發(fā)的可交付成果直接相關距芬，這可以幫助項目管理活動。有許多工具可以支持瀑布模型循帐。

瀑布模型的主要弱點是框仔，大多數（如果不是全部）需求必須在開發(fā)之初就知道。瀑布模型不容易適應變化拄养。軟件產品在項目完成或接近完成時才可以使用离斩，所以該模型不包括對利益相關者的中間反饋的規(guī)定，盡管在基于瀑布的開發(fā)過程中可以使用原型來提供早期反饋瘪匿。
瀑布模型最適合于那些需求是已知的并且預期是穩(wěn)定的項目跛梗，并且開發(fā)過程預期會以一種有序的、有紀律的方式進行柿顶。例如茄袖，瀑布模型可能適合于將現有產品移植到一個新的平臺、環(huán)境或語言的項目嘁锯，其中的限制因素是眾所周知的宪祥。其他的例子可能包括更新軟件以符合新的政府法規(guī)的增強項目聂薪，或者使目前正在手工執(zhí)行的報告自動化的項目。瀑布式生命周期模型也適用于只有幾個有經驗的程序員和許多初級程序員的項目蝗羊，或者是在非常成熟的領域中的新開發(fā)項目藏澳，即正在建立的另一個軟件產品，就像上一個產品耀找。瀑布模型通常不適合于需求模糊或預期具有高波動性的項目翔悠，或預期不會以線性方式進展的項目。對于大型的野芒、高風險的項目蓄愁，更多基于風險的方法，如螺旋模型或增量開發(fā)可能比瀑布模型更合適狞悲。

V型模型

V型模型是瀑布模型的一個變種撮抓，它強調了測試階段和生命周期早期階段產生的產品之間的關系，驗收測試根據概念階段定義的利益相關者的需求來評估軟件摇锋，系統(tǒng)測試根據需求階段指定的產品級需求來評估軟件丹拯，以此類推。測試規(guī)劃和設計可以在相應的早期開發(fā)階段顯著完成后立即開始荸恕。例如乖酬，一旦相當數量的利益相關者的需求（概念，在例子中）被定義融求，驗收測試規(guī)劃和設計就可以開始了咬像。一旦相當數量的產品級需求被定義，系統(tǒng)測試規(guī)劃和設計就可以開始了双肤。

W-模型

W模型是瀑布模型的另一種變體施掏。W模型有兩條路徑（或稱交叉V），每條路徑都代表一個獨立的組織或獨立團隊在開發(fā)過程中的生命周期茅糜。第一條路徑代表開發(fā)組織/團隊七芭，負責開發(fā)需求、設計和代碼蔑赘。第二條路徑代表獨立的驗證和確認（V&V）組織狸驳，負責獨立分析、審查和測試軟件生命周期各階段的工作成果缩赛。

遞增/迭代式軟件開發(fā)生命周期

螺旋模型

螺旋模型最初由Boehm（1988）定義耙箍，是一個基于風險的過程模型，它在以前的模型基礎上擴展了細節(jié)酥馍，包括替代方案的探索辩昆、原型設計和規(guī)劃。螺旋模型將軟件開發(fā)的每個周期細分為四個象限旨袒。然后汁针，生命周期的活動以螺旋方式納入這四個象限术辐，從中間的概念階段開始。

• 確定目標施无、備選方案和約束條件辉词。開發(fā)團隊確定該周期的目標、替代方案和約束條件猾骡。例如瑞躺，在概念階段，這可能包括探索購買和建造的替代方案兴想，或確定在項目中應該解決哪些業(yè)務層面和/或利益相關者層面的要求幢哨。
• 識別和解決風險，評估替代方案嫂便，并選擇方法：評估替代方案嘱么，識別和分析風險，并可能進行原型設計顽悼，以選擇最適合該項目周期的方法。例如几迄，對于概念階段蔚龙，這可能包括風險識別和分析購買和建造的選擇，對替代方案的成本/效益分析映胁，以及原型設計木羹，以評估選擇，以確定在內部建造軟件是否是合適的決定解孙。
• 開發(fā)和V&V下一層次的產品坑填。開發(fā)該階段的軟件產品，并對這些產品進行V&V活動弛姜。這也可能包括創(chuàng)建模擬脐瑰、模型或基準，如果合適的話廷臼。例如苍在，對于概念階段，這可能包括征詢荠商、分析和指定業(yè)務層面和利益相關者層面的需求寂恬，并執(zhí)行V&V活動來驗證這些需求。
• 計劃下一個階段莱没。在這前三項活動中初肉，會做出一些決定并獲得一些影響項目計劃的額外信息。因此饰躲，在螺旋模型的第四個活動中牙咏，項目計劃被逐步闡述臼隔，為后續(xù)周期提供更多的細節(jié)。這第四步通常以審查和/或其他周期過渡活動結束眠寿。例如躬翁，對于概念階段，這可能包括使用概念階段前三個活動的信息和決定來更新需求階段和其他后續(xù)階段的項目計劃盯拱。

然后盒发，這四個象限被重復用于需求周期和高層（架構）設計周期。隨著詳細設計周期的前兩項活動的完成狡逢，項目的大部分主要決定已經做出宁舰，螺旋模型完成了第三項活動，其中包括詳細設計規(guī)范和V&V奢浑、編碼和代碼V&V蛮艰、單元測試、集成和測試雀彼、系統(tǒng)測試壤蚜、驗收測試和運營。與其他所有的軟件開發(fā)生命周期模型一樣徊哑，螺旋模型可以根據項目和組織的需要進行調整袜刷。

螺旋模型將重點從產品開發(fā)轉移到風險分析和規(guī)避上。螺旋模型把注意力集中在早期探索選項上莺丑，通過原型設計獲得反饋著蟹，以驗證正確的產品是以最合適的方式建立的。螺旋模型還包括處理變化的機制梢莽，通過任何給定的活動或周期的迭代萧豆，在進入下一個周期之前，根據需要多次進行昏名。螺旋模型通過強調在獲得更多信息時對項目計劃的更新涮雷，納入了堅實的項目管理技術。
Boehm（2000）列出了成功應用螺旋模型的六個共同特征轻局。

• "同時而不是按順序確定工件
• 在每個螺旋循環(huán)中考慮主要的螺旋要素份殿。
  • 關鍵利益相關者的目標和約束
  • 產品和過程的選擇
  • 風險識別和解決
  • 利益相關者審查
  • 承諾進行
• 使用風險考慮來確定每個螺旋周期內每個活動的努力程度
• 使用風險考慮因素來確定每個螺旋周期中產生的每個工件的詳細程度
• 用三個錨點里程碑來管理利益相關者的生命周期承諾。
  • 生命周期目標(LCO)
  • 生命周期結構(LCA)
  • 初始運行能力（IOC

強調系統(tǒng)和生命周期的活動和工件嗽交，而不是軟件和初始開發(fā)卿嘲。

螺旋模型是一個復雜的模型，一些利益相關者并不了解或不容易掌握夫壁，因此利益相關者可能會發(fā)現它難以溝通和使用拾枣。螺旋模型需要高水平的風險管理技能和分析技術，這使得它比其他模型更依賴于人。這也意味著梅肤，螺旋模型需要一個強大的司蔬、熟練的項目經理。螺旋模型的一個弱點是姨蝴，它不像基于瀑布模型那樣與根據合同進行的軟件開發(fā)的需求相關（例如俊啼，與控制、檢查點和中間交付的映射）左医。

螺旋模型適合于那些軟件開發(fā)方法是非線性的和/或包含多種需要探索的替代方法的項目授帕。對于較小的、低風險的浮梢、直接的項目跛十，額外的風險管理、分析和計劃步驟可能會增加不必要的額外成本和/或努力秕硝。由于螺旋模型具有廣泛的靈活性和自由度芥映，固定成本或固定進度的項目可能不適合使用這種模型。螺旋模型也可能不是經驗不足的項目的合適選擇远豺。

迭代模式

迭代模型其中的步驟或活動被重復多次奈偏。這樣做可能是為了給需求、設計躯护、代碼或測試增加更多的細節(jié)霎苗，也可能是為了實現小塊的新功能，一個接一個榛做。有許多不同的迭代模型。例如内狸，上面討論的螺旋模型可以作為一個迭代模型來實現检眯，下面的敏捷軟件開發(fā)生命周期小節(jié)中描述的測試驅動開發(fā)和功能驅動開發(fā)方法也是迭代模型。迭代模型中開發(fā)周期從短期的昆淡、集中的計劃開始锰瘸，它定義了在該迭代中要實現的功能。每個周期包括設計昂灵、編寫測試避凝、開發(fā)代碼、執(zhí)行測試眨补，并將成功開發(fā)的代碼整合到該周期的 "基線 "中管削，然后再設計、編寫測試撑螺，如此循環(huán)含思。這個過程持續(xù)進行，在各個環(huán)節(jié)都有反饋（來自其他開發(fā)者、客戶含潘、用戶和/或其他利益相關者饲做，以及軟件本身），直到功能在分配給增量的時間范圍內完成遏弱。然后盆均，該增量的輸出被發(fā)布給利益相關者，他們可能會試用并投入運行漱逸，或者只是為下一個開發(fā)周期（迭代）提供反饋泪姨。

迭代模型的好處包括不需要預先知道所有的需求。明確的需求可以在軟件中實現虹脯，而較模糊的需求正在被調查和/或穩(wěn)定下來驴娃。新的需求可以被添加到未來的迭代中，因為它們被確認循集。將高風險的產品/項目分解成更小的部分唇敞，也有助于減少風險。構建在迭代模型中的連續(xù)反饋回路提供了學習的循環(huán)咒彤，有助于消除類似錯誤在產品其他部分的傳播疆柔，并允許以更大的信心在產品中構建質量。

增量開發(fā)

增量開發(fā)是指通過使用軟件開發(fā)的多次傳遞镶柱，構建越來越大的軟件需求子集的過程旷档。在增量開發(fā)中，需求被確定后歇拆，它們被優(yōu)先分配到計劃的增量中鞋屈，每個增量都是軟件開發(fā)的一個環(huán)節(jié)。每一個后續(xù)的版本/發(fā)行都是可用的故觅，但只具有部分功能（除了最后一次交付厂庇，它包括所有的需求）。每個增量可以有自己的軟件開發(fā)生命周期模型（例如输吏，瀑布式权旷、V型、迭代式）贯溅。不要求每個增量都使用相同的模型拄氯。例如，前兩個增量可以使用瀑布模型它浅，而下一個增量可以改用迭代模型译柏。

增量開發(fā)可以按順序進行，即在開始下一個增量之前完成一個增量姐霍。這些增量也可以平行進行艇纺。

增量開發(fā)的主要優(yōu)勢之一是建立較小的子集比建立一個大系統(tǒng)的風險要小。這使得客戶/用戶可以收到和/或評估產品的早期版本，其中包含他們最優(yōu)先的操作需求黔衡。這提供了比傳統(tǒng)瀑布式項目更早的驗證和反饋的機會蚓聘。增量開發(fā)也能很好地適應變化。如果在增量的開發(fā)過程中發(fā)現了新的或變化的需求盟劫，它們可以被分配到未來的增量中夜牡，而不會擾亂當前開發(fā)周期的時間表和計劃。然而侣签，如果新的或改變的需求有足夠高的優(yōu)先級塘装，以至于它們必須被添加到當前的版本中，那么要么是優(yōu)先級較低的未實施的需求可以滑落到下一個增量中影所，要么是更新的時間表和其他計劃可能需要重新協商蹦肴。

增量開發(fā)模式的一個弱點是，大部分的需求仍然必須在前面知道猴娩。根據系統(tǒng)和項目所使用的開發(fā)方法阴幌，可能需要額外的工作來創(chuàng)建一個能夠支持整個系統(tǒng)的架構，并且足夠開放以接受每一個新的功能增量的加入卷中。每個發(fā)布的增量必須是一個完整的工作系統(tǒng)矛双，即使它不包括所有的預期功能。因此蟆豫，增量開發(fā)對如何選擇特定增量的內容是很敏感的议忽，如果它是為了發(fā)布到運營中。例如十减，如果在以后的版本中才安排核銷庫存的功能栈幸，那么發(fā)布一個允許核銷庫存的庫存控制系統(tǒng)增量是不可行的。遞增式開發(fā)還將產品的某些部分提前置于配置控制之下帮辟，從而要求正式的變更程序速址，以及相關的增加的開銷，提前開始织阅。最后，增量開發(fā)的好處之一是能夠更快地將高優(yōu)先級的軟件功能送到客戶/用戶手中震捣，從而更早地獲得他們的反饋荔棉。然而，這也可能是一個弱點蒿赢，如果軟件的質量不好润樱。換句話說，開發(fā)組織可能忙于修復上一個增量中的缺陷羡棵，而沒有時間為下一個增量進行新的開發(fā)壹若。

增量開發(fā)不需要迭代產品生命周期，但它們經常被一起使用。術語迭代開發(fā)和迭代正在被使用店展，特別是在敏捷社區(qū)养篓，一般是指增量產品生命周期和迭代開發(fā)生命周期的結合。例如極限編程的流程原則將迭代開發(fā)周期與增量產品開發(fā)相結合赂蕴，一個迭代的輸出成為下一個迭代的輸入柳弄，以此類推。

演進開發(fā)

進化開發(fā)發(fā)生在現有的運行中的軟件產品被更新以實現完善性概说、適應性或預防性維護碧注。演進開發(fā)發(fā)生在一個軟件產品成功的時候。如果客戶/用戶喜歡這個產品糖赔，他們會想繼續(xù)使用它萍丐，但運行環(huán)境很少是靜態(tài)的。技術在變放典，利益相關者的需求和優(yōu)先級在變逝变，業(yè)務領域在變，標準和法規(guī)在變刻撒，等等骨田。因此，聰明的組織在規(guī)劃他們的軟件戰(zhàn)略時声怔，會考慮到這些潛在的變化态贤，并計劃進行進化式開發(fā)。

演進開發(fā)和增量式開發(fā)的主要區(qū)別在于醋火，在進化式開發(fā)中悠汽，包含所有需求的完整系統(tǒng)已經在運行中使用了一段時間。與增量開發(fā)一樣芥驳，演進式開發(fā)建立了一系列連續(xù)的不同版本的軟件柿冲。然而，在演進式開發(fā)中兆旬，所有的原始需求都被建立在發(fā)布到運行中的軟件的第一次演進中假抄。增量開發(fā)技術可以用來建立任何一個使用遺留軟件作為輸入的軟件演化。每個演進都可以使用與其前身演進相同或不同的軟件開發(fā)模型丽猬。

演進模型的優(yōu)點之一是宿饱，它關注軟件的長期成功，因為它改變并適應利益相關者的需求和其他隨時間發(fā)生的變化脚祟。只有當前演化的需求是已知的谬以，但這種方法提供了機會愧驱，讓客戶/用戶在交付版本時得到驗證和反饋桑滩。產品演進可以被出售以資助進一步的開發(fā)，并為組織提供利潤伪朽。事實上，這些演變很多時候是開發(fā)組織的 "現金牛"铭乾，因為他們?yōu)樾碌暮透碌能浖峁┵Y金剪廉，而不需要從頭開始創(chuàng)建一個全新的系統(tǒng)的必要投資。

演進模式的主要弱點可能是時間跨度越長片橡，或者進化的次數越多妈经，有知識的人轉到其他項目甚至其他組織的可能性就越大。對于組織在幾個月甚至幾年內都不知道的需求的長期支持和未來發(fā)展需求捧书，努力吹泡、費用和其他項目屬性可能很難估計。進化的開發(fā)只有在強大的客戶/用戶的參與和投入下才會成功经瓷。還有一個風險（和潛在的好處）爆哑，那就是永無止境的進化。幾十年前建立的軟件仍然在運行舆吮，這并不罕見揭朝。在某些時候，可能很難找到具有適當技能的員工色冀，或者找到硬件和其他技術潭袱，來支持這些非常老的軟件系統(tǒng)。例如锋恬，作者知道有一家公司仍在支持一個在20世紀60年代用COBOL編寫的舊的遺留工資系統(tǒng)屯换。他們的產品支持團隊由程序員組成，他們的年齡從50多歲到80多歲不等与学，其中許多人正準備退休彤悔，或者已經退休并被重新雇用為顧問。這家公司的管理層找不到想要學習COBOL的年輕程序員索守。當然晕窑，解決這個難題的辦法是使用新技術將軟件重新設計成現代編程語言，這也是管理層現在正在進行的主要投資卵佛，以便使軟件能夠支持到未來杨赤。他們目前正在支付兩個開發(fā)團隊的費用，其中一個團隊正在支持舊系統(tǒng)截汪，同時將他們的知識傳授給建立現代版系統(tǒng)的新一代程序員疾牲。

敏捷軟件開發(fā)的生命周期

應用敏捷生命周期和相關的過程模型，并確定它們的好處以及何時使用挫鸽。

實際上有很多敏捷方法说敏，包括Scrum鸥跟、極限編程（XP）丢郊、測試驅動開發(fā)（TDD）盔沫、功能驅動開發(fā)（FDD）、Crystal枫匾、精益（本書第7章有討論）架诞、看板等。這些方法中的許多都集中在軟件開發(fā)的不同方面干茉，是相互補充的谴忧。術語 "敏捷 "或 "敏捷開發(fā) "通常用于描述這些方法中的一種，或這些方法中的幾種的合并角虫，由一個組織采用和調整以滿足其需求沾谓，以及其團隊、項目和利益相關者的需求戳鹅。

敏捷宣言均驶，如圖9.12所示，是2001年在猶他州雪鳥的一次會議上制定的枫虏。這是后來被稱為 "敏捷聯盟 "的第一次會議妇穴。強調 "右邊的項目有價值 "這句話很重要，因為有些對敏捷方法的批評讓人覺得這種方法拒絕流程隶债、計劃腾它、合同和文件。"超過 "這個詞是關鍵死讹。宣言中并沒有說 "代替"瞒滴，而許多批評敏捷方法的人似乎是在暗示。
敏捷聯盟（www.agilealliance.com）也定義了以下12條原則來支持敏捷宣言回俐。

• "我們的首要任務是通過早期和持續(xù)交付有價值的軟件來滿足客戶逛腿。
• 歡迎不斷變化的需求，甚至在開發(fā)后期仅颇。敏捷過程為客戶的競爭優(yōu)勢駕馭變化单默。
• 頻繁地交付工作軟件，從幾周到幾個月不等忘瓦，更傾向于較短的時間范圍搁廓。
• 業(yè)務人員和開發(fā)人員必須在整個項目中每天一起工作。
• 圍繞積極的個人建立項目耕皮。給他們需要的環(huán)境和支持境蜕，并相信他們能完成工作。
• 向開發(fā)團隊傳達信息以及在開發(fā)團隊內部傳達信息的最有效方法是面對面的交談凌停。
• 工作軟件是衡量進展的主要標準粱年。
• 敏捷過程促進可持續(xù)發(fā)展。贊助商罚拟、開發(fā)人員和客戶/用戶應該能夠無限期地保持恒定的速度台诗。
• 持續(xù)關注卓越的技術和良好的設計可以增強敏捷性完箩。
• 簡潔性，即最大限度地減少未完成的工作的藝術拉队，是至關重要的弊知。
  最好的架構、需求和設計產生于自我組織的團隊粱快。
• 每隔一段時間秩彤，團隊就會反思如何變得更有效，然后相應地調整和調整其行為"事哭。

計劃驅動的軟件開發(fā)方法學側重于定義程序和方法漫雷、人員、工具和設備如何相互作用的 "規(guī)則"鳍咱。在計劃驅動的方法論中珊拼，通常會強調對過程問題的技術解決方案。

敏捷方法主要關注的是客戶流炕、開發(fā)者和產品之間的溝通澎现，因為這三者之間的行為非常重要。開發(fā)者必須與客戶溝通每辟，了解他們的需求以及對這些客戶的附加價值剑辫。然后，開發(fā)人員創(chuàng)建產品渠欺，并通過審查和測試與該產品溝通妹蔽，以驗證該產品是否符合其規(guī)格。產品通過頻繁的原型和建成后的產品演示與客戶溝通挠将，這樣客戶就可以驗證產品是否符合其預期用途并按需要工作胳岂。然后，客戶將任何問題和額外的需求傳達給開發(fā)人員舔稀，反饋繼續(xù)進行乳丰。這種頻繁的、高質量的溝通提供了一個持續(xù)的反饋回路内贮，以確認正確的產品正在被正確地構建产园，并在開發(fā)周期的早期發(fā)現問題，提高最終產品的質量夜郁。

敏捷方法強調社會學解決方案什燕。敏捷社區(qū)認為，"關注技能竞端、溝通和社區(qū)可以使項目更有效屎即、更敏捷。"敏捷軟件開發(fā)使用的不是以技術為導向的規(guī)則事富，而是 "輕松但充分的項目行為規(guī)則 "和 "以人和溝通為導向的規(guī)則"（Cockburn 2002）技俐。然后埃撵，這些解決方案與適當的技術搭配，以提高效率（例如虽另，促進測試自動化的工具，持續(xù)部署饺谬，等等）捂刺。

敏捷方法適用于 "不確定的需求和不可預測的實施風險 "的軟件開發(fā)工作。如果開發(fā)工作 "依賴于知識創(chuàng)造和協作"募寨，敏捷方法可能比計劃驅動的方法更合適（James 2012）族展。

兩種最廣為人知和使用的敏捷方法是Scrum和XP（如下所述）。Scrum主要專注于軟件開發(fā)的計劃和監(jiān)控方面拔鹰，而XP則專注于技術實施技巧仪缸。正因為如此，許多組織將Scrum和XP方法結合起來列肢，因為它們可以很好地互補恰画。

Scrum

Scrum這個詞最初來源于橄欖球比賽中的一種策略，它表示通過團隊合作 "讓一個失去比賽的球回到比賽中"（Schwaber 2002）瓷马。Scrum是一個軟件開發(fā)框架拴还，它定義了一個角色、會議欧聘、工作產品和規(guī)則的結構片林。Scrum使用一個短的（例如，兩周或四周）增量開發(fā)周期怀骤，稱為沖刺费封。每個沖刺的目標是在沖刺結束時開發(fā)一個完整的可交付產品功能的增量。Scrum定義了三個具體的角色和責任蒋伦。

• 產品負責人負責建立整體的產品愿景弓摘，并負責軟件開發(fā)工作的投資回報率（ROI）。其他產品負責人的職責包括痕届。
  • 為產品的開發(fā)獲取初始和持續(xù)的資金
  • 代表其他利益相關者衣盾，充當需求問題、決策和優(yōu)先級的最終仲裁者
  • 管理爷抓、控制并使產品積壓可見势决，以便每個迭代都能解決產品積壓中最有價值的需求。
  • 接受或拒絕每個沖刺階段所完成的軟件版本蓝撇，并決定產品的交付時間果复。
  • 規(guī)劃長期的發(fā)布策略
  • 決定何時終止開發(fā)
• Scrum團隊，也叫Scrum開發(fā)團隊渤昌，是一個自我管理虽抄、自我組織的協作團隊走搁，有權做出決定并采取必要的行動來實現每個沖刺的目標。Scrum團隊是跨職能的迈窟、多樣化的私植。該團隊必須包括具有實現軟件所需的所有技能的成員--需求、設計车酣、代碼曲稼、技術出版物、白盒和黑盒測試湖员、質量贫悄、配置管理、領域和/或法規(guī)專業(yè)知識等等娘摔。除了這些活動窄坦，Scrum團隊還參與了。
  • 估算工作量
  • 創(chuàng)建沖刺積木
  • 幫助產品所有者審查和確定產品積壓的優(yōu)先次序
  • 識別阻礙開發(fā)工作的因素

理想的Scrum團隊規(guī)模是5到9名成員凳寺。對于需要更多人參與的大規(guī)模開發(fā)工作鸭津，Scrum方法論建議組建多個Scrum團隊，并使用Scrum of Scrums肠缨，由各個Scrum團隊的代表組成曙博，以實現團隊間的協調。
Scrum主管負責確保開發(fā)工作是按照Scrum的實踐怜瞒、價值和規(guī)則進行的父泳，并確保開發(fā)工作按計劃進行。Scrum主管與Scrum團隊吴汪、產品所有者和其他利益相關者進行互動惠窄，以。

• 傳授Scrum流程漾橙，并充當敏捷教練
• 保護Scrum團隊不受外界干擾和干涉
• 幫助獲取資源和消除障礙
• 幫助采用杆融、調整和持續(xù)改進Scrum流程，以滿足Scrum團隊和組織的需求
• 主持沖刺計劃會議霜运、日常Scrum會議脾歇、沖刺回顧會議和沖刺回顧會議
• 促進團隊協議的收集，包括關于他們將如何開展工作的協議
• 在每個沖刺期間淘捡，捕捉經驗數據以跟蹤進度并確定Scrum團隊的速度（團隊交付工作的總體能力）藕各。

在Scrum中，雖然Scrum團隊是自我管理的焦除，但管理層負責最終決策激况，并制定項目必須遵循的章程、標準和慣例。管理層也參與制定項目的目標乌逐、目的和要求竭讳。管理層參與選擇產品負責人，衡量進度浙踢，并減少產品積壓绢慢。

客戶、用戶和其他利益相關者參與到為正在開發(fā)或增強的系統(tǒng)確定產品積壓項目的相關工作中洛波∫扔撸客戶和用戶收到交付的軟件并向Scrum團隊提供反饋》芩辏客戶也可能參與選擇產品負責人。

產品積壓定義了所有尚未在軟件中實現的荸百、打算成為最終產品一部分的已知特性（功能和非功能要求）闻伶。產品積壓包括對正在建立或增強的系統(tǒng)的業(yè)務和技術要求的優(yōu)先級和持續(xù)更新的列表，通常被表述為用戶故事够话。產品積壓項目可以包括期望的特性蓝翰、功能、錯誤修正女嘲、缺陷畜份、要求的增強和技術升級。產品積壓也可以包括流程改進欣尼。

Scrum過程以愿景開始爆雹，包括預期的投資回報率、發(fā)布和里程碑愕鼓。最初的產品積壓包含一個優(yōu)先考慮的產品需求列表（例如钙态，用戶故事、用例或功能）菇晃。隨著時間的推移册倒，會有更多的需求出現，并被優(yōu)先考慮磺送，添加到產品積壓中驻子。

每個沖刺階段都會有一個由Scrum主管主持的沖刺計劃會議。這個會議實際上是兩個背對背舉行的會議估灿，但許多組織將這兩個會議合并為一個會議崇呵。在沖刺計劃會議的第一部分，Scrum團隊和Scrum主管與產品所有者會面馅袁，以演熟。

• 確定一個沖刺 "目標"，這是一個對沖刺期間要實現的整體工作的簡短描述。這個目標被用來集中精力芒粹，并在概念上將沖刺聯系在一起兄纺。
  根據新的信息，或者自上個沖刺階段以來添加或返回到產品積壓中的任何項目化漆，重新確定產品積壓中剩余項目的優(yōu)先次序估脆。
• 對于Scrum團隊就產品積壓中的項目提出的任何問題，包括關于內容座云、目的疙赠、意義和意圖的問題，從產品所有者那里獲得答案朦拖。
• 從產品積壓中選擇Scrum團隊認為在沖刺結束前可以轉化為可交付產品功能的完整增量的項目--創(chuàng)建沖刺積壓圃阳。
• Scrum團隊使用故事點或努力來估計選定的用戶故事。團隊將估計的總數與他們在過去沖刺期間的表現進行比較璧帝，以此來衡量他們在沖刺期間的工作投入是否過多或過少捍岳。估算和速度在第15章中討論）。
• Scrum團隊向產品所有者承諾睬隶，他們將盡最大努力交付這些選定的項目锣夹。

在沖刺計劃會議的第二部分，沖刺活動是通過將每個選定的產品積壓項目轉化為實施該項目所需的初步任務集來計劃的苏潜。根據需要银萍，也可以增加額外的任務來進行沖刺。團隊可能不會預先知道所有的任務恤左，隨著沖刺的進行贴唇，額外的任務可能會被添加到列表中。

在沖刺期間飞袋，Scrum團隊通過執(zhí)行將沖刺積壓項目轉化為一個或多個軟件產品（軟件構建滤蝠、用戶文檔等）的任務，將選定的產品積壓變成功能的增量授嘀。在沖刺期間物咳，Scrum團隊還舉行簡短的每日會議，稱為Scrums或每日站立會議蹄皱。在這些每日Scrums中览闰，每個Scrum團隊成員都要回答三個問題。

• 自從上次Scrum會議以來巷折，我已經做了什么工作压鉴？
• 在下一次Scrum會議之前，我將做什么工作锻拘？
• 我有哪些障礙（問題或難題）油吭？

每個沖刺的主要產出是 "一個潛在的可發(fā)貨的產品增量"（Schwaber 2007）击蹲，這是一個工作軟件（根據商定的 "完成 "的定義進行測試和完成），其質量足以發(fā)貨婉宰，盡管它可能不具備所有需要實際發(fā)貨的功能歌豺。當Scrum團隊在沖刺結束時交付新功能時，交付過程包括心包。

與產品所有者和其他感興趣的利益相關者舉行沖刺回顧會議类咧，以展示新功能并獲得反饋，然后決定是否發(fā)布產品（或者在第28章討論的發(fā)布管理計劃中作出這一決定）蟹腾。

• 沖刺回顧痕惋，Scrum主管和Scrum團隊對上一個沖刺的執(zhí)行情況進行評估，并根據需要調整團隊的流程和工作協議娃殖，以便為下一個沖刺進行改進值戳。
• 在每個Scrum結束時，產品所有者決定產品積壓上是否有足夠的價值繼續(xù)進行下一個沖刺炉爆。

在沖刺期間或沖刺結束時堕虹，可能會根據利益相關者的反饋或其他利益相關者的需求來確定新的需求。此外叶洞，在剛剛結束的沖刺階段鲫凶，可能還有不完整的沖刺積壓項目禀崖。這些需求將被優(yōu)先考慮并添加到產品積壓中衩辟。然后召開下一次沖刺計劃會議，再次開始這個循環(huán)波附，重復這個循環(huán)艺晴，直到所有的功能都被實現，或者產品所有者決定終止開發(fā)工作掸屡。

積壓改進會議不是Scrum的正式會議之一封寞。然而，許多組織發(fā)現這些會議對于為下一次沖刺計劃會議準備產品積壓中的項目很有用仅财。

• 將大的故事/功能或史詩（一個故事太大狈究，無法在一個沖刺階段實現）分解成小的故事/功能
• 更清楚地定義不容易理解或模糊的故事/功能
• 與利益相關者進行額外的對話，以確定故事的接受標準
• 重新確定新增或改進項目的優(yōu)先次序

極限編程

極限編程（XP）是一種敏捷的迭代開發(fā)方法盏求，它將敏捷開發(fā)的思想帶到了極致抖锥。XP包括測試驅動開發(fā)（TDD）技術，開發(fā)人員首先編寫一個當前軟件無法通過的測試碎罚，因為他們還沒有編寫相應的代碼磅废，然后編寫能夠通過該測試的代碼。使用重構荆烈，開發(fā)人員然后改善該代碼的質量拯勉，消除任何重復的竟趾、復雜的或笨拙的結構。這就建立了Beck（2005）所說的測試--代碼--重構宫峦，測試--代碼--重構的自然和有效的 "節(jié)奏"岔帽。

XP基于以下價值觀，其中許多是整個敏捷社區(qū)共有的斗遏。

• 溝通山卦。XP強調溝通。根據Beck（2005）诵次，"在團隊軟件開發(fā)中最重要的是溝通"账蓉。

• 簡潔性。為了避免對模糊理解的需求和結構的承諾逾一，XP要求設計保持在最基本的東西上铸本，可以在下一次交付/迭代的時間范圍內提供所需的功能。一個直截了當的遵堵、被廣泛溝通和理解的軟件結構意味著人們需要正式 "溝通 "的東西會減少箱玷。這有助于消除可能混淆有效溝通的含糊不清之處。XP創(chuàng)造了一個縮寫YAGNI陌宿，"你不需要它"锡足，以強調不要添加當前（已知）功能不需要/不會需要的結構和設計。如果你認為你將來可能需要它壳坪，那就等到將來再添加它（基于Succi 2001）舶得。然而，YAGNI并不意味著你不能擁有復雜的軟件爽蝴。YAGNI只是意味著軟件應該盡可能的簡單沐批，并且仍然滿足客戶的需求。

• 反饋蝎亚。XP實踐者認為九孩，因為事情會發(fā)生變化，所以必須縮短反饋周期发框，從幾周或幾個月躺彬，縮短到幾分鐘或幾小時。XP團隊不斷努力獲得并利用盡可能多的反饋梅惯。

• 勇氣宪拥。勇氣有時會表現為一個人在遇到障礙時愿意去做或嘗試一些事情，犯錯誤个唧，從錯誤中學習江解，拋棄不可行的東西，重新開始徙歼。在其他時候犁河，勇氣可能意味著等待鳖枕、傾聽和學習，直到一個更好的桨螺、更簡單的解決方案出現宾符。XP實踐者必須有勇氣說出真相，承認真正存在的東西并處理它灭翔。

• 尊重魏烫。如果任何一個人的貢獻不被其他成員所重視，那么這個團隊就不可能像它應該/可以的那樣有效肝箱。團隊還必須有強烈的成功動機和對工作環(huán)境的熱情哄褒。為了達到這個目的，團隊成員必須互相尊重煌张，尊重項目呐赡，以建立信任和集體責任。

XP提倡以下原則骏融，其中許多也是整個敏捷社區(qū)共有的链嘀。

• 經濟性。XP方法通過以下方式關注經濟性档玻。
  • 推遲成本怀泊。鼓勵項目在做出設計/開發(fā)承諾之前，"等到最后的責任時刻"误趴。
  • 賺取報酬霹琼。承諾盡快交付有價值的、可運行的軟件冤留，并在此后經常交付碧囊，這意味著客戶將獲得軟件的好處树灶，而開發(fā)組織將更快收到付款纤怒。
  • 軟件再利用。創(chuàng)建用于重復使用的軟件意味著它的價值可以被反復實現天通，而不是僅僅一次泊窘。
  • 業(yè)務調整。強調與客戶的互動和反饋像寒，創(chuàng)造出的軟件產品更有可能具有商業(yè)價值烘豹，與商業(yè)目標和目的相一致，并滿足企業(yè)的需求诺祸。
• 互利：互利意味著關注那些現在為利益相關者携悯、現在為開發(fā)者、以及以后為利益相關者和開發(fā)者提供價值的活動和產品筷笨。
• 接受的責任：XP團隊成員 "簽署 "實施任務憔鬼。也就是說龟劲，一旦下一次迭代的需求清單被定義、優(yōu)先級被確定轴或，并被分解為實現這些功能所需的任務昌跌，開發(fā)人員就會自行分配這些任務。
• 冗余：這意味著使用目標相似的冗余活動照雁，只要它們能增加價值蚕愤。例如，在使用結對編程后進行測試是多余的饺蚊，因為這兩種活動都是為了消除缺陷--然而萍诱，在實踐中，測試通常會發(fā)現在開發(fā)中沒有發(fā)現的額外缺陷污呼，所以測試是增值的砂沛。
• 自我相似性：尋找有效的模式并在其他地方重復它們。尋找能幫助你用昨天的解決方案解決今天的問題的模式曙求。除非是唯一的選擇碍庵，否則不要去用獨特的解決方案來解決管理或流程問題，也不要用需求悟狱、設計或代碼解決方案静浴。
• 質量。質量必須建立在軟件中挤渐。引用Beck（2005）的話苹享。
  • "把質量推得更高，往往會導致更快的交付浴麻；而降低質量標準得问，往往會導致更晚、更難預測的交付软免。"
  • "質量的好處沒有明顯的限制宫纬，只有我們理解如何實現質量的能力的限制。"
  • "質量不是一個純粹的經濟因素膏萧。人們需要做他們感到自豪的工作漓骚。"
• 流程：XP認為軟件開發(fā)是一個從一個迭代到下一個迭代的連續(xù)流程，而不是一組離散的階段榛泛。
• 失敗蝌蹂。失敗不是浪費，它使我們能夠從錯誤中學習曹锨。試驗和錯誤可能是發(fā)現什么是有效的最便宜的方法孤个。
• 機會。學會把問題看作是機會沛简。
  • 改進我們做事的方式
  • 創(chuàng)造更好的軟件
  • 建立人際關系
  • 拓展我們的個人知識和技能組合
  • 團隊和組織學習
• 反思：改進來自于對問題（或潛在問題）原因的學習齐鲤，以及找到糾正（或避免）問題的解決方案硅急。XP要求團隊不斷思考他們在做什么和為什么。這提供了輸入和反饋佳遂，允許立即重用好的想法和快速消除問題营袜。我們不應該隱藏我們的錯誤。我們應該暴露它們并從中學習丑罪。
• 人性化：XP增加了對人的問題的關注荚板，以便人們和團隊能夠緊密合作。這種關注對那些習慣于作為個人貢獻者工作的人來說可能是新的吩屹，甚至是不舒服的跪另。
• 改進：敏捷方法和計劃驅動方法都認為，持續(xù)改進是有效和高效地實現更高質量和增值的軟件的最佳途徑煤搜。
• 小步走免绿。XP強調以小步快跑的方式做出改變。團隊應該尋找最起碼的方向擦盾，然后對變化進行優(yōu)先排序嘲驾，并逐步實施，這樣可以減少開銷和風險迹卢。
• 多樣性：在團隊中擁有多樣性可以幫助產生積極的沖突（新的想法辽故、不同的意見、替代的方法）腐碱。

為了將其價值和原則落實到軟件開發(fā)的日常工作中誊垢，XP包括一套主要和必然的實踐。XP的主要實踐包括症见。

• 團隊共處：軟件應該在一個足夠大的工作空間里開發(fā)喂走，以便整個團隊，包括客戶谋作，都能在一個空間里一起工作芋肠。
• 整個團隊。在實施XP項目時瓷们，整個跨職能业栅、自我指導的XP團隊作為一個單位工作秒咐，以完成其目標谬晕。
• 信息化的工作空間: XP團隊利用工作空間的墻壁來傳達重要的、活躍的信息携取。一目了然攒钳，人們應該能夠感受到項目的進展情況，并能夠僅僅通過查看工作區(qū)周圍張貼的信息就能發(fā)現當前或潛在的問題雷滋。
• 有活力的工作：XP強調在可持續(xù)的節(jié)奏下不撑，從業(yè)者只需工作盡可能多的時間就能有成效（每天8小時文兢，每周40小時，不生病來上班）焕檬。- XP也鼓勵在工作時有合理的玩耍時間姆坚，以使個人恢復活力并激發(fā)創(chuàng)造力。
• 故事: 開發(fā)人員通過要求他們的利益相關者講述關于誰將使用該系統(tǒng)实愚，如何使用該系統(tǒng)兼呵，以及為什么使用的故事來創(chuàng)建系統(tǒng)的需求。這些故事被記錄下來腊敲，成為第一層次的優(yōu)先需求击喂，只有在選擇實施時才會充實到更多細節(jié)。
• 季度周期碰辅。以季度為周期懂昂，計劃（Beck 2005）。
  • "識別瓶頸--特別是那些在團隊之外控制的瓶頸
  • 專注于大局--項目在組織中的位置
  • 啟動修復
  • 計劃本季度的主題
  • 挑選一個季度的故事來解決這些主題"
• 每周的周期没宾。團隊的工作是編寫測試用例凌彬，并在接下來的五天內讓它們運行。召開每周計劃會議循衰，以饿序。
  • 審查實際進展與預期進展的匹配情況
  • 選擇該周要實施的客戶故事
  • 根據需要，進一步重新定義每個故事的要求和接受標準
  • 估計實施每個故事所需的工作時間
  • 將故事劃分為任務
  • 讓每個團隊成員自行選擇他們負責執(zhí)行的任務
• 松弛：理想情況下羹蚣，團隊將在所需的時間內完成所有承諾的工作原探，但在每周的時間表中留有一些松弛，以便在每周的周期內彌補任何不可預見的事件顽素。
• 結對編程：結對編程涉及兩個人咽弦，其中一個人不斷審查另一個人正在開發(fā)的東西。關于結對編程的更多細節(jié)見第22章）胁出。
• 測試驅動的開發(fā)（TDD）：TDD主張在編寫代碼之前型型，先編寫代碼必須通過的測試用例。
• 漸進式設計全蝶。一般來說闹蒜，敏捷方法，特別是XP抑淫，不寫一些所謂的大設計在前面（BDUF）绷落。也就是說，設計是隨著時間的推移而出現的始苇，通過逐步的砌烁、持續(xù)的努力，致力于反思系統(tǒng)中已經存在的東西和接下來需要的東西。
• 持續(xù)集成：XP實踐在持續(xù)的基礎上將每一塊改變的（或新的）軟件代碼集成到系統(tǒng)中函喉，在代碼改變的幾個小時內創(chuàng)建并測試一個新的構建避归。這是與傳統(tǒng)的瀑布式生命周期行為相反的一端，所有（或大部分）的軟件代碼在集成開始前就已經寫好管呵。
• 10分鐘的構建梳毙。要想在XP項目中頻繁地進行集成，必須能夠非尘柘拢快速地構建系統(tǒng)和運行測試比搭。10分鐘構建所代表的目標就是要使之成為可能钾虐。

XP的必然做法包括。

• 團隊的連續(xù)性：高績效的團隊應該長期保持在一起。
• 真正的客戶參與酿矢。Martin (2003)說数冬，客戶是 "定義和優(yōu)先考慮功能的人或團體"非洲《翁埽客戶需要與開發(fā)團隊保持密切聯系（如果不是團隊的實際成員），并通過積極參與軟件的定義和驗證（編寫測試用例排抬，甚至可能執(zhí)行測試用例）來對軟件負責懂从。
• 協商范圍：XP哲學說，如果在一個給定的增量中蹲蒲，有什么東西必須 "滑落"番甩，那應該是范圍（功能），而不是操縱成本届搁、進度或質量缘薛。由于范圍縮小而錯過的功能被移到下一個增量。
• 單一代碼庫：正如前面討論持續(xù)集成時指出的卡睦，保持單一代碼基線是非常理想的宴胧。然而，分支可以在短時間內出現表锻，然后通過頻繁的集成將其重新整合在一起恕齐，至少每天都要做。
• 共享代碼瞬逊。在團隊有了集體責任感之后显歧，團隊中的任何人都可以在任何時候改進系統(tǒng)的任何部分（Beck 2005）。這需要采用全團隊的編碼標準确镊。"如果需要進行改變士骤，處于最佳狀態(tài)的人（看到立即需要改變的開發(fā)者）可以進行改變"（Astels 2002）。
• 代碼和測試骚腥。XP的 "最小化 "文檔方法表明敦间，代碼和測試應該是任何其他文檔的基礎，而不是相反束铭。無論好壞廓块，產品就是軟件的作用，所以軟件代碼和測試是記錄產品能力的最終權威契沫。
• 漸進式部署带猴。通過在項目的早期和之后經常遞增地部署軟件，項目可以定期地展示有形的工作成果懈万。這使得客戶也能經常提供有用的反饋拴清，因此，在完成工作和反映工作之間幾乎沒有時間間隔会通。對小增量的審查允許經常調整項目方向和快速識別缺陷口予。對每個小增量的規(guī)劃也更準確。
• 每日部署涕侈。XP的理想是每天把工作的軟件送到客戶的手中沪停。除了在小的情況下，由于各種原因裳涛，這可能是不實際的木张。然而，重要的是要認識到端三，軟件不被積極使用的時間越長舷礼，開發(fā)就越有可能偏離客戶的最終需求（即使它符合客戶最初認為有意義的方向）。